# NiamonX Tools WiKi **NiamonX Tools WiKi** is the central knowledge hub that provides detailed documentation, usage guides, and technical insights into all tools, modules, and research utilities developed within the **NiamonX ecosystem**. It serves as a unified reference point for engineers, researchers, and security analysts working with NiamonX technologies in the fields of **AI, data intelligence, cybersecurity, and OSINT**. # Data Breach Search # Public Breached Search | Public Breaches (140+ Billion Records) [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/D6VDgk24I4VZK3js-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/D6VDgk24I4VZK3js-image.png) #### **Overview of the Service** The platform available at **[dash.niamonx.io/breaches\_search](https://dash.niamonx.io/breaches_search)** is a professional-grade **Public Breached Data Search System** designed for verifying whether specific personal identifiers have appeared in any known public data leaks across the Internet. It operates on an **aggregated dataset exceeding 140 billion records** collected from **over 4,500 public breach sources**, making it one of the most extensive publicly searchable breach databases in existence. --- ### 🔍 How the Search Works When a user enters a query — such as an **email address, username, phone number, IP, or domain** — the system performs a real-time lookup across its encrypted, indexed data clusters. The query is normalized, tokenized, and securely matched against hashed or pseudonymized datasets to locate potential breach entries. The search engine uses **multi-vector indexing** optimized for text, numeric, and composite keys (e.g., *email + password*, *name + city*), allowing flexible combined searches. To maintain integrity and performance: - Each user request is subject to a **10-second cooldown** (anti-spam policy). - Partial queries can improve recall; deleting one character may trigger a broader match. - Cached results are used for frequent queries to improve response time. --- ### 🧩 What Can Be Searched You can look up: - **Emails and logins** - **Phone numbers** (international format) - **Domains or URLs** - **IP addresses** - **Full names or social network identifiers** - **“Combo” lines** (e.g., *email + password* pairs from public leaks) The system structures results into logical “groups” that may include: - Email or login identifiers - Hashed or masked passwords - IP and domain references - Profiles and related metadata - First/last seen activity dates Sensitive fields like passwords remain **masked** until explicitly revealed by the user. --- ### 🛡️ Security & Ethics All stored data and query logs are **encrypted using modern cryptographic algorithms**. Only **aggregated metadata** — not full confidential strings — is retained in request history for transparency and analytics. Additional safeguards: - **Bank card and medical information** are automatically excluded from indexing. - **Publication of retrieved data** is strictly forbidden. - Detected abuse leads to **account suspension and IP blocking**. The service is intended for **ethical use only** — such as checking whether your credentials or company assets appear in public leaks and taking appropriate security measures (e.g., password changes, MFA setup). --- ### 📊 Extra Features - **Risk indicator:** assesses the exposure level of each result. - **Result caching:** speeds up repeated lookups. - **CSV export:** allows structured export without revealing sensitive fields. - **Ongoing index updates:** new sources are continuously crawled and normalized. --- In summary, **NiamonX Breach Search** acts as a secure, encrypted intelligence platform that enables professionals and individuals to verify their exposure in public breaches responsibly. It prioritizes **data protection, cryptographic integrity, and ethical transparency**, providing actionable insights while maintaining user and data privacy. ### 📬 Contact Information For any inquiries, users can contact the project team directly: - **support @ niamonx.io** — Technical Support - **other @ niamonx.io** — General Inquiries - **takedown @ niamonx.io** — Requests for Data Removal / Privacy Takedowns - **legal @ niamonx.io** — Legal Matters An alternative contact channel is the official **Helpdesk**: 🔗 [https://support.niamonx.io/](https://support.niamonx.io/) # ULP (Infostealer Logs) | Public Breached ULP Search [![sdadsadasdas_clean_clean.jpg](https://wiki.niamonx.io/uploads/images/gallery/2025-11/scaled-1680-/T7rsYi2uJsC8JxYU-sdadsadasdas-clean-clean.jpg)](https://wiki.niamonx.io/uploads/images/gallery/2025-11/T7rsYi2uJsC8JxYU-sdadsadasdas-clean-clean.jpg) #### **Overview of the Service** The platform available at **[dash.niamonx.io/ulp\_search](https://dash.niamonx.io/ulp_search)** — known as **ULP Search** — is a specialized **Data Breach Search Engine** developed by **NiamonX** for identifying credential exposures in **public and infostealer leak datasets**. It provides professionals and security researchers with a structured, secure, and ethical way to verify whether specific login credentials have been compromised online. The ULP database currently indexes **over 19 billion credential records**, continuously updated and refined through automated pipelines, ensuring freshness, accuracy, and de-duplication. --- ### 🧩 What is ULP? **ULP** stands for **URL · LOGIN · PASSWORD**, representing a *credential triple* extracted from public or infostealer data sources. Each record typically contains: - **URL** — the website, endpoint, or domain where credentials were used (e.g., `example.com/login`) - **LOGIN** — the associated username or email address - **PASSWORD** — the captured or leaked password (masked by default for security) This triplet allows correlation between breached accounts, reused passwords, and compromised domains, forming the foundation of forensic credential analysis within NiamonX’s breach intelligence system. --- ### 🔍 How the Search Works Users can query the database using any of the following parameters: - **Email address or username** - **Domain or URL** - **Password (masked matching supported)** The system automatically detects the query type (`Auto` mode) or allows manual selection for more specific searches. Searches are conducted in **real-time** against encrypted datasets, and results are filtered and ranked by confidence and relevance. Key operational details: - **Exact match** can be enabled for precise email or username lookups. - **Domain-based searches** support suffix logic to detect subdomains (e.g., searching `example.com` will also include `mail.example.com`). - **URL searches** accept partial paths, ideal for endpoint-level tracing. - **Result limits:** up to 1,000 records per request. - **Anti-abuse control:** all queries are encrypted and rate-limited. If search performance temporarily decreases, it may indicate **active deduplication** or **dataset reindexing** — repeating the search after a few minutes ensures access to the freshest possible data. --- ### 🧠 Key Features - **AI Audit System:** enhances search precision and filters false positives through pattern-based validation and contextual AI analysis. - **Result History & Filtering:** users can save searches, view historical queries, and filter by host, login, or URL. - **Masked Passwords:** sensitive data remains hidden by default to prevent misuse. - **Secure Export Options:** structured result exports with sensitive fields excluded. - **Regular Updates:** continuous ingestion of verified breach data ensures up-to-date intelligence. --- ### 🛡️ Security, Privacy & Ethics Every search request is **fully encrypted end-to-end**, ensuring that user queries and results remain private. The system never shares, resells, or exposes query data — even internally. Ethical principles: - Only perform searches for **data you own** or have **explicit authorization** to analyze. - Keep results confidential and never redistribute them. - Immediately **change any exposed passwords** and **enable multi-factor authentication (MFA)** if compromise is detected. - Publication of retrieved data in open sources is strictly prohibited. --- ### 📈 Technical Highlights - **19B+ credential records** - **Real-time encrypted search** - **Periodic deduplication & refresh cycles** - **Adaptive caching for faster repeated queries** - **Multi-type query engine (Email / Domain / URL / Password)** --- ### 📬 Contact Information For support, inquiries, or privacy-related requests, the NiamonX team can be reached directly via: - **support @ niamonx.io** — Technical Support - **other @ niamonx.io** — General Inquiries - **takedown @ niamonx.io** — Personal Data Removal Requests - **legal @ niamonx.io** — Legal or Compliance Matters Alternative contact channel: 🔗 **Helpdesk:** [https://support.niamonx.io/](https://support.niamonx.io/) --- In summary, **NiamonX ULP Search** is a **cryptographically secure and ethically governed breach intelligence system** designed for professional credential analysis. It provides deep visibility into compromised login data from billions of records — while maintaining the highest standards of **security, privacy, and responsible use**. # PBS v2 (Beta Search) | Public Breached Search V2 [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2025-11/scaled-1680-/19oOAOYO1pVXHRy5-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2025-11/19oOAOYO1pVXHRy5-image.png) #### **Overview of the Service** The platform available at **[dash.niamonx.io/breaches\_s\_v2](https://dash.niamonx.io/breaches_s_v2)** — known as **Public Breached Search V2** — is an advanced, security-focused version of the NiamonX breach intelligence engine. It enables users to safely and privately search for **publicly available leaked records** (emails, usernames, phone numbers, or hashes) through a **fully encrypted channel**, using an enhanced privacy-preserving architecture. This system is designed for individuals, analysts, and cybersecurity teams who need to verify whether specific identifiers have been compromised — without exposing their search queries or retrieved data. --- ### 🔍 How the Search Works When a user submits a query — such as an **email address, username, phone number, or hash** — the system performs a real-time lookup across an **alternative, minimized index** of public breach data. The search is executed through a **closed security network** using **end-to-end encryption** and a **master key–based decryption layer**. This ensures that: - All transmitted data remains encrypted at every step. - Decryption occurs **only on the client side**, not on NiamonX servers. - The system never stores sensitive results or full identifiers in plain form. This approach provides **maximum privacy**, ensuring that no third party — including NiamonX infrastructure — can access raw search data or results. --- ### 🧩 What Can Be Searched Supported input types: - **Email address** - **Username / Login** - **Phone number** (international format) - **Hash** (MD5 / SHA1 / SHA256 and similar) Unlike the standard Breached Search engine, V2 does **not** support URLs, domains, or combined queries. It focuses exclusively on **personal identifiers and cryptographic hashes** to maintain precision and data hygiene. Passwords found in results are **hidden (masked)** by default. Users may reveal them manually if needed for verification, but they must not redistribute or publicly display that information. --- ### 🧠 Key Features - **Encrypted Communication Channel:** every search request and response is transmitted securely. - **Client-side Decryption:** sensitive content is decrypted locally using the user’s master key. - **Minimal Indexing:** only essential metadata is stored to ensure fast lookups while reducing exposure. - **Local Query History:** recent searches (up to 200 entries) are stored locally in the browser, not on the server. - **Flexible Export:** results can be exported in **CSV** or **JSON** format, excluding confidential fields. - **Password Visibility Control:** toggle to hide or show masked password fields. - **Filtering System:** refine results by data type or source metadata. --- ### 🛡️ Security, Privacy & Ethics The service is built with **security-first architecture** and strict privacy guarantees: - All communication is conducted through a **secure, encrypted channel**. - Data is stored and processed in a **closed system** environment. - **No internal quotas or usage metrics** are publicly displayed to prevent misuse. - Searches must only be performed on **your own data** or with **explicit permission**. - Abuse or attempts to deanonymize datasets will result in **account termination**. - **Publication of personal or sensitive data retrieved from the system is strictly forbidden.** Users are strongly encouraged to **practice digital hygiene** — for example, by changing passwords, enabling MFA, and avoiding credential reuse. --- ### ⚙️ Technical Highlights - **Alternative breach dataset with minimal indexing** - **Closed internal security infrastructure** - **End-to-end encryption with client-side decryption** - **Local storage of query history (no server retention)** - **Supports: email / username / phone / hash** - **Output masking for passwords and sensitive fields** - **CSV/JSON export with filtering tools** --- ### 📬 Contact Information For any technical, legal, or privacy-related inquiries, users can reach the NiamonX team directly via: - **support @ niamonx.io** — Technical Support - **other @ niamonx.io** — General Inquiries - **takedown @ niamonx.io** — Requests for Data Removal / Privacy Takedowns - **legal @ niamonx.io** — Legal or Compliance Matters Alternative contact channel: 🔗 **Helpdesk:** [https://support.niamonx.io/](https://support.niamonx.io/) --- In summary, **NiamonX Public Breached Search V2** is a **secure, privacy-preserving intelligence system** that enables safe and encrypted lookup of breach data. It prioritizes **user confidentiality, cryptographic protection, and ethical operation**, ensuring that every search remains private, traceable only to the authorized user, and never exposed beyond their secure session. # Public Breached Search Fast (80+B) | Fast Public Breach Intelligence Search [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/UZ2TJy182HPrsILY-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/UZ2TJy182HPrsILY-image.png) ***The platform available at*** [dash.niamonx.io/breaches\_search\_fast](https://dash.niamonx.io/breaches_search_fast) ## Overview of the Service **Public Breached Search Fast (80+B)** is a high-speed breach intelligence tool available within the NiamonX platform. It enables users to search across **80+ billion public records** collected from publicly available breach datasets and alternative intelligence channels. The system is designed for individuals, analysts, security researchers, compliance teams, and cybersecurity departments that need to quickly verify whether specific identifiers, accounts, or technical indicators appear in compromised public datasets. Unlike the encrypted PBS v2 engine, **Public Breached Search Fast** focuses on speed, broad query coverage, source diversity, graph analysis, and flexible exports. It supports a wide range of identifiers, including emails, usernames, phone numbers, names, domains, IP addresses, vehicle identifiers, social media IDs, and composite queries. The service is intended strictly for lawful security analysis, personal data verification, incident response, and defensive investigations. --- ## 🔍 How the Search Works When a user enters a search value, the system performs a fast lookup across a large alternative breach index containing more than **80 billion public records**. The user can either allow the system to automatically detect the query type or manually select a specific type, such as email, phone number, domain, VIN, passport, Telegram, VK, or composite query. The platform then returns available matches, grouped and structured by source, data type, and related metadata. Important behavior: - The same leak may have multiple source references. - A single query can return different source combinations across repeated searches. - Sources are updated daily. - Repeating a request may reveal additional sources that were not included in previous results. - Free users are limited to **200 results**. - Sensitive fields, including passwords, are masked for free users. - Full access requires an upgraded account. This approach allows the system to prioritize both speed and broad source discovery while keeping sensitive information controlled. --- ## 🧩 What Can Be Searched Public Breached Search Fast supports **22 query types** with automatic detection. Supported query types: - `auto` — Auto-detect - `email` — Email address - `email_local` — Email local part - `email_domain` — Email domain - `phone` — Phone number - `fullname` — Full name - `nickname` — Nickname or username - `password` — Password - `ip` — IP address - `domain` — Domain - `car_plate` — Car plate - `vin` — Vehicle Identification Number - `passport` — Passport - `snils` — SNILS - `inn` — INN - `vk` — VKontakte identifier - `telegram` — Telegram identifier - `facebook` — Facebook identifier - `instagram` — Instagram identifier - `composite` — Multi-field composite query - `fullname_dob` — Full name with date of birth - `numeric_id` — Numeric identifier The search input supports values from **2 to 500 characters**. Users should enter only the value itself, not a full URL. For example, enter a domain name instead of a full website address. --- ## ⚙️ Search Interface The search interface includes the following main fields: ### Search Value The identifier or value to search for. Examples of supported values: - Email address - Phone number - Full name - Nickname - IP address - Domain - VIN - Car plate - Passport number - Social media identifier - Composite query ### Query Type The user may select a specific query type or use **Auto-detect**. Auto-detection helps identify the most likely input type and route the search through the correct lookup logic. ### Limit The user can specify the maximum number of results to retrieve. Free users are limited to **200 visible results** with sensitive information masked. Paid users may access higher result limits and full visibility depending on their subscription level and permissions. --- ## 🧠 Key Features ### Fast Search Across 80+ Billion Records The system is optimized for quick lookups across a very large public breach index. ### 22 Query Types Public Breached Search Fast supports a wide range of identifiers, including personal, technical, vehicle-related, and social media identifiers. ### Auto-Detection The platform can automatically detect the type of query entered by the user. ### Overview Section Search results include a structured overview of discovered matches, source distribution, and available metadata. ### Results View Matched records are displayed in a readable format with source highlighting and structured fields. ### Graph View The tool can visualize relationships between identifiers, sources, and connected records using graph-based analysis. ### AI Audit The AI Audit feature helps summarize and interpret the search results from a security and risk perspective. ### Offline Graph Export Users can export graph analysis as an offline HTML file for local review, reporting, or internal investigations. ### Cluster and Expand The system can cluster related records and expand connected entities to help analysts understand relationships between data points. ### Source Highlighting Sources are visually highlighted to make it easier to identify where specific records were found. ### Flexible Export Results can be exported in multiple formats: - CSV - TXT - JSON - Markdown - PDF Export functionality is intended for lawful internal use, incident response, compliance checks, and security reporting. --- ## 📊 Results, Graph, and AI Audit Public Breached Search Fast provides multiple result analysis layers. ### Overview The overview section summarizes key information about the query, such as: - Number of discovered records - Related data categories - Available source groups - Detected query type - Possible risk indicators ### Results The results section displays matching records from available public breach sources. Depending on the user’s access level, some sensitive fields may be masked. ### Graph The graph view helps users analyze relationships between identifiers and sources. This is useful for: - Account compromise investigations - Identity exposure analysis - Infrastructure correlation - Reused identifier detection - Source relationship mapping ### AI Audit The AI Audit feature provides an automated interpretation of the findings. It may help identify: - Potential account compromise - Reused credentials - Risky exposure patterns - Multiple-source appearances - High-risk identifiers - Recommended defensive actions AI Audit is intended to support analyst decision-making and should not be treated as a final legal or forensic conclusion. --- ## 📤 Export Options Public Breached Search Fast supports several export formats: - **CSV** — for spreadsheets and structured analysis - **TXT** — for simple plain-text review - **JSON** — for technical workflows and integrations - **MD** — for documentation and reporting - **PDF** — for formal reports and sharing with authorized parties - **HTML graph export** — for offline graph visualization Sensitive fields may be masked or excluded depending on account permissions, subscription level, and platform security rules. Users must not redistribute personal or sensitive data obtained from the system. --- ## ⚠️ Important Notes About Sources A single leak may have many different source references. Because sources are updated daily, repeated searches may show different or additional sources that were not included in earlier results. This behavior is normal and reflects the dynamic nature of the breach intelligence index. Users should treat results as intelligence indicators and verify important findings through proper security, legal, or compliance workflows before taking action. --- ## 🛡️ Security, Privacy & Ethics Public Breached Search Fast is built for defensive cybersecurity, personal security verification, and lawful intelligence analysis. Users must follow strict ethical rules: - Search only your own data or data you are legally authorized to investigate. - Do not use the system to stalk, harass, deanonymize, or target individuals. - Do not publish personal or sensitive data retrieved from the platform. - Do not redistribute passwords, identity documents, phone numbers, private addresses, or other confidential information. - Do not use breach data for account takeover, credential stuffing, fraud, spam, phishing, or social engineering. - Do not attempt to bypass masking, limits, access controls, or platform protections. - Use discovered exposure only for remediation, reporting, and defensive security actions. Recommended security actions after discovering exposed data: - Change affected passwords immediately. - Enable multi-factor authentication. - Avoid credential reuse. - Review account login history. - Monitor suspicious activity. - Notify affected users or internal teams when legally appropriate. - Request takedown or removal where applicable. Abuse of the system may result in account restriction, suspension, or termination. --- ## ⚙️ Technical Highlights - Search across **80+ billion public records** - Fast alternative breach intelligence channels - 22 supported query types - Automatic query type detection - Supports email, username, phone, name, password, IP, domain, VIN, car plate, passport, SNILS, INN, social media identifiers, and composite queries - Overview, Results, Graph, and AI Audit modules - Offline graph export in HTML format - Cluster and expand functionality - Source highlighting - CSV, TXT, JSON, Markdown, PDF export - Freemium access model - Free users limited to 200 results - Sensitive data masking for free users - Daily source updates --- ## 📌 Query Types Reference
Query TypeDescription
`auto`Auto-detect
`email`Email
`email_local`Email local part
`email_domain`Email domain
`phone`Phone
`fullname`Full name
`nickname`Nickname / Username
`password`Password
`ip`IP address
`domain`Domain
`car_plate`Car plate
`vin`VIN
`passport`Passport
`snils`SNILS
`inn`INN
`vk`VKontakte
`telegram`Telegram
`facebook`Facebook
`instagram`Instagram
`composite`Composite multi-field query
`fullname_dob`Full name + date of birth
`numeric_id`Numeric ID
--- ## 📬 Contact Information For technical, legal, abuse, privacy, or takedown-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Data Removal / Privacy Takedown Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX Public Breached Search Fast (80+B)** is a high-speed public breach intelligence tool designed for fast, broad, and structured searches across more than **80 billion public records**. It supports 22 query types, automatic detection, source highlighting, graph analysis, AI-assisted audit, offline graph export, and multiple export formats. The tool is intended for lawful cybersecurity investigations, personal exposure checks, compliance workflows, and defensive threat intelligence. It combines speed, large-scale coverage, and flexible analysis features while enforcing masking, access control, and ethical usage requirements. # Dark Web Search | Underground Threat Intelligence Monitoring [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/j3P3xRJybEj3drsJ-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/j3P3xRJybEj3drsJ-image.png) ***The platform available at*** [dash.niamonx.io/dark\_web\_search](https://dash.niamonx.io/dark_web_search) ## Overview of the Service **Dark Web Search** is a cybersecurity intelligence tool within the NiamonX platform designed to search for mentions of companies, domains, IP addresses, employee credentials, usernames, email addresses, cryptocurrency wallets, CVEs, and other security-relevant indicators across underground forums, dark web communities, and marketplace-related sources. The tool helps organizations detect early signs of exposure, leaked credentials, threat actor discussions, infrastructure mentions, and possible compromise indicators. It is designed for security teams, SOC analysts, threat intelligence researchers, compliance departments, and company owners who need to monitor whether their organization, assets, or employees are being discussed or exposed in underground environments. The results are informational and should always be validated through further investigation before taking operational, legal, or security actions. --- ## 🔍 How the Search Works When a user submits a search query, such as a company name, domain, IP address, email address, username, BTC wallet, or CVE identifier, the system searches across indexed dark web and underground forum data. In **Simple Mode**, the tool searches both: - Post titles - Post content Results are sorted by ingestion date, meaning the newest collected items appear first. The platform uses real-time forum scraping and NiamonX Radar intelligence capabilities to detect fresh mentions and newly ingested underground content. Supported search examples include: - Company name - Domain - IP address - Email address - Username - Employee credential - BTC wallet - CVE identifier - Product or project name - Internal keyword - Brand name The system is intended to help users identify possible risks, not to provide final conclusions without manual validation. --- ## 🧩 What Can Be Searched Dark Web Search supports keyword-based searches related to organizational and technical exposure. Common searchable values include: - Company names - Brand names - Domains - Subdomains - IP addresses - Corporate email addresses - Employee usernames - Credentials - Cryptocurrency wallets - CVE identifiers - Internal project names - Product names - Infrastructure keywords - Threat actor references - Leak titles - Forum post keywords The tool is flexible and can be used for both broad monitoring and focused investigation. For example: - Searching a company name may reveal forum discussions or leak mentions. - Searching a domain may reveal exposed credentials or infrastructure references. - Searching an email may reveal account exposure or credential leaks. - Searching a CVE may reveal underground discussions about exploitation. - Searching a BTC wallet may reveal links to ransomware, scams, or threat actor activity. --- ## 🧠 Key Features ### Real-Time Forum Scraping The tool continuously collects and processes data from monitored underground sources, allowing users to discover recently ingested mentions. ### Search Across Dark Web Forums and Marketplaces Dark Web Search helps identify mentions across underground communities, forums, marketplaces, and related intelligence sources. ### 5+ Source Groups The platform currently provides access to more than five monitored source groups, with collected data updated through the NiamonX Radar intelligence infrastructure. ### Simple Search Mode Simple Mode searches across both post titles and post content, making it easier to find relevant mentions without advanced query syntax. ### Ingestion Date Sorting Results are sorted by ingestion date, allowing analysts to focus on the newest discovered content first. ### AI Threat Summary The platform can generate an AI-assisted threat summary to help users quickly understand the possible risk, context, and relevance of discovered mentions. ### IOC Extraction The system can extract Indicators of Compromise from discovered content. Possible IOCs may include: - IP addresses - Domains - URLs - Email addresses - Hashes - Cryptocurrency wallets - CVEs - Usernames - Infrastructure indicators ### Risk Score The risk score is calculated based on signals such as: - Number of leak mentions - Verified hits - Credential presence - IOC density - Relevance of detected content - Possible relationship to the searched entity The score is intended as an analyst support metric and should not be treated as a final determination. ### Bookmarks Users can save searches and individual leak records as bookmarks. Bookmarks are stored locally in the browser and can be opened from the side panel. ### Search History The tool keeps local browser-based history for easier access to previous searches. ### Daily Request Limits Daily request limits depend on the user’s current plan. For example, a plan may include: - 1000 daily requests - Remaining request counter - Usage tracking by plan limit --- ## 📊 Results and Threat Context Dark Web Search results are designed to help analysts quickly understand what was found and why it may matter. A result may include: - Source name or source group - Title - Content snippet - Ingestion date - Detected indicators - Risk score - Related credentials - Extracted IOCs - AI-generated summary - Bookmark option The system helps users identify whether the discovered mention is likely related to: - Credential exposure - Company targeting - Data sale or leak discussion - Infrastructure reconnaissance - Vulnerability exploitation - Threat actor activity - Brand abuse - Fraud or phishing activity - Ransomware-related intelligence All findings should be reviewed manually and correlated with internal logs, SIEM data, EDR alerts, access history, and other trusted security sources. --- ## 🤖 AI Threat Summary The AI Threat Summary feature helps convert raw underground data into readable intelligence. It may assist with: - Explaining the context of the mention - Highlighting possible risks - Identifying exposed entities - Summarizing credential-related findings - Detecting relevant IOCs - Suggesting defensive investigation steps - Prioritizing high-risk results AI-generated summaries are intended to support human analysts and should not replace professional review. --- ## 🧬 IOC Extraction Dark Web Search can automatically extract security indicators from discovered content. Extracted indicators may include:
IOC TypeDescription
IP addressPossible infrastructure, victim system, or attacker-controlled host
DomainMentioned corporate, phishing, malware, or infrastructure domain
EmailExposed account, contact, or credential-related identifier
HashMalware, file, or credential-related hash
CVEVulnerability identifier discussed in underground content
WalletCryptocurrency wallet connected to scams, ransomware, or illicit activity
UsernameForum handle, employee account, or leaked login
URLMentioned website, panel, leak page, or infrastructure reference
IOC extraction helps analysts move from raw search results to actionable threat intelligence. --- ## 🔖 Bookmarks and Local Storage The bookmark system allows users to save important findings for later review. Bookmarks may include: - Search queries - Individual leak records - Relevant dark web mentions - Investigation leads - High-risk findings Saved searches and leaks are stored locally in the browser and can be opened from the side panel. This allows analysts to keep track of investigations without relying on external notes or repeated manual searches. --- ## 🚦 Daily Requests and Plan Limits Dark Web Search uses daily request limits based on the user’s subscription plan. The interface may show: - Daily requests used - Total daily request allowance - Remaining requests Example: ```text Daily Requests 0 / 1000 1000 remaining ``` These limits help control usage, protect infrastructure stability, and prevent abuse of the intelligence system. --- ## 🧠 Risk Score Logic The risk score is calculated using several intelligence signals. Main scoring factors include: - Number of leak mentions - Number of verified hits - Presence of credentials - Density of extracted IOCs - Recency of ingested content - Relevance to the searched company, domain, or identifier - Possible exposure severity - Underground source context A higher risk score may indicate stronger relevance, higher exposure, or more urgent investigation priority. However, risk scores should be interpreted as guidance, not as absolute proof of compromise. --- ## 🛡️ Security, Privacy & Ethics Dark Web Search is intended for defensive cybersecurity, threat intelligence, brand monitoring, and lawful corporate security investigations. Users must follow strict ethical and legal rules: - Search only for assets, companies, domains, accounts, or indicators that you are authorized to investigate. - Do not use the tool to stalk, harass, deanonymize, or target individuals. - Do not attempt to purchase, trade, or distribute stolen data. - Do not interact with threat actors based solely on search results. - Do not redistribute leaked credentials, personal information, or sensitive material. - Do not use discovered credentials for unauthorized access. - Do not use dark web intelligence for fraud, phishing, extortion, or social engineering. - Validate all findings before taking action. - Follow applicable data protection, privacy, and cybersecurity laws. Recommended defensive actions after discovering relevant mentions: - Validate the finding using internal security logs. - Check whether exposed credentials are active. - Force password resets where appropriate. - Enable or enforce multi-factor authentication. - Review access logs for suspicious activity. - Investigate affected systems or accounts. - Notify internal security, legal, or compliance teams. - Preserve evidence according to company procedures. - Request takedown where legally applicable. - Monitor for repeated mentions or escalation. Abuse of the platform may result in account restriction, suspension, or termination. --- ## ⚙️ Technical Highlights - Dark web and underground forum search - Real-time forum scraping - Search across 5+ monitored source groups - Simple Mode search across titles and content - Results sorted by ingestion date - AI threat summary - IOC extraction - Risk score calculation - Bookmarks for searches and individual leaks - Local browser-based bookmark storage - Search history - Daily request limits based on plan - Powered by NiamonX Radar API - Suitable for SOC, threat intelligence, compliance, and security monitoring workflows --- ## 🔌 NiamonX Radar API Dark Web Search is powered by **NiamonX Radar**, an advanced OSINT and cybersecurity intelligence API. NiamonX Radar provides access to modern intelligence services through a REST API and supports automated security workflows. The API can be used for: - Automated integrations - Data enrichment - Breach intelligence - Threat intelligence analysis - Dark web monitoring - IOC enrichment - Enterprise security workflows - Internal SOC automation - Risk monitoring - Compliance support Developers and security teams can explore the full API documentation, authentication methods, available endpoints, examples, and integration guides at: 🔗 [https://radar.niamonx.io/](https://radar.niamonx.io/) --- ## 📌 Usage Hints - Simple Mode searches both title and content. - Use company names, domains, IPs, emails, usernames, BTC wallets, or CVEs as search keywords. - Risk score is calculated from leak counts, verified hits, credentials, and IOC density. - Bookmarks can store both search queries and individual leaks. - Saved searches and leaks are stored locally in the browser. - Daily requests are based on the user’s plan limits. - Results are informational and should be validated through further investigation. - Newer results are prioritized by ingestion date. - AI summaries help triage findings but do not replace analyst review. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or takedown-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Data Removal / Privacy Takedown Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX Dark Web Search** is a threat intelligence and monitoring tool that helps users detect mentions of companies, domains, IP addresses, employee credentials, wallets, CVEs, and other security indicators across underground forums and marketplace-related sources. It provides real-time forum scraping, ingestion-date sorting, AI threat summaries, IOC extraction, bookmarks, local history, risk scoring, and integration support through the NiamonX Radar API. The tool is designed for lawful defensive cybersecurity, corporate monitoring, incident response, threat intelligence, and exposure validation. All results should be treated as intelligence leads and confirmed through further investigation before taking action. # OSINT Tools # Visual Osint (FotoForensics / ExifTool / Risk Score) [![rec.JPG](https://wiki.niamonx.io/uploads/images/gallery/2025-11/scaled-1680-/GIBnFlS0K23JGYiM-rec.JPG)](https://wiki.niamonx.io/uploads/images/gallery/2025-11/GIBnFlS0K23JGYiM-rec.JPG) #### **Overview of the Service** The **Visual OSINT** module — available as part of the NiamonX investigation suite — is an advanced **photo forensics and metadata analysis tool** that helps identify image manipulation, origin, and authenticity indicators. It integrates multiple forensic technologies — including **FotoForensics-style artifact analysis**, **ExifTool-based metadata extraction**, and **CASIA AI prediction** — to deliver a complete visual intelligence assessment for investigators, journalists, and security analysts. --- ### 🧩 What the Tool Does **Visual OSINT** performs a deep, server-side forensic analysis of uploaded images, combining pixel-level inspection, metadata parsing, and AI-driven anomaly detection. Supported file types: **JPEG, PNG, WebP** (up to 25 MB). Each file is securely uploaded to NiamonX’s processing server, analyzed through a FotoForensics-like API, and returned with visual and statistical breakdowns. The system enforces a **cooldown of 30 seconds per request** and allows up to **90 seconds for processing**. --- ### 🔍 Core Analysis Features 1. **Image Forensics (Visual Analysis)** The tool generates multiple forensic artifacts and comparisons: - **Original / Compressed Copy** - **Diff & Amplified Diff** (highlights pixel-level differences) - **Overlay & Artifact Grid** (visualizes edited regions) - **ELA (Error Level Analysis)** — identifies compression and tampering zones - **Noise Map** — isolates sensor and noise inconsistencies - **CASIA Prediction** — AI model inference from CASIA dataset to detect manipulation patterns 2. **EXIF & Metadata Extraction** Metadata is extracted using **PHP EXIF and ExifTool** modules, including: - Camera and software data - Creation timestamps - GPS coordinates (if embedded) - Editing traces and unusual tags - Hidden text or string data (binary text extraction) 3. **String Analysis** The tool detects **embedded ASCII or Unicode strings**, sometimes hidden within images. Long strings can indicate **metadata injection** or **hidden payloads**. 4. **GPS & Geolocation** If available, GPS coordinates are extracted and highlighted for quick mapping or cross-verification. --- ### ⚖️ Risk Score System Each image receives a **heuristic Risk Score**, assessing the likelihood of manipulation or sensitive content presence: - **High Risk:** GPS data present, strong ELA/diff indicators, suspicious or inconsistent tags. - **Medium Risk:** Rich EXIF metadata, CASIA neutral or borderline prediction, potential editing hints. - **Low Risk:** Minimal tags, no GPS, stable compression, and no visible tampering evidence. > ⚠️ The score is **heuristic** — not absolute proof — and should be interpreted as an analytical indicator rather than forensic certification. --- ### 🧠 Tips for Use - Hover the mouse over **artifact thumbnails** to use the built-in **magnifying glass (4x zoom)**. - Enable **auto-scroll** to jump to results automatically after processing. - Some files may return **partial artifacts** depending on compression level or EXIF structure. - Long embedded strings or missing ELA layers can be signals of **steganography** or **format re-encoding**. [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2025-11/scaled-1680-/JqFLdzSMv6EYEbHe-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2025-11/JqFLdzSMv6EYEbHe-image.png) --- ### 💾 Request History - Stored **locally only** (up to 50 entries). - Records include: filename, file size, GPS presence, calculated risk score, and main detected features. - No data or images are stored on NiamonX servers after processing completion. --- ### 🛡️ Security & Privacy All image uploads and forensic analyses are processed via **secure, encrypted channels**. The service never retains or shares the uploaded files or results. Each request is isolated and deleted after processing to maintain strict **data confidentiality** and **user privacy**. Users are encouraged to perform analyses only on **legally obtained images** and to respect privacy and consent regulations when handling visual materials. [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2025-11/scaled-1680-/8hUFmHuu8lPJHSyZ-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2025-11/8hUFmHuu8lPJHSyZ-image.png) --- ### 📬 Contact Information For inquiries, assistance, or data-related requests, contact the NiamonX team: - **support @ niamonx.io** — Technical Support - **other @ niamonx.io** — General Questions - **takedown @ niamonx.io** — Requests for Data Removal / Privacy Takedowns - **legal @ niamonx.io** — Legal or Compliance Matters Alternative contact channel: 🔗 **Helpdesk:** [https://support.niamonx.io/](https://support.niamonx.io/) --- In summary, **NiamonX Visual OSINT** is a **comprehensive image forensics platform** combining traditional EXIF metadata inspection, advanced artifact visualization, and AI-driven manipulation detection. It provides investigators with reliable insights into image authenticity and integrity — while maintaining the highest standards of **security, privacy, and digital ethics**. # Social Media Search [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2025-11/scaled-1680-/UvqOaXgfxrthhWsj-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2025-11/UvqOaXgfxrthhWsj-image.png) # Social Media Search — NiamonX **Link:** [https://dash.niamonx.io/social\_msearch](https://dash.niamonx.io/social_msearch) **What it is** The Social Media Search tool is a focused OSINT utility that generates and runs specialized search queries across social media domains using **Google Programmable Search Engine (GPSE)** combined with NiamonX query logic. It helps investigators, analysts, and researchers locate public social footprints quickly by applying network-specific filters, modifiers and heuristics — without scraping protected APIs. --- ## Key functionality - **Tab-based network filtering:** Switch between tabs for individual social networks (8 supported networks) or run in **All** mode to cover multiple platforms at once. - **Query types supported:** username, email, keywords, hashtags, mentions, and free-text phrases. - **Smart query generation:** The interface auto-builds site: and domain-specific queries for each social network using GPSE and NiamonX heuristics. - **Modifiers & presets:** Use exact-phrase (`"..."`), `@user`, `#tag`, `-excludedword` and other modifiers to refine results. Quick presets speed up common searches. - **Heuristic scoring:** Results are scored/filtered by a heuristic engine that highlights higher-probability matches (based on signal strength, domain match, recency and pattern matching). - **History & local storage:** Recent queries are stored locally in the browser (history, filters) for convenience — nothing is pushed to public indexes by the tool itself. - **Copying & export:** Ability to copy results and export structured lists for reporting or follow-up analysis. - **Token parameter:** An optional random token parameter can be appended to bypass aggressive caching (note: may reduce relevance). --- ## How the search works (high level) 1. You enter a basic query (username, email, keywords). 2. NiamonX constructs network-aware GPSE queries (site:facebook.com “username”, site:twitter.com @user, etc.) and applies modifiers you selected. 3. GPSE executes the search and returns results; NiamonX post-processes them with heuristic filters and presents ranked results in the UI. 4. You can switch tabs to view results restricted to a given social domain or view aggregated results in All mode. Because the tool relies on Google’s index, results depend on what Google has crawled and indexed for each social network. --- ## What you can search for - Public profiles by **username** or handle. - Mentions or posts containing **emails** or **keywords**. - **Hashtags** and topical content (`#tag`). - **Exact phrases** (use quotes) and exclusion filters (`-word`). - Quick multi-network scans (All mode) for footprint discovery. --- ## Limitations & important notes - **Depends on Google index:** not a replacement for direct API access to private or rate-limited platform data. If something isn’t on Google, the tool won’t find it. - **No protected-data access:** does not access private profiles or bypass platform protections. - **Token cache-bypass:** using the random token can force fresher Google results but may lower result relevance. - **Respect platform TOS:** you must comply with Google’s and target platforms’ terms of service. Abuse may result in blocked access. - **Local history only:** history is kept in the browser (not shared publicly); sensitive searches should be handled carefully. --- ## Best-practice tips - Use quotation marks for exact phrase matches. - Combine `@username` and `"username"` to cover different forms and variations. - Use `-word` to remove noisy sources from results. - Try All mode first for broad reconnaissance, then switch to a specific network tab to drill down. - If results look stale, re-run the query or tweak modifiers (Google index freshness varies). --- ## Privacy & security - The tool generates queries and shows results via GPSE; it does **not** harvest private data or bypass access controls. - Query history resides in the user’s browser. NiamonX post-processing applies heuristics but does not expose private platform data. - Use the tool only for lawful, authorized investigations and with respect for privacy. --- ## Contact / support For any questions, reporting issues, or compliance requests, contact the NiamonX team: - **support @ niamonx.io** — Technical Support - **other @ niamonx.io** — General Inquiries - **takedown @ niamonx.io** — Data removal / privacy takedowns - **legal @ niamonx.io** — Legal / compliance Alternative channel: **Helpdesk** → [https://support.niamonx.io/](https://support.niamonx.io/) # Brand Reputation [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2025-11/scaled-1680-/ZvD4pwUst7VhKp7v-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2025-11/ZvD4pwUst7VhKp7v-image.png) # **Brand Reputation — NiamonX** **Link:** [https://dash.niamonx.io/brand\_reputation](https://dash.niamonx.io/brand_reputation) **What it is** The **Brand Reputation** module is a next-generation AI-powered system for **brand perception auditing, sentiment tracking, and trust assessment**. It automatically gathers and analyzes public mentions of any company or brand name, evaluates overall tone and credibility, and generates a structured analytical report in under 90 seconds. Built on top of **NiamonX SearchGPT AI**, it processes large datasets from multiple open sources, performing sentiment analysis, contextual clustering, and reputation scoring — all securely and locally processed with end-to-end encryption. --- ## **Key Functionality** - **Automated Brand Intelligence:** Enter a brand or company name; the system collects public mentions from online sources and performs semantic tone analysis. - **Tone and Sentiment Detection:** Determines whether general sentiment is positive, neutral, or negative across aggregated mentions. - **Trust and Risk Analysis:** Evaluates credibility of sources, consistency of tone, and potential risks to brand trust. - **Comparative Analysis:** Allows comparing your brand’s score with competitors (e.g., “toom Baumarkt Germany” vs. “OBI Germany”). - **Comprehensive Report Generation:** Produces a Markdown-formatted summary with sections for tone overview, key quotes, trends, competitor metrics, and final evaluation. - **Local Query History:** Stores up to 200 recent searches locally (brand names and short previews only — no personal or external data). - **Copy & Download Options:** Instantly copy or export the report in `.txt` format for presentations or documentation. --- ## **How It Works** 1. You enter a **brand or company name** (e.g., “Alphabet Inc.” or “NiamonX”). 2. The engine collects relevant mentions from public data sources. 3. NiamonX AI performs a **multi-layer audit**: text clustering, tone detection, quote extraction, and trust scoring. 4. Within **30–90 seconds**, you receive a detailed Markdown report summarizing findings with sentiment breakdown, trend indicators, and confidence ratings. --- ## **What You Can Analyze** - **Corporate and consumer brands** (e.g., “IKEA”, “Tesla”, “Lufthansa”). - **Institutions or municipalities** (e.g., “Stadtwerke Hof”). - **Startups and emerging brands** (e.g., “NiamonX”). - **Cross-regional or industry-specific brands** (“toom Baumarkt Germany”, “Volksbank Berlin”). --- ## **Report Contents** - **Summary Overview** — concise snapshot of brand tone and reputation level. - **Tone Analysis** — positive, neutral, negative tone distribution with percentages. - **Quotes & Mentions** — key extracted phrases and examples. - **Trust & Source Evaluation** — assessment of data credibility and bias level. - **Competitor Comparison** — optional comparison with rival brands. - **Final Assessment** — heuristic reputation score from 0–100 (aggregated). Markdown rendering ensures each report is **visually clear, structured, and ready for presentation**. --- ## **Privacy & Security** - Data is **collected only from public sources** — no hidden APIs or unauthorized data scraping. - All queries and results are processed through a **secure encrypted channel**. - Local browser storage is used for history; no external telemetry or analytics. - Generated reports are transient — not shared or indexed anywhere. --- ## **Tips for Best Results** - Add **geographical or industry context** to the query (e.g., “toom Baumarkt Germany”, “Airbus Aerospace”). - Compare **multiple competitors** for benchmarking. - Export results as `.txt` or copy Markdown directly into reports. - Wait the full 90 seconds for the analysis to complete; large datasets require deep semantic evaluation. --- ## **Example Use Cases** - **PR & Marketing Teams:** Track brand health, press tone, and audience sentiment. - **Corporate Analysts:** Monitor changes in brand perception or response to public events. - **Investors:** Assess brand stability and public trust before funding decisions. - **Reputation Management Firms:** Automate large-scale audits using AI-based contextual scoring. --- ## **Contact / Support** For issues, assistance, or legal inquiries: Helpdesk: [https://support.niamonx.io](https://support.niamonx.io) # Reverse Image Search 18+ (OSINT) | Adult Public Model Image Intelligence [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/I35zQhbMJvJnERbG-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/I35zQhbMJvJnERbG-image.png) The platform available at **[https://dash.niamonx.io/reverse\_image\_search](https://dash.niamonx.io/reverse_image_search)** — known as **Reverse Image Search 18+ (OSINT)** — is a specialized 18+ image intelligence module within the NiamonX platform. It is designed to perform reverse image search against public adult-model sources and return structured, analyst-friendly matches for moderation, brand protection, content verification, and lawful OSINT analysis. ## 18+ Important Notice **Reverse Image Search 18+ is strictly limited to adult public-model analysis.** Users may only upload or submit images when they have a lawful and ethical right to analyze them. Any illegal, abusive, non-consensual, exploitative, or privacy-invasive use is strictly prohibited. The service is intended for: - Adult-content analytics - Platform moderation - Public model verification - Duplicate or repost detection - Brand and creator protection - Authorized OSINT investigation - Safety and compliance workflows The service must not be used for stalking, harassment, doxxing, deanonymization of private individuals, non-consensual identification, or analysis of minors. Any content involving minors is strictly prohibited. Misuse of the tool may result in immediate account blocking or termination. --- ## Overview of the Service **Reverse Image Search 18+ (OSINT)** allows users to search for visual matches across public adult webcam and model-related platforms. The tool accepts either an image URL or a local file upload and attempts to find visually similar public model records. The system returns a structured report containing potential matches, platform statistics, gender indicators, probability ratings, distance metrics, seen timestamps, account-seen timestamps, risk score, and links to available match views. The tool is built for analysts who need a clean, controlled, and reviewable interface for checking whether an adult public-model image appears across supported 18+ sources. Results are heuristic and should be interpreted carefully. A visual match does not automatically prove identity, ownership, consent status, or account control. --- ## 🔍 How the Search Works A user can start a search in one of two ways: - Submit an image URL - Upload a local image file Supported upload formats include: - JPEG - PNG - WebP - GIF Maximum file size: ```text 10 MB ``` If both a URL and a file are specified, the uploaded file has priority. For URL-based searches, the system may use a short cache window of approximately five minutes. This improves repeatability and avoids unnecessary repeated processing of the same URL. After the request is submitted, the backend creates a search job, processes the image, compares it against supported public 18+ model sources, and returns a ranked list of possible matches. --- ## 🧩 What Can Be Searched The tool supports reverse image analysis for adult public-model content only. Accepted inputs:
Input TypeDescription
Image URLDirect or supported image URL
Local file uploadJPEG, PNG, WebP, or GIF file
Adult public-model imagesImages that the user is authorized to analyze
Unsupported or prohibited inputs: - Images of minors - Private images without permission - Non-consensual intimate images - Images used for harassment or stalking - Images of private individuals for identification - Illegal sexual content - Screenshots or images submitted to bypass platform rules - Files larger than the supported limit - Unsupported file formats Users must ensure that every submitted image is lawful, authorized, and appropriate for adult-public-model analysis. --- ## ⚙️ Search Interface The main search interface includes several core controls. ### URL Images Users can paste an image URL. Example format: ```text https://... ``` URL searches may use short-term caching for repeatability. ### File Upload Users can upload a local image file. Supported formats: ```text jpeg / png / webp / gif ``` Maximum size: ```text 10 MB ``` If both URL and file are provided, the file upload is processed first. ### Search Limit The interface displays the current request limit and reset time. Example: ```text Limit: 59 / reset 600s ``` This helps users understand remaining availability and rate-limit reset timing. --- ## 📊 Results Section After a job is completed, the tool displays a structured results panel. Possible result fields include:
FieldDescription
MatchesTotal number of returned matches
Job IDUnique backend job identifier
StatusProcessing status, such as finished
CreatedJob creation timestamp
DurationBackend processing duration
RiskInternal risk score
Risk levelLow, medium, high, or another internal level
Platform statisticsMatch distribution by platform
Probability distributionProbability summary
Gender distributionf / m / c / u indicators
Distance metricsMinimum, average, and maximum distance
Job linkLink to the job report, when available
Example status structure: ```text Status: finished Duration: 1987 ms Matches: 20 Risk: 25 Low ``` The results should be treated as investigative leads and manually reviewed. --- ## 🧠 Key Features ### Reverse Image Search for 18+ OSINT The tool performs visual search against public adult-model sources and returns possible matches. ### URL or File Search Users can submit an image URL or upload a local file. ### File Priority Logic If both URL and file are submitted, the uploaded file is prioritized. ### Short-Term URL Cache URL searches may use an approximately five-minute cache window to improve repeatability and reduce unnecessary repeated processing. ### Job-Based Processing Each search creates a backend job with its own status, ID, creation timestamp, duration, and result set. ### Platform Statistics The system summarizes matches by source platform. Example platform statistics may appear in a compact format such as: ```text cb:10 mfc:3 c4:3 bc:2 sc:1 sm:1 ``` Platform labels are internal or source-specific abbreviations and should be interpreted according to the platform documentation or analyst context. ### Distance Metrics The tool provides distance values to help estimate visual similarity. The smaller the distance value, the closer the match according to the system’s heuristic. ### Probability Rating The probability field shows an external or backend-provided rating. This value may often be “low” and should not be treated as a final confidence conclusion by itself. ### Risk Score The risk score is a simple internal evaluation based on the saturation and characteristics of returned matches. It is intended for triage and prioritization, not as a legal or identity conclusion. ### Filtering Users can filter results by: - Platform - Probability - Gender - Maximum distance ### Export The current results table can be exported to CSV for internal review or case documentation. ### Metadata-Only History Request history stores only metadata such as URL hash or file hash. Images are not saved. --- ## 📋 Results Table The results table displays potential visual matches in a structured format. Main columns may include:
ColumnDescription
\#Result position
PlatformSource platform abbreviation
ModelPublic model/account name returned by the system
GenderGender indicator
DistanceVisual similarity distance
ProbabilityProbability rating
SeenFirst or related seen timestamp
AccountSeenAccount-level seen timestamp
LinksAvailable match views, such as Face or Full
Example link types: - **Face** — face-focused match view - **Full** — full-image or full-result view These links are intended for analyst review and should be accessed only for lawful, authorized purposes. --- ## 📏 Distance Interpretation The **Distance** value is one of the most important technical indicators in the report. General interpretation:
DistanceMeaning
Lower valueCloser visual match
Higher valueWeaker visual similarity
Similar rangeRequires manual comparison
Distance is heuristic. It does not prove identity, model ownership, account control, consent, or exact duplication. Analysts should compare multiple factors before making conclusions: - Face similarity - Full-image similarity - Platform source - Model/account name - Seen timestamp - AccountSeen timestamp - Probability rating - Result rank - Visual context - Duplicate patterns across platforms --- ## 🎯 Probability Interpretation The **Probability** field reflects an external or backend-provided rating. Common values may include: - Low - Medium - High - Unknown In many cases, returned results may be marked as “low,” even when the visual distance is close. Probability should therefore be interpreted together with distance, source platform, result rank, and manual review. A low probability does not automatically mean the result is irrelevant. A high probability does not automatically prove identity. --- ## 🚦 Risk Score The **Risk** value is an internal evaluation that helps summarize the saturation and possible relevance of returned matches. Example: ```text Risk 25 Low ``` Risk may consider signals such as: - Number of matches - Platform distribution - Distance range - Probability spread - Repeated model/account appearances - Density of similar results - Availability of face and full-image links Risk is intended for triage. It should not be used as a final judgment. --- ## 🧬 Gender Indicators The results may include gender indicators. Common values:
IndicatorMeaning
fFemale
mMale
cCouple
uUnknown
Gender indicators are source or model metadata signals and may not always be accurate. They should be treated as descriptive metadata, not identity verification. --- ## 🌐 Platform Statistics The platform statistics section summarizes how results are distributed across supported source platforms. Example: ```text Platforms cb:10 mfc:3 c4:3 bc:2 sc:1 sm:1 ``` This helps analysts understand whether matches are concentrated on one source or spread across multiple platforms. A high number of matches on one platform may suggest repeated appearances, duplicate records, or platform-specific similarity clustering. A broad spread across multiple platforms may require closer manual review. --- ## 🕒 Seen and AccountSeen The report may include two timestamp fields. ### Seen The **Seen** value usually refers to when a specific visual match, image, or record was observed by the source system. ### AccountSeen The **AccountSeen** value usually refers to when the related account or model profile was observed. These timestamps are useful for understanding historical presence and recency. They do not prove that the account is currently active. --- ## 🔗 Face and Full Links Results may provide links such as: - Face - Full These links help analysts review the matched content from different perspectives. ### Face A face-focused view may help compare facial similarity. ### Full A full-image view may help compare broader context, body position, background, outfit, image composition, or duplicated content. Analysts should use both views when available and avoid relying on a single visual cue. --- ## 💾 Request History The **Request History (18+)** section stores previous search metadata. Important privacy behavior: ```text Only stores search metadata (URL SHA1 / file SHA1). Images are not saved. ``` History may include: - Source type - Job ID - Number of matches - Platform summary - Top match names - File hash or URL hash - Risk score - Timestamp This allows users to review past searches without storing the original uploaded images. Request history should still be treated as sensitive metadata because it may reveal investigative activity. --- ## 📤 Export The export function dumps the current results table into CSV. CSV export may include: - Platform - Model/account name - Gender - Distance - Probability - Seen timestamp - AccountSeen timestamp - Links Exported files should be stored securely and shared only with authorized recipients. When used for moderation, compliance, or investigation, exports should follow internal data-handling policies. --- ## ✅ Recommended Analyst Workflow A careful review process should follow these steps. ### 1. Confirm Authorization Before uploading any image, confirm that the image is lawful to analyze and belongs to an adult public model or an authorized moderation workflow. ### 2. Choose Input Method Use either a URL or a local file. If both are submitted, remember that the file takes priority. ### 3. Run the Search Submit the request and wait for the job to finish. ### 4. Review the Summary Check match count, job status, duration, risk score, platform distribution, probability distribution, gender distribution, and distance range. ### 5. Sort by Distance Prioritize lower-distance results for manual review. ### 6. Check Face and Full Views Use both visual perspectives where available. ### 7. Compare Context Compare visual details, platform names, timestamps, and repeated matches. ### 8. Avoid Overclaiming Use cautious language such as “possible match,” “visual similarity,” or “candidate result” unless verified by additional evidence. ### 9. Export Only When Needed Export CSV only for authorized internal workflows. ### 10. Store Evidence Securely Treat all results, links, hashes, and exports as sensitive investigation material. --- ## 🛡️ Security, Privacy & Ethics Reverse Image Search 18+ is a sensitive tool and must be used responsibly. Strictly prohibited use includes: - Uploading images of minors - Searching for private individuals without consent or lawful basis - Uploading non-consensual intimate images - Harassment, stalking, or doxxing - Deanonymizing private people - Publishing or redistributing sensitive matches - Using results for blackmail, extortion, impersonation, or abuse - Attempting to bypass platform restrictions - Misrepresenting heuristic matches as verified identity proof Acceptable use cases include: - Authorized adult-content moderation - Public adult-model duplicate detection - Creator or brand protection - Lawful OSINT research - Safety review of public adult content - Internal compliance checks - Platform abuse investigation Users must manually verify results and interpret them as technical similarity signals, not final identity conclusions. --- ## ⚙️ Technical Highlights - 18+ reverse image search module - Designed for adult public-model OSINT only - Available at `dash.niamonx.io/reverse_image_search` - Supports image URL search - Supports local file upload - Supported formats: JPEG, PNG, WebP, GIF - Maximum upload size: 10 MB - File upload takes priority over URL when both are provided - URL request cache of approximately five minutes - Job-based backend processing - Job ID, status, creation time, and duration display - Match count - Internal risk score - Platform statistics - Probability distribution - Gender distribution - Distance metrics - Filters by platform, probability, gender, and maximum distance - Result table with platform, model, gender, distance, probability, timestamps, and links - Face and Full review links - CSV export - Request history stores only metadata - Images are not saved in request history - Intended for analytics, moderation, and authorized OSINT --- ## 📌 Usage Hints - Upload only lawful adult public-model images. - Do not upload private images unless you have the right to analyze them. - Never upload or analyze images involving minors. - Use lower distance values as stronger visual-similarity candidates. - Treat probability as an additional rating, not a final conclusion. - Use risk score for triage only. - Filter by platform, gender, probability, or maximum distance when reviewing many results. - Compare both Face and Full views when available. - Export CSV only for authorized internal use. - Remember that request history stores hashes and metadata, not images. - Treat all matches as investigative leads until manually verified. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or takedown-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Data Removal / Privacy Takedown Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX Reverse Image Search 18+ (OSINT)** is a specialized reverse image search tool for adult public-model intelligence, analytics, and moderation. It supports URL and file-based searches, compares images against supported public 18+ model sources, and returns structured results with platform statistics, visual distance metrics, probability ratings, gender indicators, risk score, timestamps, and review links. The tool is designed for lawful, ethical, adult-only analysis. It must never be used for private-person identification, non-consensual searches, minors, harassment, doxxing, or abuse. All matches should be treated as heuristic visual-similarity leads and manually verified before any conclusion or action. # Exif Remove and Metadata Privacy | Local Image Metadata Cleaner [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/Q8aJpM5uKYbWlwhN-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/Q8aJpM5uKYbWlwhN-image.png) The platform available at **[https://dash.niamonx.io/exif\_remove](https://dash.niamonx.io/exif_remove)** — known as **Exif Remove and Metadata Privacy** — is a privacy-focused image metadata inspection and cleaning tool within the NiamonX platform. It allows users to view, assess, export, and remove EXIF / metadata from images directly inside the browser, without sending image files to the server. ## Overview of the Service **Exif Remove and Metadata Privacy** is designed to help users protect themselves from accidental metadata exposure before publishing or sharing images online. Images often contain hidden technical metadata, including device model, camera settings, software name, creation date, orientation, thumbnails, GPS coordinates, serial numbers, and editing history. This information can reveal sensitive details about the person, device, location, or workflow behind the image. The tool allows users to inspect this metadata locally, assess privacy risk, remove metadata, optionally re-encode the image, and download a cleaned version. The main privacy advantage of this module is that processing happens locally in the user’s browser. Images are not uploaded to the NiamonX server for metadata extraction or deletion. --- ## 🔍 How the Tool Works When a user selects or drags an image into the tool, the browser reads the file locally and extracts available metadata. The tool then displays detected tags, risk indicators, file type, file size, and metadata categories. The user can review the information before cleaning the file. When metadata removal is requested, the tool redraws the image through the browser Canvas API. This creates a new image output without the original embedded EXIF metadata. Depending on the selected output settings, the tool can: - Keep the original format when possible - Convert to JPEG, PNG, or WebP - Adjust JPEG / WebP quality - Limit the long side of the image - Apply auto-orientation - Preserve transparency when supported - Remove metadata without unnecessary transcoding when the format matches - Export detected metadata as JSON - Process multiple files in bulk The cleaned file can then be downloaded and safely used for publishing, sharing, reporting, or documentation. --- ## 🧩 Supported File Types Exif Remove and Metadata Privacy supports common web image formats. Supported formats: - JPEG - PNG - WebP The interface may also accept common browser-supported image representations depending on browser capabilities, but the recommended formats are JPEG, PNG, and WebP. Recommended file size: ```text Up to approximately 50 MB per file ``` Unsupported or limited formats: - HEIC - RAW camera formats - Some proprietary image formats - Formats not supported by browser-side Canvas processing Newer formats such as HEIC and RAW are not supported on the Canvas side. --- ## 📁 Uploading Images The upload area allows users to drag files into the interface or click to select files manually. Example interface text: ```text Drag files here or click to select ``` Metadata is extracted locally after the file is selected. Important privacy behavior: ```text Images are not sent to the server. Metadata is extracted locally. ``` This makes the tool suitable for privacy-sensitive workflows where users need to inspect image metadata before publishing or transferring files. --- ## ⚙️ Output Settings The tool provides several output configuration options. ### Output Format Users can choose how the cleaned file should be saved. Typical option: ```text As the Original (auto) ``` This means the tool attempts to preserve the original format where possible. Other possible output formats may include: - JPEG - PNG - WebP Format choice affects file size, quality, transparency, and compatibility. --- ### Quality For JPEG and WebP outputs, users can select image quality. Example: ```text 92% ``` Recommended privacy-friendly and quality-balanced range: ```text 90–95% ``` Higher quality preserves more visual detail but may produce larger files. Lower quality reduces size but can introduce compression artifacts. --- ### Limit the Long Side Users can resize the image by limiting its longest side in pixels. Example: ```text Without scaling ``` A practical option before publishing online is to reduce the long side to a value such as: ```text 2048 px ``` This can reduce file size and limit unnecessary visual detail while preserving enough quality for web publishing. --- ### Auto-Orientation The tool can apply image orientation based on the original Orientation metadata. This is important because many photos rely on EXIF Orientation to display correctly. If metadata is removed without applying orientation, the image may appear rotated incorrectly. Auto-orientation helps preserve the visible appearance of the image after cleaning. --- ### Keep Transparency For images with transparency, such as PNG files, the tool can preserve alpha transparency when possible. Important note: If PNG is converted to JPEG, transparency is lost because JPEG does not support alpha channels. Recommended behavior: - Use PNG or WebP when transparency must be preserved. - Use JPEG when transparency is not required and smaller file size is preferred. --- ### Delete Only The “Delete only” option avoids unnecessary transcoding when the output format matches the original format. This is useful when the user wants to remove metadata with minimal visual change. However, depending on the browser and image format, some re-encoding may still be required to fully remove embedded metadata. --- ## 📊 File Summary After upload, the tool displays a quick summary. Example structure: ```text Files: 1 Cleaned: 0 Tags: 15 ``` For each image, the interface may show: - File name - MIME type - File size - Metadata tag count - Original metadata - Cleaned status - Risk category - Detected sensitive fields Example file information: ```text Type: image/jpeg Size: 1.2 MB Metadata: 15 tags ``` --- ## 🧾 Metadata Viewer The metadata viewer displays detected EXIF and image metadata in a structured format. Possible metadata fields include: - Orientation - Resolution - Resolution unit - Software - EXIF version - Color space - Pixel dimensions - Scene capture type - Thumbnail data - GPS coordinates - Device manufacturer - Device model - Lens information - Serial number - Creation date and time - Modification date and time - Editing software - Embedded preview or thumbnail Example metadata categories: ```text Software Orientation PixelXDimension PixelYDimension thumbnail ``` The metadata view is useful because it allows users to understand exactly what hidden information exists before removing it. --- ## 🚨 Why Metadata Removal Matters Image metadata can reveal more information than expected. Possible privacy-sensitive metadata:
Metadata TypePrivacy Risk
GPS coordinatesCan reveal home, workplace, travel route, or private location
Device modelCan identify the camera or phone used
Serial numberCan link multiple images to the same physical device
Creation date/timeCan reveal when the photo was taken
Software nameCan reveal editing tools or workflow
Embedded thumbnailCan contain an older version of the image
Orientation and dimensionsUsually low risk but still technical metadata
Author or copyright fieldsCan reveal identity or organization
File historyMay reveal editing or export chain
Before publishing images online, it is strongly recommended to check for GPS coordinates, serial numbers, device model, and creation time. --- ## 🧠 Risk Assessment The tool includes a metadata risk assessment system. Risk levels help users understand how sensitive the detected metadata may be. ### High Risk High-risk metadata may include: - GPS coordinates - Exact location data - Serial number - Exact time combined with device identifiers - Sensitive embedded thumbnails - Private author or owner fields Example risk interpretation: ```text High: GPS coordinates, exact time + serial number ``` High-risk images should be cleaned before publishing or sharing. --- ### Medium Risk Medium-risk metadata may include: - Device model - Camera manufacturer - Software name - Creation date - Editing date - Lens or device details Example risk interpretation: ```text Medium: Device model, software, creation date ``` Medium-risk fields may not reveal location directly, but they can still support tracking, correlation, or device fingerprinting. --- ### Info Informational metadata may include: - File size - Orientation - Resolution - Basic image dimensions - Color profile - Non-sensitive technical tags Example risk interpretation: ```text Info: Size, orientation, basic tags ``` Informational metadata is usually lower risk but can still be removed for maximum privacy. --- ## 🧹 Metadata Removal Method Exif Remove and Metadata Privacy removes metadata by redrawing the image in the browser Canvas. This process creates a clean image output from pixel data rather than copying the original file structure with embedded metadata. In practice, this helps remove: - EXIF tags - GPS tags - Camera metadata - Editing software metadata - Embedded thumbnail metadata - Many application-specific metadata blocks Important note: Some browser-generated outputs may still contain minimal format-level information required for valid images, but sensitive EXIF metadata is removed through the redraw/export process. --- ## 🔐 Local Processing and Privacy The tool is designed around local browser-side processing. Main privacy guarantees: - Images are processed locally in the browser. - Metadata extraction happens locally. - Metadata removal happens locally. - Images are not uploaded to the server. - Metadata is not sent to the server. - Request history is stored locally in the browser. This makes the tool suitable for privacy-conscious users, journalists, investigators, security teams, and anyone who needs to clean images before sharing them. --- ## 🕓 Request History The tool includes a local request history panel. Important behavior: ```text Stored only locally in the browser. No files or metadata are sent to the server. ``` The history may store up to a limited number of recent entries, such as: ```text Up to 50 entries ``` History entries may include: - File name - File size - Risk level - Detected metadata categories - Processing timestamp Example categories shown in history may include: - Info - Medium - Date - Device - Software The history is useful for reviewing recent local cleaning activity, but it should still be treated as sensitive local metadata on shared devices. --- ## 📤 JSON Export The tool can export detected metadata as JSON. This is useful for: - Documentation - Security review - Privacy audits - Before/after comparison - Evidence preservation - Developer testing - Internal reporting JSON exports may contain sensitive metadata. They should be stored securely and deleted when no longer needed. --- ## 📦 ZIP Upload and Bulk Processing The tool supports ZIP upload or bulk processing workflows when available. Bulk processing is useful when users need to clean multiple images before: - Publishing a gallery - Sending documentation - Uploading screenshots - Sharing evidence - Preparing website assets - Submitting images to public platforms When cleaning many files, users should still review high-risk images manually, especially those that may contain GPS or device identifiers. --- ## 📉 Size Comparison After cleaning or re-encoding images, the tool can help compare original and output file sizes. Size differences may occur because of: - Metadata removal - JPEG / WebP quality settings - Image resizing - Format conversion - Transparency preservation - Canvas re-encoding - Thumbnail removal A cleaned image may be much smaller if the original file contained large embedded metadata or thumbnail previews. --- ## 🖼️ Format and Quality Considerations ### JPEG Best for photos and general publishing. Pros: - Small file size - Broad compatibility - Adjustable quality Cons: - Lossy compression - No transparency - Repeated compression can reduce quality ### PNG Best for screenshots, logos, graphics, and transparency. Pros: - Supports transparency - Lossless visual quality - Good for UI images and graphics Cons: - Larger file size for photos - May not be ideal for large camera images ### WebP Best for modern web publishing. Pros: - Good compression - Supports transparency - Often smaller than JPEG or PNG Cons: - Compatibility depends on platform or workflow - Some older tools may not support it --- ## ⚠️ Re-Compression Warning Repeated compression can degrade image quality. For best results: - Clean and save the image once. - Avoid repeatedly opening and exporting the same JPEG. - Use quality around 90–95% for JPEG/WebP. - Keep the original private copy separately if needed. - Use PNG or WebP when transparency must be preserved. --- ## ✅ Recommended Privacy Workflow A careful image-cleaning workflow should follow these steps. ### 1. Upload the Image Locally Drag the file into the tool or select it manually. ### 2. Review Metadata Check all detected metadata before cleaning. ### 3. Look for High-Risk Tags Prioritize GPS, serial number, device model, creation time, and embedded thumbnails. ### 4. Choose Output Settings Select format, quality, orientation, resizing, and transparency options. ### 5. Remove Metadata Generate the cleaned image. ### 6. Compare File Size Review whether the cleaned image size changed significantly. ### 7. Download the Cleaned File Use the cleaned version for publishing or sharing. ### 8. Recheck If Needed Upload the cleaned image again to confirm that metadata was removed. ### 9. Store Originals Safely Keep original images private if they contain sensitive metadata. ### 10. Clear Local History on Shared Devices If using a shared or public computer, clear browser history and local storage after processing. --- ## 🛡️ Security, Privacy & Ethics Exif Remove and Metadata Privacy is designed for privacy protection, responsible publishing, and safe image sharing. Acceptable use cases include: - Removing GPS coordinates before publishing photos - Cleaning screenshots before sharing them - Protecting device information - Preparing images for public websites - Reducing metadata exposure in reports - Sanitizing investigation images - Removing editing history from exported graphics - Checking images before social media upload - Cleaning images before sending to third parties Users should use the tool responsibly: - Do not rely on metadata removal to hide illegal activity. - Do not alter evidence in contexts where original metadata must be preserved. - Keep original files when forensic integrity is required. - Do not publish sensitive images without consent. - Do not remove metadata from files that must remain legally auditable. - Use proper evidence-handling workflows for legal, compliance, or forensic cases. For forensic or legal investigations, metadata removal should be performed only on working copies, never on original evidence. --- ## ⚙️ Technical Highlights - EXIF and metadata viewer - Metadata removal for images - Local browser-side processing - Images are not sent to the server - Metadata is not sent to the server - Supports JPEG, PNG, and WebP - Recommended size up to approximately 50 MB per file - Output format selection - JPEG / WebP quality control - Long-side resize option - Auto-orientation support - Transparency preservation for PNG / WebP workflows - Delete-only mode when format matches - Metadata tag counter - Risk assessment system - JSON metadata export - Size comparison - Local request history - History stored only in browser local storage - Up to 50 local history entries - Bulk / ZIP workflow support - Canvas-based metadata deletion - HEIC and RAW not supported on Canvas side --- ## 📌 Usage Hints - Always check for GPS before publishing photos. - Check device model, serial numbers, software, and creation time. - Use quality 90–95% for JPEG/WebP in most cases. - Reduce the long side, such as 2048 px, for web publishing. - Preserve transparency when cleaning PNG logos or screenshots. - Avoid PNG to JPEG conversion if transparency matters. - Avoid repeated recompression. - Save only once when possible. - Re-upload the cleaned file to verify metadata removal. - Clear local history on shared devices. - Keep original evidence unchanged if forensic integrity matters. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or takedown-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Data Removal / Privacy Takedown Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX Exif Remove and Metadata Privacy** is a local browser-based privacy tool for inspecting and removing EXIF / metadata from JPEG, PNG, and WebP images. It helps users detect sensitive metadata such as GPS coordinates, device model, serial number, software, creation time, thumbnails, and other hidden tags before publishing images online. The tool processes files locally, does not send images or metadata to the server, supports output format and quality control, provides risk assessment, enables JSON export, and stores only local browser history. It is designed for privacy protection, safer publishing, security workflows, and responsible image handling. # Flight Information | Flight Search & Aviation Intelligence [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/TrDuwsHUyOOMPhXu-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/TrDuwsHUyOOMPhXu-image.png) The platform available at **[https://dash.niamonx.io/flightinfo](https://dash.niamonx.io/flightinfo)** — known as **Flight Information** — is an aviation intelligence and flight lookup tool within the NiamonX platform. It allows users to search for flight information by IATA or ICAO flight number and receive a structured report with route, status, departure details, arrival details, aircraft data, telemetry fields, timestamps, and local browser-based request history. ## Overview of the Service **Flight Information** is designed to help users quickly check the current or recent status of a commercial or private flight using standard aviation flight identifiers. The tool supports both **IATA** and **ICAO** flight number formats and can automatically detect the correct query mode. It returns a clean, structured flight summary that is useful for aviation monitoring, travel verification, logistics coordination, OSINT workflows, executive protection, airport operations review, and general flight status checks. The interface is built to be simple and fast. A user enters a flight number, selects or keeps auto-detection mode, and receives a readable flight report containing departure and arrival airports, gates, terminals, scheduled or updated times, status, route, and available aircraft or telemetry fields. Access depends on the user’s plan and daily tool limits. --- ## 🔍 How the Search Works When a user enters a flight number, the tool checks the query using the selected mode. Available modes include: - Auto detect - IATA - ICAO In **Auto detect** mode, the system attempts to determine whether the entered value is an IATA-style or ICAO-style flight number. Examples: ```text AA6 ``` ```text AAL6 ``` The backend then returns available flight information and displays it in a structured format. If the flight is found, the report may include: - Flight number - Route - Current status - Departure airport - Departure terminal - Departure gate - Departure local time - Departure UTC time - Departure update timestamp - Arrival airport - Arrival terminal - Arrival gate - Baggage belt - Arrival local time - Arrival UTC time - Arrival update timestamp - Aircraft registration - Aircraft type - Aircraft model - Aircraft manufacturer - Engine information - Build year and age - Aircraft HEX - MSN - Telemetry fields - Request history entry --- ## 🧩 What Can Be Searched Flight Information is intended for flight number lookup. Supported query types:
Query TypeExampleDescription
IATA flight number`AA6`Airline IATA code + flight number
ICAO flight number`AAL6`Airline ICAO code + flight number
Auto-detected flight number`IB8539`The system detects the likely mode
The user should enter only the flight identifier. Recommended input examples: ```text IB8539 ``` ```text SK2624 ``` ```text SAS2624 ``` Unsupported input examples: ```text Miami to Newark ``` ```text MIA EWR 17 June ``` ```text https://example.com/flight/IB8539 ``` ```text American Airlines flight from Miami tomorrow ``` For best results, users should enter a clean IATA or ICAO flight number. --- ## ⚙️ Controls and Interface The Flight Information interface includes several core sections. ### Controls The controls area shows search mode, filters, query limits, and client-side interface status. Example indicators: ```text Auto-detect · Filters Client-side ``` ### Query Counter The query counter shows remaining and total daily requests. Example: ```text 148 / 150 Queries remaining / total Plan: Sentinel ``` This helps users understand how many flight searches remain under the current plan. ### Find Flight The **Find Flight** section is the main search area. It contains: - Mode selector - Query input - Example queries - Search action Example: ```text Mode: Auto detect Query: IB8539 ``` --- ## 📊 Flight Result Summary After a successful lookup, the tool displays the flight route and status. Example structure: ```text IB8539 MIA → EWR Status: en-route 2026-06-17 18:46:52 UTC ``` The summary helps the user quickly understand: - Which flight was found - Origin and destination - Current flight status - Last report or lookup time Common flight statuses may include: - Scheduled - En-route - Landed - Delayed - Cancelled - Unknown - Diverted The exact statuses depend on the data returned by the backend source. --- ## 🛫 Departure Section The **Departure** section contains information about the origin airport and departure event. Possible fields include:
FieldDescription
AirportDeparture airport in IATA and ICAO format
TerminalDeparture terminal
GateDeparture gate
Time localLocal departure time at the airport
Time UTCDeparture time converted to UTC
Updated UTCLast update timestamp for departure data
Example departure structure: ```text Airport: MIA (KMIA) Terminal: N Gate: D10 Time local: 2026-06-17 13:35 Time UTC: 2026-06-17 17:35 Updated UTC: 2026-06-17 17:30 ``` This section is useful for confirming where the flight departed from, whether gate or terminal information is available, and whether departure timing has been updated. --- ## 🛬 Arrival Section The **Arrival** section contains information about the destination airport and arrival event. Possible fields include:
FieldDescription
AirportArrival airport in IATA and ICAO format
TerminalArrival terminal
GateArrival gate
BaggageBaggage belt or claim area
Time localLocal arrival time at the airport
Time UTCArrival time converted to UTC
Updated UTCLast update timestamp for arrival data
Example arrival structure: ```text Airport: EWR (KEWR) Terminal: A Gate: 11 Baggage: 4 Time local: 2026-06-17 16:39 Time UTC: 2026-06-17 20:39 Updated UTC: 2026-06-17 20:23 ``` This section is especially useful for travel coordination, passenger pickup planning, logistics, and airport operations review. --- ## ✈️ Aircraft Section The **Aircraft** section displays available aircraft-related information. Possible fields include:
FieldDescription
RegistrationAircraft tail number or registration
ICAO TypeICAO aircraft type code
ModelAircraft model
ManufacturerAircraft manufacturer
EnginesEngine information
Built / AgeBuild year and aircraft age
HEXAircraft Mode-S / ADS-B hex identifier
MSNManufacturer serial number
Some fields may be unavailable depending on the data provider, flight type, aircraft tracking availability, or privacy restrictions. If aircraft details are unavailable, the interface may show: ```text — ``` This means the field was not returned or could not be confirmed for the selected flight. --- ## 📡 Telemetry Section The **Telemetry** section displays live or recent aircraft movement data when available. Possible telemetry fields include:
FieldDescription
PositionCurrent or last known position
HeadingDirection of travel
AltitudeCurrent or last known altitude
SpeedGround speed or reported speed
V-SpeedVertical speed
SquawkTransponder squawk code
If telemetry is unavailable, the tool may display empty fields or placeholder values. Telemetry availability can depend on: - Aircraft ADS-B visibility - Data provider support - Flight status - Privacy filtering - Regional coverage - Time since last update - Aircraft type - Military, private, or restricted flight settings Telemetry should be treated as informational and may not always be real-time. --- ## 🧾 Result Table The tool may also display a compact row-based result table. A row may include: - Flight number - Route - Status - Departure UTC time - Arrival UTC time - Aircraft fields - Lookup timestamp Example compact format: ```text IB8539 MIA → EWR en-route 2026-06-17 17:35 2026-06-17 20:39 ``` The table can help users compare repeated lookups or scan recent results quickly. Users can click a column header to sort results when sorting is available in the interface. --- ## 🕓 Request History The **Request History** section stores recent searches locally in the user’s browser. Example history behavior: ```text Stores last 100 queries in your browser. ``` History entries may include: - Search mode - Original query - Normalized flight number - Route - Lookup timestamp - Flight status - Result metadata Example history item: ```text auto IB8539 MIA → EWR 17.06.2026, 21:35:37 ``` Request history is useful for quickly revisiting previous flight checks without retyping the flight number. Because the history is stored in the browser, it may be cleared if the user deletes browser data, switches devices, or uses another browser profile. --- ## 🧠 Key Features ### IATA and ICAO Search The tool supports both common flight identifier formats. ### Auto-Detection Auto mode attempts to detect whether the query is IATA or ICAO. ### Structured Flight Report Results are displayed in a readable layout with departure, arrival, aircraft, and telemetry sections. ### Local and UTC Times The report shows both local airport time and UTC time when available. ### Gate, Terminal, and Baggage Details The tool can display airport operation details such as terminal, gate, and baggage claim. ### Aircraft Details When available, the report includes aircraft registration, type, model, manufacturer, engines, HEX, and MSN. ### Telemetry Fields The tool can display position, heading, altitude, speed, vertical speed, and squawk when available. ### Client-Side Controls Filtering and interface controls are handled client-side for a fast user experience. ### Request History The last 100 queries are stored locally in the browser. ### Plan-Based Access Daily query limits depend on the user’s plan. --- ## 🚦 Daily Queries and Plan Limits Flight Information uses plan-based daily query limits. Example: ```text 148 / 150 Queries remaining / total Plan: Sentinel ``` Limits help control usage, protect backend availability, and provide predictable access across user plans. Users should monitor the remaining query counter when performing multiple searches. --- ## 🧭 IATA vs ICAO Flight Information supports both IATA and ICAO flight identifiers. ### IATA Flight Number IATA flight numbers usually use a two-character airline code followed by a flight number. Example: ```text AA6 ``` ### ICAO Flight Number ICAO flight numbers usually use a three-letter airline code followed by a flight number. Example: ```text AAL6 ``` ### Auto Detect Auto-detect mode tries to determine the correct format automatically. If the result seems incorrect or no flight is found, users can manually switch between IATA and ICAO mode. --- ## 🧠 Result Interpretation Flight data should be interpreted carefully. Important interpretation notes: - Flight status can change quickly. - Gate and terminal assignments may change before departure or arrival. - Arrival times may be estimated and updated during flight. - Aircraft information may be unavailable for some flights. - Telemetry may be delayed, missing, or privacy-filtered. - Local times are based on airport time zones. - UTC times are useful for cross-region comparison. - A missing field does not always mean the information does not exist; it may simply not be returned by the provider. The tool is useful for fast lookup and monitoring, but critical operational decisions should be confirmed with the airline, airport, or official aviation data source when necessary. --- ## ✅ Recommended Workflow A practical flight lookup workflow should follow these steps. ### 1. Enter the Flight Number Use a clean IATA or ICAO flight number. ### 2. Start With Auto Detect Use Auto detect first unless you already know the identifier type. ### 3. Review the Route Confirm that the origin and destination match the expected flight. ### 4. Check the Status Look for status such as scheduled, en-route, landed, delayed, or cancelled. ### 5. Review Departure Details Check departure airport, terminal, gate, local time, UTC time, and update timestamp. ### 6. Review Arrival Details Check arrival airport, terminal, gate, baggage belt, local time, UTC time, and update timestamp. ### 7. Check Aircraft and Telemetry Use aircraft and telemetry fields when available, but remember that they may be incomplete. ### 8. Save or Reuse History Use local request history to revisit previous queries. ### 9. Verify Critical Details For time-sensitive travel, logistics, or operational decisions, confirm with official airline or airport sources. --- ## 🛡️ Security, Privacy & Responsible Use Flight Information is intended for lawful aviation information lookup and operational awareness. Acceptable use cases include: - Checking your own flight - Travel planning - Passenger pickup coordination - Logistics monitoring - Aviation OSINT - Airport operations review - Corporate travel monitoring - Incident response support - Executive protection workflows - Historical query review Users should follow responsible use principles: - Do not use flight information for stalking, harassment, or physical harm. - Do not misuse aircraft or route data to target individuals. - Do not assume telemetry is perfectly live or complete. - Do not make safety-critical decisions from a single data point. - Verify important travel or operational details with official sources. - Treat local request history as potentially sensitive on shared devices. --- ## ⚙️ Technical Highlights - Flight lookup module - Available at `dash.niamonx.io/flightinfo` - Supports IATA flight numbers - Supports ICAO flight numbers - Auto-detect mode - Client-side controls and filters - Plan-based daily query limits - Structured flight report - Route display - Flight status display - Departure airport, terminal, gate, local time, UTC time, and update timestamp - Arrival airport, terminal, gate, baggage, local time, UTC time, and update timestamp - Aircraft registration, type, model, manufacturer, engines, build year, age, HEX, and MSN when available - Telemetry fields for position, heading, altitude, speed, vertical speed, and squawk when available - Sortable result table - Local browser request history - Stores last 100 queries in the browser - Suitable for travel, logistics, OSINT, corporate monitoring, and aviation awareness workflows --- ## 📌 Usage Hints - Enter IATA flight numbers like `AA6`. - Enter ICAO flight numbers like `AAL6`. - Use Auto detect when unsure. - If a result looks wrong, manually switch between IATA and ICAO mode. - Check both local and UTC times. - Review update timestamps to understand data freshness. - Gate, terminal, and baggage details can change. - Telemetry may be unavailable or delayed. - Click column headers to sort result tables when available. - Access depends on your plan and daily tool limits. - Request history is stored locally in the browser. - Clear browser data on shared devices if flight history is sensitive. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX Flight Information** is a flight lookup and aviation intelligence tool that allows users to search for flights by IATA or ICAO identifier and receive a structured report with route, status, departure details, arrival details, aircraft fields, telemetry fields, timestamps, and local request history. The tool is designed for travel verification, logistics support, aviation OSINT, corporate monitoring, passenger coordination, and operational awareness. Results should be treated as informational and verified with official airline or airport sources for critical decisions. # Flight Schedules | Departures, Arrivals & Airline Schedule Intelligence [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/VwV4CUrLy1kCBkD2-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/VwV4CUrLy1kCBkD2-image.png) The platform available at **[https://dash.niamonx.io/flight\_schedules](https://dash.niamonx.io/flight_schedules)** — known as **Flight Schedules** — is a flight schedule intelligence tool within the NiamonX platform. It allows users to search real-time airport schedules by departure airport, arrival airport, airline, specific flight number, flight status, and delay filters. ## Overview of the Service **Flight Schedules** provides a structured view of current and near-future flight movements. The tool is designed to show departure and arrival queues for up to approximately 12 hours ahead, depending on the available data source and selected filters. Unlike a single-flight lookup tool, Flight Schedules is built for broader schedule monitoring. It helps users analyze groups of flights from or to a specific airport, filter by airline, search for a specific flight, review operational status, identify delays, and export results for further analysis. The module is useful for travel coordination, logistics, aviation OSINT, airport monitoring, corporate travel tracking, incident response support, executive protection workflows, and operational awareness. Access depends on the user’s plan and daily tool limits. --- ## 🔍 How the Search Works The user selects one or more search fields and submits a schedule query. The system then searches the flight schedule database and returns matching flights in a structured table. The tool supports multi-criteria search, meaning users can combine multiple filters to narrow results. Example search combinations: - Departure airport only - Arrival airport only - Departure airport + airline - Arrival airport + airline - Departure airport + arrival airport - Specific flight number - Airport + flight status - Airport + minimum delay - Airline + status - Airline + route For example, a user can search all departures from Miami International Airport using: ```text Departure IATA: MIA ``` Or combine filters such as: ```text Departure IATA: MIA Airline IATA: AA Status: active ``` The result is a schedule table with flight numbers, route, airline, status, departure and arrival times, terminal and gate details, flight duration, and delay indicators when available. --- ## 🧩 What Can Be Searched Flight Schedules supports several search fields. ### Departure Airport Users can search by departure airport using either IATA or ICAO code. Examples: ```text MIA ``` ```text KMIA ``` ### Arrival Airport Users can search by arrival airport using either IATA or ICAO code. Examples: ```text SFO ``` ```text KSFO ``` ### Airline Users can filter by airline using IATA or ICAO airline code. Examples: ```text AA ``` ```text AAL ``` Multiple airlines can be entered as a comma-separated list. Example: ```text AA,BA,DL ``` ### Flight Number Users can search for a specific flight by IATA or ICAO flight number. Examples: ```text AA2421 ``` ```text AAL2421 ``` ### Status Users can filter schedules by operational status. Possible values may include: - Any - Active - Scheduled - Landed - Cancelled - Delayed - Unknown The exact available statuses depend on backend data. ### Delay Filter Users can search for flights with delay greater than or equal to a selected number of minutes. Example: ```text Delay ≥ 30 ``` This is useful for quickly identifying disrupted flights. --- ## ⚙️ Search Interface The Flight Schedules interface contains several main search controls. ### Departure IATA Search by departure airport IATA code. Example: ```text MIA ``` ### Departure ICAO Search by departure airport ICAO code. Example: ```text KMIA ``` ### Arrival IATA Search by arrival airport IATA code. Example: ```text SFO ``` ### Arrival ICAO Search by arrival airport ICAO code. Example: ```text KSFO ``` ### Airline IATA Filter by one or more airline IATA codes. Example: ```text AA,BA ``` ### Airline ICAO Filter by one or more airline ICAO codes. Example: ```text AAL,BAW ``` ### Flight IATA Search by IATA-style flight number. Example: ```text AA2421 ``` ### Flight ICAO Search by ICAO-style flight number. Example: ```text AAL2421 ``` ### Status Filter by flight status. Default value: ```text Any ``` ### Delay ≥ Filter flights with a delay greater than or equal to the selected number of minutes. Example: ```text 30 ``` --- ## 📊 Schedule Results After a successful search, the tool displays a schedule summary and a table of matching flights. The summary may include: - Search filter used - Timestamp of the query - Number of results - Number of airlines - Departure airport - Destination airports - Time window - Result table Example summary structure: ```text DEP_IATA: MIA Results: 100 Airlines: 37 From: MIA To: DTW, DCA, MCO, MGA, PHL, BWI, YYZ Window: 2026-06-17 13:00 UTC → 2026-06-18 00:08 UTC ``` This gives users a fast overview of the searched airport schedule and the range of returned flights. --- ## 📋 Results Table The main results table displays flight records in a compact operational format. Typical columns may include:
ColumnDescription
FlightFlight number
AirlineAirline IATA code
RouteDeparture and arrival airports
StatusFlight status
Departure timeScheduled or updated departure time
Arrival timeScheduled or updated arrival time
Departure terminal / gateDeparture terminal and gate
Arrival terminal / gateArrival terminal and gate
DurationFlight duration in minutes
Departure delayDeparture delay, if available
Arrival delayArrival delay, if available
Example row: ```text AA3310 AA MIA → DCA active 2026-06-17 17:41 2026-06-17 20:25 N / D38 2 / C32 164 ``` The table is intended for quick scanning and comparison. Users can click column headers to sort results when sorting is available. --- ## 🛫 Departures When searching by departure airport, the tool shows flights leaving the selected airport within the current schedule window. Departure-focused use cases: - Checking airport departure queue - Monitoring outbound flights - Reviewing gate assignments - Checking airline activity from an airport - Identifying delayed departures - Tracking specific outbound routes - Exporting airport departure lists Example: ```text Departure IATA: MIA ``` This returns flights departing from Miami International Airport. --- ## 🛬 Arrivals When searching by arrival airport, the tool shows flights arriving at the selected airport within the current schedule window. Arrival-focused use cases: - Passenger pickup planning - Airport arrival monitoring - Logistics coordination - Delay tracking - Airline arrival filtering - Destination airport analysis Example: ```text Arrival IATA: EWR ``` This returns flights arriving at Newark Liberty International Airport. --- ## 🏢 Airline Filtering The tool supports airline filtering by IATA or ICAO code. This is useful when users need to focus on one airline or a group of airlines. Example: ```text Airline IATA: AA,BA ``` This can return only flights operated or listed under American Airlines and British Airways codes, depending on backend data. Airline filtering is especially useful for: - Airline operations review - Codeshare analysis - Corporate travel monitoring - Disruption analysis - Airport activity by carrier --- ## ✈️ Flight Number Search Users can search for a specific flight using IATA or ICAO flight number fields. Examples: ```text Flight IATA: EK164 ``` ```text Flight ICAO: UAE164 ``` This is useful when a user wants schedule-table context for one specific flight rather than a full airport queue. If the exact flight is not found, users should verify whether the flight number is IATA or ICAO and try the matching field. --- ## ⏱️ Time Window Flight Schedules shows the current queue for up to approximately 12 hours ahead. The result summary may show the schedule window in UTC. Example: ```text Window: 2026-06-17 13:00 UTC → 2026-06-18 00:08 UTC ``` The time window helps users understand which period is covered by the returned results. Important interpretation notes: - The schedule window may shift depending on current time and backend data. - Results may include active, landed, scheduled, or delayed flights. - UTC is useful for cross-time-zone comparison. - Local airport times may differ from the displayed UTC values depending on interface configuration. --- ## 🧠 Key Features ### Multi-Criteria Search Users can combine departure airport, arrival airport, airline, flight number, status, and delay filters. ### Departure and Arrival Monitoring The tool supports both outbound and inbound schedule analysis. ### Airline Filtering Users can filter by one or more airlines using comma-separated codes. ### Specific Flight Lookup The module supports direct flight number filtering. ### Status Filtering Users can narrow results by operational status. ### Delay Filtering The delay filter helps identify flights with disruption above a selected threshold. ### Sortable Results Users can sort schedule rows by table columns. ### CSV Export Schedule results can be exported to CSV for spreadsheets, reporting, or operational workflows. ### TXT Export Flight codes can be exported as TXT for simple lists, scripts, or copy-paste workflows. ### Local Request History The last 100 schedule queries are stored locally in the browser. ### Plan-Based Limits Daily query limits depend on the user’s subscription plan and are enforced server-side. --- ## 📤 Export Options Flight Schedules supports export for operational and analytical workflows. ### CSV Export CSV export is useful for: - Spreadsheet analysis - Reporting - Airport operations review - Logistics planning - Delay tracking - Airline comparison - Internal documentation ### TXT Export TXT export can provide a plain list of flight codes. This is useful for: - Quick sharing - Batch checking - Operational watchlists - Copying flight numbers into another tool - Lightweight reporting Exported files should be stored appropriately when they contain operationally sensitive travel information. --- ## 🕓 Request History The **Request History** section stores the last 100 queries in the user’s browser. History entries may include: - Departure filter - Arrival filter - Airline filter - Flight filter - Query timestamp - Route summary - Search mode or selected fields Example history entry: ```text MIA → — Airlines: any Flight: any 17.06.2026, 21:37:41 ``` Request history is stored locally and helps users quickly repeat previous searches. Because it is browser-based, history may be cleared when the user deletes local browser data or switches devices. --- ## 🚦 Daily Queries and Plan Limits Flight Schedules uses plan-based query limits. Example: ```text 148 / 150 Queries remaining / total Plan: Sentinel ``` Important points: - Access depends on the user’s plan. - Daily tool limits are enforced server-side. - Users should monitor remaining queries when performing many searches. - Exporting already loaded data does not necessarily require a new schedule query. --- ## 🧭 IATA and ICAO Codes The tool supports both IATA and ICAO code formats. ### Airport Codes IATA airport codes are usually three letters. Examples: ```text MIA SFO EWR ``` ICAO airport codes are usually four letters. Examples: ```text KMIA KSFO KEWR ``` ### Airline Codes IATA airline codes are usually two characters. Examples: ```text AA BA DL ``` ICAO airline codes are usually three letters. Examples: ```text AAL BAW DAL ``` ### Flight Numbers IATA flight numbers usually start with an IATA airline code. Example: ```text AA2421 ``` ICAO flight numbers usually start with an ICAO airline code. Example: ```text AAL2421 ``` Using the correct code type improves result accuracy. --- ## 🧠 Result Interpretation Flight schedule data should be interpreted as operational information that may change quickly. Important notes: - Gates can change before departure or arrival. - Terminals can change due to operational conditions. - Delay values may update frequently. - Codeshare flights may appear as multiple flight numbers for the same physical flight. - Airline filters may include codeshare or marketing flight numbers depending on backend data. - A missing field does not always mean the information does not exist; it may simply not be returned. - Schedule windows are time-limited and should not be interpreted as a full-day flight list. - For critical travel or logistics decisions, confirm with official airline or airport sources. Codeshare behavior is especially important. Multiple airlines may show identical route, time, terminal, and gate information because they refer to the same operating flight under different marketing flight numbers. --- ## ✅ Recommended Workflow A practical schedule search workflow should follow these steps. ### 1. Choose the Search Field Select whether you want to search by departure, arrival, airline, flight number, status, or delay. ### 2. Enter Airport or Airline Codes Use IATA or ICAO codes depending on the field. ### 3. Combine Filters When Needed For example, use departure airport plus airline code to narrow results. ### 4. Review the Summary Check number of results, airlines, route coverage, and time window. ### 5. Sort the Table Sort by departure time, arrival time, status, airline, route, or delay. ### 6. Identify Codeshares Look for rows with identical route and times but different airline codes. ### 7. Check Delays Use the delay filter or delay columns to identify disruptions. ### 8. Export Results Export CSV for structured analysis or TXT for flight code lists. ### 9. Use History for Repeated Queries Open recent searches from browser history when checking the same airport repeatedly. ### 10. Verify Critical Data Confirm important travel or operational decisions through official sources. --- ## 🛡️ Security, Privacy & Responsible Use Flight Schedules is intended for lawful aviation schedule lookup and operational awareness. Acceptable use cases include: - Airport departure monitoring - Airport arrival monitoring - Travel planning - Passenger pickup coordination - Logistics planning - Airline schedule review - Aviation OSINT - Corporate travel monitoring - Incident response support - Executive protection workflows - Delay analysis - Exporting operational flight lists Users should follow responsible use principles: - Do not use schedule data for stalking, harassment, or physical harm. - Do not misuse flight data to target individuals. - Do not treat schedule data as perfectly real-time or complete. - Do not make safety-critical decisions based only on one source. - Verify important travel, airport, or operational data with official sources. - Treat local request history as potentially sensitive on shared devices. --- ## ⚙️ Technical Highlights - Flight schedule search module - Available at `dash.niamonx.io/flight_schedules` - Real-time schedule database - Shows current queue for up to approximately 12 hours ahead - Supports departures and arrivals - Supports airport IATA and ICAO filters - Supports airline IATA and ICAO filters - Supports specific flight IATA and ICAO filters - Supports status filtering - Supports minimum delay filtering - Multi-criteria search - Comma-separated airline filtering - Client-side controls - Sortable result table - CSV export - TXT export for flight codes - Local browser request history - Stores last 100 queries in the browser - Plan-based daily query limits - Server-side limit enforcement - Suitable for aviation monitoring, travel coordination, logistics, OSINT, and operational awareness --- ## 📌 Usage Hints - Select which field you want to search by. - Use Departure IATA for airport departure queues. - Use Arrival IATA for airport arrival queues. - Use ICAO codes when IATA results are ambiguous. - Combine filters, such as departure airport plus airline IATA. - Use comma-separated airline codes to filter multiple carriers. - Use status filtering to focus on active, landed, scheduled, or delayed flights. - Use Delay ≥ to find disrupted flights. - Sort by any column for faster analysis. - Export CSV for full schedule analysis. - Export TXT when you only need flight codes. - Remember that schedule data can change quickly. - Access depends on your plan and daily tool limits. - Local request history stores the last 100 queries in your browser. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX Flight Schedules** is a real-time flight schedule intelligence tool for searching departures, arrivals, airlines, specific flights, statuses, and delays. It supports multi-criteria search by airport IATA / ICAO, airline IATA / ICAO, flight IATA / ICAO, operational status, and minimum delay. The tool returns structured schedule tables with routes, times, terminals, gates, durations, delays, result summaries, export options, and browser-based request history. Flight Schedules is designed for travel coordination, airport monitoring, aviation OSINT, logistics, corporate travel visibility, and operational awareness. Results should be treated as informational and verified with official airline or airport sources when used for critical decisions. # Flight Delay | Real-Time Flight Delay Monitoring [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/BdDKXTvV1UB4Lotq-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/BdDKXTvV1UB4Lotq-image.png) The platform available at **[https://dash.niamonx.io/flight\_delay](https://dash.niamonx.io/flight_delay)** — known as **Flight Delay** — is a real-time aviation delay monitoring tool within the NiamonX platform. It allows users to track delayed departures and arrivals worldwide, filter results by airport, airline, flight number, status, and minimum delay threshold, and export delay intelligence for operational analysis. ## Overview of the Service **Flight Delay** is designed to help users monitor current flight disruptions in real time. The tool provides a structured view of delayed flights and allows users to focus on departures, arrivals, specific airports, airlines, routes, or individual flight numbers. Unlike general flight search, which focuses on one flight, and flight schedules, which shows a broader airport queue, Flight Delay is optimized for disruption monitoring. It highlights flights affected by delay conditions and helps analysts quickly identify where operational problems are occurring. The tool is useful for: - Airport operations monitoring - Airline disruption analysis - Passenger coordination - Logistics and cargo planning - Corporate travel monitoring - Aviation OSINT - Executive protection workflows - Incident response support - Travel risk monitoring - Delay trend analysis Results reflect current operations and should be treated as operational intelligence that may change quickly. --- ## 🔍 How the Tool Works The user selects whether they want to monitor **Departures** or **Arrivals**, sets a minimum delay threshold, and optionally adds filters such as airport, airline, flight number, or status. The system then searches real-time delay data and returns matching flights in a structured table. Example search configuration: ```text Type: Departures Min delay: 60 minutes Status: Any ``` The result table may include flights from many airports and airlines when no specific airport filter is applied. When airport, airline, or flight filters are added, the output becomes more focused. The tool supports multi-criteria filtering, so users can combine several conditions for precise monitoring. Example combinations: ```text Departures Minimum delay: 60 minutes Departure IATA: MIA Airline IATA: AA ``` ```text Arrivals Minimum delay: 30 minutes Arrival IATA: JFK Status: active ``` ```text Departures Flight number: 2421 Minimum delay: 30 minutes ``` --- ## 🧩 What Can Be Monitored Flight Delay can monitor delayed flights using several types of filters. Supported monitoring dimensions: - Departure delays - Arrival delays - Departure airport - Arrival airport - Airline - Flight IATA code - Flight ICAO code - Numeric flight number - Operational status - Minimum delay threshold This allows users to monitor delays globally or narrow the view to a specific route, airline, airport, or flight. --- ## ⚙️ Filter Interface The Flight Delay interface contains a set of filter controls. ### Type The user selects the delay type to monitor. Available modes: - Departures - Arrivals **Departures** focuses on delayed outbound flights. **Arrivals** focuses on delayed inbound flights. --- ### Min Delay The minimum delay threshold determines which flights appear in the results. Example: ```text Min delay: 60 ``` This means only flights with a delay greater than or equal to 60 minutes should be returned. The interface may also show quick helper text such as: ```text ≥ 30 minutes ``` Common threshold examples:
ThresholdUse Case
15 minutesMinor delay monitoring
30 minutesStandard disruption monitoring
60 minutesSignificant delay monitoring
90 minutesSerious operational disruption
120+ minutesMajor delay review
A higher threshold produces fewer but more severe results. --- ### Departure IATA Filters results by departure airport using a three-letter IATA airport code. Example: ```text MIA ``` Use this when monitoring delays for flights departing from a specific airport. --- ### Departure ICAO Filters results by departure airport using a four-letter ICAO airport code. Example: ```text KMIA ``` ICAO codes are useful when IATA codes are ambiguous or when working with aviation-specific systems. --- ### Arrival IATA Filters results by arrival airport using a three-letter IATA airport code. Example: ```text SFO ``` Use this when monitoring delayed flights arriving at a specific airport. --- ### Arrival ICAO Filters results by arrival airport using a four-letter ICAO airport code. Example: ```text KSFO ``` --- ### Airline IATA Filters results by airline using one or more IATA airline codes. Example: ```text AA,BA ``` Comma-separated values are allowed, which makes it possible to monitor several airlines in one query. --- ### Airline ICAO Filters results by airline using one or more ICAO airline codes. Example: ```text AAL,BAW ``` This is useful for aviation analysts who work with ICAO identifiers. --- ### Flight IATA Filters results by a full IATA-style flight code. Example: ```text AA2421 ``` --- ### Flight ICAO Filters results by a full ICAO-style flight code. Example: ```text AAL2421 ``` --- ### Flight Number Filters results by the numeric flight number only. Example: ```text 2421 ``` This can be useful when the airline code is uncertain or when comparing codeshare flights. --- ### Status Filter Filters flights by operational status. Default value: ```text Any ``` Possible status values may include: - Any - Active - Scheduled - Landed - Cancelled - Delayed - Unknown The exact returned statuses depend on the backend aviation data source. --- ## 📊 Delay Results Summary After a search is completed, the tool displays a summary of the returned delay data. The summary may include: - Search type - Minimum delay threshold - Departure airports represented in the result set - Arrival airports represented in the result set - Query timestamp - Number of returned results - Maximum delay - Number of airlines Example summary structure: ```text DEPARTURES, ≥ 60 min Results: 100 Max delay: 1000 min Airlines: 52 ``` This summary helps users quickly understand the scale of current delays and whether the result set is broad or focused. --- ## 📋 Results Table The results table displays delayed flights in a compact operational format. Typical columns include:
ColumnDescription
FlightFlight code
AirlineAirline IATA code
RouteDeparture and arrival airport
StatusCurrent operational status
Departure timeScheduled or updated departure time
Arrival timeScheduled or updated arrival time
Departure terminal / gateDeparture terminal and gate, if available
Arrival terminal / gateArrival terminal and gate, if available
DurationFlight duration or scheduled travel time in minutes
Departure delayDeparture delay in minutes
Arrival delayArrival delay in minutes
Example row format: ```text AA5395 AA SDF → CLT landed 2026-06-17 16:00 2026-06-17 17:37 B2 E43 102 102 95 ``` The table is designed for fast scanning, sorting, and export. --- ## 🛫 Departure Delay Monitoring When the type is set to **Departures**, the tool focuses on delayed outbound flights. This mode is useful for: - Monitoring airport departure disruptions - Tracking delayed outbound routes - Checking departure gate impact - Identifying airlines with active delays - Reviewing large airport disruption events - Supporting passenger and crew coordination - Exporting delayed departure lists Example use case: ```text Show all departures delayed by at least 60 minutes. ``` With additional filters: ```text Show all MIA departures delayed by at least 60 minutes. ``` --- ## 🛬 Arrival Delay Monitoring When the type is set to **Arrivals**, the tool focuses on delayed inbound flights. This mode is useful for: - Passenger pickup planning - Airport arrival flow monitoring - Destination airport disruption analysis - Ground transport coordination - Hotel and transfer planning - Executive arrival monitoring - Cargo receiving workflows Example use case: ```text Show all arrivals into JFK delayed by at least 30 minutes. ``` --- ## 🏢 Airline Delay Filtering The tool supports airline-based filtering using IATA or ICAO airline codes. This is useful for identifying whether delays are concentrated around a specific carrier. Example: ```text Airline IATA: AA,BA,DL ``` Airline filtering can help with: - Airline operations monitoring - Codeshare delay analysis - Corporate travel risk review - Carrier performance checks - Disruption response - Customer support workflows Because codeshares may appear as multiple flight numbers for the same physical flight, analysts should review rows with identical routes, times, gates, and delay values carefully. --- ## ✈️ Flight-Specific Delay Search Users can filter by a specific flight using: - Flight IATA - Flight ICAO - Numeric flight number Examples: ```text Flight IATA: AA2421 ``` ```text Flight ICAO: AAL2421 ``` ```text Flight number: 2421 ``` This is useful when monitoring a particular flight that may be delayed, cancelled, or affected by operational changes. --- ## ⏱️ Delay Values Delay values are shown in minutes. The table may include several delay-related columns, depending on the returned data. Common delay indicators:
Delay FieldMeaning
Main delayOverall delay value used for filtering
Departure delayDelay affecting departure
Arrival delayDelay affecting arrival
For departures, the departure delay is usually most relevant. For arrivals, the arrival delay is usually most relevant. However, both values can be useful because a flight may depart late and recover some time en route, or depart with a small delay and arrive with a larger delay due to routing, congestion, weather, or holding patterns. --- ## 🚨 Max Delay The summary may show a maximum delay value. Example: ```text Max delay: 1000 min ``` This helps users quickly identify the severity of the largest delay in the current result set. A very high delay value should be reviewed carefully because it may indicate: - Major operational disruption - Schedule rollover - Data-source anomaly - Cancelled or rescheduled service - Long ground delay - Airport disruption - Weather event - Regional traffic flow issue For critical use, high-delay records should be validated with official airline or airport sources. --- ## 🧠 Key Features ### Real-Time Delay Monitoring The tool monitors current delayed flights and returns operationally relevant results. ### Departures and Arrivals Users can choose whether to focus on delayed departures or delayed arrivals. ### Configurable Delay Threshold Minimum delay can be adjusted to focus on minor, moderate, or severe disruptions. ### Airport Filters Users can filter by departure or arrival airport using IATA or ICAO codes. ### Airline Filters Users can filter by one or more airlines using comma-separated IATA or ICAO codes. ### Flight Filters Users can search by full IATA flight code, full ICAO flight code, or numeric flight number. ### Status Filtering Results can be filtered by operational status. ### Sortable Table Users can click table headers to sort results. ### CSV Export Results can be exported to CSV for structured analysis. ### TXT Export Flight lists can be exported to TXT for quick operational use. ### Local Request History Recent queries are stored locally in the browser. ### Plan-Based Limits Daily query limits are enforced server-side according to the user’s plan. --- ## 📤 Export Options Flight Delay supports export for operational and analytical workflows. ### CSV Export CSV export is useful for: - Spreadsheet analysis - Delay reporting - Airline disruption review - Airport operations dashboards - Logistics documentation - Incident response records - Corporate travel reporting ### TXT Export TXT export is useful when users need a plain list of delayed flight numbers. Possible use cases: - Watchlists - Batch checks - Quick sharing with operations teams - Copying into other aviation tools - Internal notifications Exported delay data may contain operationally sensitive travel information and should be stored appropriately. --- ## 🕓 Request History The **Request History** section stores recent delay searches locally in the browser. Example behavior: ```text Stores last 100 queries in your browser. ``` History entries may include: - Search type - Route filters - Delay threshold - Airline filter - Flight filter - Query timestamp Example history format: ```text DEPARTURES — → — ≥ 60 min Airline: any Flight: any 17.06.2026, 21:40:19 ``` Local history helps users repeat common monitoring queries quickly. Because it is browser-local, history may be cleared by deleting browser data or using another device. --- ## 🚦 Query Limits and Plan Access Flight Delay uses plan-based query limits. Example: ```text 149 / 150 Queries remaining / total Plan: Sentinel ``` Important points: - Access depends on the user’s plan. - Daily tool limits are enforced server-side. - The user should monitor remaining query count during repeated searches. - Exporting already loaded results is separate from running new delay queries. --- ## 🧭 IATA and ICAO Reference The tool supports both IATA and ICAO identifiers. ### Airport IATA Three-letter airport code. Examples: ```text MIA JFK SFO ``` ### Airport ICAO Four-letter airport code. Examples: ```text KMIA KJFK KSFO ``` ### Airline IATA Two-character airline code. Examples: ```text AA BA DL ``` ### Airline ICAO Three-letter airline code. Examples: ```text AAL BAW DAL ``` ### Flight IATA IATA airline code plus flight number. Example: ```text AA2421 ``` ### Flight ICAO ICAO airline code plus flight number. Example: ```text AAL2421 ``` Using the correct identifier type improves result accuracy. --- ## 🧠 Result Interpretation Flight delay data should be interpreted carefully because flight operations change quickly. Important interpretation rules: - A delay value can change as the flight status updates. - A landed flight may still appear if it met the delay threshold. - Active flights can recover time en route. - Scheduled flights may show expected delay before departure. - Codeshare flights may appear as separate rows with identical times and routes. - A missing terminal or gate does not always mean the information is unavailable at the airport; it may simply not be returned. - Very high delay values should be validated. - Status and delay fields may differ depending on provider logic. - Operational decisions should be confirmed with official airline or airport sources. The tool is designed for monitoring and analysis, not as a single source of truth for safety-critical decisions. --- ## ✅ Recommended Monitoring Workflow A practical delay monitoring workflow should follow these steps. ### 1. Select Delay Type Choose Departures or Arrivals depending on the monitoring objective. ### 2. Set Minimum Delay Use 30 minutes for general disruption monitoring or 60+ minutes for more serious delay analysis. ### 3. Add Airport Filters Use departure or arrival IATA / ICAO codes to focus on a specific airport. ### 4. Add Airline Filters Use airline filters to monitor one or more carriers. ### 5. Add Flight Filters When Needed Use full flight codes or numeric flight number for a specific flight. ### 6. Review Summary Check result count, maximum delay, airlines, and route spread. ### 7. Sort the Table Sort by delay, departure time, arrival time, route, airline, or status. ### 8. Identify Codeshares Look for identical routes, times, and delays under different flight numbers. ### 9. Export Results Use CSV for structured analysis or TXT for simple flight lists. ### 10. Verify Critical Cases Confirm severe delays, cancellations, and passenger-impacting events with official sources. --- ## 🛡️ Security, Privacy & Responsible Use Flight Delay is intended for lawful aviation monitoring and operational awareness. Acceptable use cases include: - Monitoring delayed departures - Monitoring delayed arrivals - Airport disruption analysis - Airline delay tracking - Travel coordination - Passenger pickup planning - Logistics and cargo planning - Corporate travel monitoring - Aviation OSINT - Executive protection workflows - Incident response support - Operational reporting Users should follow responsible use principles: - Do not use delay information for stalking, harassment, or physical harm. - Do not misuse flight data to target individuals. - Do not assume delay data is perfectly real-time or complete. - Do not make safety-critical decisions based only on one source. - Verify important travel and operational details with official sources. - Treat local request history as potentially sensitive on shared devices. - Use exports responsibly and store them securely when they contain operationally sensitive information. --- ## ⚙️ Technical Highlights - Real-time flight delay monitoring - Available at `dash.niamonx.io/flight_delay` - Supports departure delay monitoring - Supports arrival delay monitoring - Configurable minimum delay threshold - Airport filters by IATA and ICAO - Airline filters by IATA and ICAO - Comma-separated airline filtering - Flight filters by IATA, ICAO, and numeric flight number - Status filtering - Client-side filters and controls - Sortable result table - CSV export - TXT export for flight lists - Local browser request history - Stores last 100 queries in the browser - Plan-based query limits - Server-side limit enforcement - Suitable for aviation monitoring, travel coordination, logistics, OSINT, and operational awareness --- ## 📌 Usage Hints - Select Departures to monitor outbound delays. - Select Arrivals to monitor inbound delays. - Use 30 minutes for general delay monitoring. - Use 60 minutes or more for significant disruption tracking. - Use airport IATA codes such as `MIA`, `JFK`, or `SFO`. - Use airport ICAO codes such as `KMIA`, `KJFK`, or `KSFO`. - Use comma-separated airline codes to monitor several airlines. - Use flight IATA or ICAO for exact flight tracking. - Use the numeric flight number when the airline code is uncertain. - Click table headers to sort results. - Export CSV for analysis. - Export TXT for flight lists. - Confirm critical delay data with official airline or airport sources. - Access depends on your plan and daily tool limits. - Local request history stores the last 100 queries in your browser. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX Flight Delay** is a real-time delay monitoring tool for tracking delayed departures and arrivals worldwide. It supports configurable minimum delay thresholds, airport filters, airline filters, flight filters, status filtering, sortable tables, CSV export, TXT flight-list export, local browser history, and plan-based query limits. The tool is designed for aviation operations, travel coordination, airport disruption monitoring, logistics, corporate travel visibility, aviation OSINT, and incident response support. Results should be treated as current operational intelligence and verified with official airline or airport sources for critical decisions. # Flight Tracker | Real-Time ADS-B Flight Monitoring [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/MKluVPp9gJZsQvLi-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/MKluVPp9gJZsQvLi-image.png) The platform available at **[https://dash.niamonx.io/flight\_tracker](https://dash.niamonx.io/flight_tracker)** — known as **Flight Tracker** — is a real-time flight tracking and aviation intelligence tool within the NiamonX platform. It allows users to monitor active flights using live ADS-B data and filter aircraft by map region, flight code, airline, route, aircraft identifier, speed, altitude, country flag, and operational status. ## Overview of the Service **Flight Tracker** is designed to provide a live operational view of active flights worldwide. The tool collects and displays real-time aircraft movement data, allowing users to track individual flights or analyze broader air traffic activity across selected regions. Unlike static schedule tools, Flight Tracker focuses on aircraft that are currently active or recently observed through live aviation telemetry. It provides position, speed, altitude, heading, aircraft type, registration, route, airline, and update timestamp when available. The tool is useful for: - Real-time aviation monitoring - Flight tracking - ADS-B intelligence - Airport and route observation - Airline fleet monitoring - Aviation OSINT - Logistics and travel awareness - Corporate travel visibility - Executive protection workflows - Incident response support - Regional airspace monitoring No raw upstream data is shown in the interface. Results are cleaned and displayed in an analyst-friendly table. --- ## 🔍 How the Tool Works The user can run a broad search for all active flights or narrow the query using one or more filters. Supported filtering options include: - Bounding box / map region - Zoom level - Minimum speed - Minimum altitude - Flight IATA code - Flight ICAO code - Numeric flight number - Aircraft HEX / registration - Airline IATA code - Airline ICAO code - Country flag - Departure airport - Arrival airport - Flight status The backend returns matching active flights, and the interface displays them in a sortable table. Example broad search: ```text All active flights ``` Example filtered search: ```text Airline IATA: BA Dep IATA / ICAO: LHR Arr IATA / ICAO: JFK ``` Example regional search: ```text Bounding box: 40.5,-74.5,41.2,-73.2 ``` This makes it possible to monitor either one specific aircraft or thousands of active flights across a larger region. --- ## 🧩 What Can Be Tracked Flight Tracker can be used to track or filter flights by several aviation identifiers. Supported search and filter types:
Filter TypeExampleDescription
Bounding box`40.5,-74.5,41.2,-73.2`Limits results to a map region
Flight IATA`AA100`IATA-style flight code
Flight ICAO`AAL100`ICAO-style flight code
Flight number`100`Numeric flight number
HEX / Reg`A1B2C3` or `N123AA`ICAO24 hex or aircraft registration
Airline IATA`AA,BA`One or more airline IATA codes
Airline ICAO`AAL,BAW`One or more airline ICAO codes
Flag`US,GB`Aircraft or operator country flag
Departure airport`JFK` or `KJFK`Departure airport IATA / ICAO
Arrival airport`LHR` or `EGLL`Arrival airport IATA / ICAO
Status`Any`Operational status filter
The tool can be used for both single-flight lookups and wide-area monitoring. --- ## ⚙️ Tracking Interface The Flight Tracker interface contains several main sections. ### Controls The controls panel shows that the tool supports: ```text BBox · Flight · Airline Client-side ``` This means users can filter by geographic bounding box, flight identifiers, and airline-related fields. ### Query Counter The interface displays current daily query limits. Example: ```text 149 / 150 Queries remaining / total Plan: Sentinel ``` Daily access depends on the user’s plan, and limits are enforced server-side. ### Track Flights The main tracking panel contains all filters used to search live flight data. --- ## 🗺️ Bounding Box Filter The **Bounding Box** filter limits results to a selected geographic region. Input format: ```text SW lat, SW lng, NE lat, NE lng ``` Example: ```text 40.5,-74.5,41.2,-73.2 ``` This means: - SW lat: south-west latitude - SW lng: south-west longitude - NE lat: north-east latitude - NE lng: north-east longitude Bounding boxes are useful for: - Monitoring flights around a city - Watching airport approach/departure zones - Tracking traffic over a specific region - Reducing result volume - Improving analysis focus - Combining geographic filtering with airline or flight filters Example use case: ```text Show active flights around New York airspace. ``` --- ## 🔎 Zoom The **Zoom** option helps control how map or regional results are interpreted. Default value: ```text Auto ``` Auto zoom allows the interface to choose an appropriate view based on the query and returned data. Zoom is most useful when combined with a bounding box or map-based workflow. --- ## 🚀 Minimum Speed Filter The **Min speed** filter allows users to return only flights above a selected speed. Unit: ```text km/h ``` This is useful for excluding stationary or slow-moving aircraft. Example use cases: - Show only aircraft currently in flight - Exclude ground traffic - Focus on en-route flights - Identify high-speed active traffic --- ## 🛫 Minimum Altitude Filter The **Min altitude** filter allows users to return only aircraft above a selected altitude. Unit: ```text m ``` This is useful for: - Excluding ground aircraft - Filtering out taxiing aircraft - Monitoring cruise-level traffic - Focusing on aircraft above a selected altitude - Separating airport surface activity from airborne traffic --- ## ✈️ Flight Filters Flight Tracker supports several flight-level filters. ### Flight IATA Search by IATA-style flight code. Example: ```text AA100 ``` ### Flight ICAO Search by ICAO-style flight code. Example: ```text AAL100 ``` ### Flight Number Search by numeric flight number only. Example: ```text 100 ``` Flight number filtering is useful when the airline code is unknown or when checking possible codeshare variants. --- ## 🛩️ Aircraft HEX / Registration The **HEX / Reg** field allows tracking by aircraft identifier. Supported examples: ```text ICAO24 HEX ``` ```text Aircraft registration ``` This is useful for tracking a specific aircraft rather than a scheduled flight number. Possible use cases: - Fleet monitoring - Aircraft-specific investigation - Tracking a tail number - Comparing repeated movements - Executive aviation monitoring - Aircraft OSINT --- ## 🏢 Airline Filters The tool supports filtering by airline IATA or ICAO codes. ### Airline IATA Example: ```text AA,BA ``` Comma-separated values are allowed. ### Airline ICAO Example: ```text AAL,BAW ``` Airline filters are useful for: - Monitoring one airline - Comparing active flights by carrier - Watching alliance or codeshare activity - Reducing large global result sets - Airline fleet observation --- ## 🏳️ Flag Filter The **Flag** filter accepts ISO-2 country codes. Example: ```text US,GB ``` This can help filter aircraft or flights associated with specific countries, depending on the returned aviation data. Use cases: - Country-level fleet monitoring - Regional aviation analysis - Filtering by aircraft registration country - OSINT review by flag or jurisdiction Flag signals should be interpreted carefully because aircraft registration country, airline nationality, and route geography may differ. --- ## 🧭 Departure and Arrival Filters Flight Tracker supports filtering by departure and arrival airports. Input can be IATA or ICAO. Examples: ```text JFK ``` ```text KJFK ``` ```text LHR ``` ```text EGLL ``` These filters are useful for: - Tracking all active flights from an airport - Tracking flights arriving at a destination - Monitoring a specific route - Combining with airline filters - Identifying current airborne traffic for an airport pair --- ## 📊 Real-Time Results Summary After a query is completed, the tool displays a summary of returned live flights. The summary may include: - Result mode - Query timestamp - Number of flights - Number of airlines - Minimum and maximum speed - Minimum and maximum altitude - Data update time range Example summary: ```text All active flights Flights: 7656 Airlines: 498 Speed: 0 → 1155 km/h Altitude: -60 → 15039 m Updated: 19:28–19:43 UTC ``` This summary gives users a quick overview of the size and freshness of the returned data. --- ## 📋 Results Table The results table displays active flights in a compact operational format. Typical columns include:
ColumnDescription
FlightFlight code
AirlineAirline code
RouteDeparture and arrival airports
StatusCurrent operational status
LatitudeCurrent or last known latitude
LongitudeCurrent or last known longitude
AltitudeCurrent or last known altitude in meters
SpeedCurrent or last known speed in km/h
HeadingDirection of travel
Vertical speedClimb or descent indicator, when available
SquawkTransponder squawk code, when available
Aircraft typeICAO aircraft type code
RegistrationAircraft registration
UpdatedLast update timestamp
Example row structure: ```text BA299 BA LHR → ORD en-route 43.225991 -82.839675 10992 698 249 0 B77W G-STBG ``` The table is designed for sorting, filtering, and export. --- ## 📍 Position Data Flight Tracker returns latitude and longitude when available. Position data helps users understand where an aircraft was last observed. Important notes: - Position may be delayed. - Position may not be available for every aircraft. - ADS-B coverage varies by region. - Some aircraft may be filtered or privacy-restricted. - A result does not guarantee perfectly live location. Position should be treated as near-real-time operational data, not as a safety-critical navigation source. --- ## 🧭 Heading The heading value shows the aircraft’s direction of travel. Example: ```text Heading: 249 ``` Heading is usually expressed in degrees, where: - 0 / 360 = north - 90 = east - 180 = south - 270 = west Heading is useful for understanding aircraft movement direction and confirming whether a flight is moving toward its expected destination. --- ## 🛫 Altitude Altitude is displayed in meters. Example: ```text Altitude: 10992 m ``` Altitude can help distinguish: - Aircraft on the ground - Climbing aircraft - Cruising aircraft - Descending aircraft - Approach or landing traffic The summary may show a range such as: ```text Altitude: -60 → 15039 m ``` Negative or unusual altitude values may appear due to data source behavior, airport elevation handling, sensor anomalies, or ground-level interpretation. --- ## 🚀 Speed Speed is displayed in kilometers per hour. Example: ```text Speed: 698 km/h ``` Speed helps identify whether an aircraft is airborne, taxiing, stationary, climbing, cruising, or descending. The summary may show the observed speed range across returned flights. --- ## 📡 Squawk The squawk field displays the aircraft transponder code when available. Squawk may be empty or unavailable for many flights. Common interpretation: - Empty field: no squawk returned - Numeric code: transponder squawk code - Special codes may indicate emergency or operational situations, but they require careful validation The tool should not be used as a sole source for emergency interpretation. --- ## 🛩️ Aircraft Type and Registration Flight Tracker may display: - ICAO aircraft type code - Aircraft registration Examples: ```text B738 A359 A21N ``` ```text G-STBG N19951 PH-BXC ``` Aircraft type and registration are useful for: - Fleet analysis - Aircraft identification - Route monitoring - Aviation OSINT - Spotting codeshare or operator differences - Historical movement correlation Some aircraft may not return registration or type information. --- ## 🧠 Key Features ### Real-Time ADS-B Monitoring The tool provides live or near-live active flight data based on ADS-B-style telemetry. ### Track Individual Flights Users can filter by flight code, flight number, aircraft HEX, or registration. ### Monitor All Active Flights The tool can return a broad global list of active flights. ### Bounding Box Filtering Users can limit results to a specific map region. ### Airline Filtering Users can filter by one or more airlines. ### Route Filtering Users can filter by departure and arrival airport. ### Speed and Altitude Filtering Users can focus on aircraft above specific speed or altitude thresholds. ### Country Flag Filtering Users can filter by ISO-2 country flag when supported. ### Status Filtering Users can filter by operational status. ### Sortable Table Any column can be sorted for faster analysis. ### CSV Export Users can export the flight list to CSV. ### TXT Export Users can export flight lists to plain text. ### Pagination Large result sets are paginated for readability. ### Local Request History The last 100 queries are stored locally in the browser. --- ## 📄 Pagination Large result sets may span multiple pages. Example: ```text Showing 1–100 of 7656 1 / 77 ``` Pagination allows the interface to handle thousands of active flights without overwhelming the browser. Users can navigate through pages to review additional aircraft. --- ## 📤 Export Options Flight Tracker supports export for operational and analytical workflows. ### CSV Export CSV export is useful for: - Spreadsheet analysis - Aviation reporting - Airspace monitoring - Fleet analysis - Route analysis - Incident documentation - OSINT case notes ### TXT Export TXT export is useful for: - Plain flight lists - Watchlists - Batch checks - Quick sharing - Copying identifiers into other tools Exported data may contain operationally sensitive flight information and should be stored responsibly. --- ## 🕓 Request History The **Request History** section stores recent tracking queries locally in the user’s browser. Example behavior: ```text Stores last 100 queries in your browser. ``` History entries may include: - Route filters - Bounding box - Zoom mode - Airline filter - Flight filter - Query timestamp Example history entry: ```text — → — BBOX: — ZOOM: auto Airline: any Flight: any 17.06.2026, 21:43:32 ``` Request history helps users repeat previous monitoring queries quickly. Because it is stored locally, it may be cleared if the user deletes browser data or switches devices. --- ## 🚦 Query Limits and Plan Access Flight Tracker uses plan-based query limits. Example: ```text 149 / 150 Queries remaining / total Plan: Sentinel ``` Important points: - Access depends on the user’s plan. - Daily limits are enforced server-side. - Users should monitor remaining queries during repeated tracking. - Exporting already loaded results is different from running a new query. --- ## 🧭 IATA, ICAO, HEX, and Registration Reference ### Flight IATA IATA-style flight code. Example: ```text AA100 ``` ### Flight ICAO ICAO-style flight code. Example: ```text AAL100 ``` ### Airline IATA Two-character airline code. Example: ```text AA BA DL ``` ### Airline ICAO Three-letter airline code. Example: ```text AAL BAW DAL ``` ### Airport IATA Three-letter airport code. Example: ```text JFK LHR MIA ``` ### Airport ICAO Four-letter airport code. Example: ```text KJFK EGLL KMIA ``` ### ICAO24 HEX Aircraft transponder hexadecimal identifier. Example: ```text A1B2C3 ``` ### Registration Aircraft tail number or national registration. Example: ```text N123AA G-STBG PH-BXC ``` --- ## 🧠 Result Interpretation Flight Tracker data should be interpreted carefully. Important interpretation rules: - ADS-B coverage varies by region. - Some aircraft may not appear due to privacy filters. - Position may be delayed or missing. - Flight status can change quickly. - Aircraft type or registration may be unavailable. - Squawk values require careful validation. - Speed and altitude may contain anomalies. - Ground aircraft may appear with low or zero speed. - Codeshare flights may appear under different airline identifiers. - A missing field does not mean the information does not exist; it may simply not be returned. The tool is designed for monitoring and intelligence, not for safety-critical navigation or official air traffic control use. --- ## ✅ Recommended Monitoring Workflow A practical Flight Tracker workflow should follow these steps. ### 1. Choose Monitoring Scope Decide whether to monitor all active flights, a region, a route, an airline, or a specific aircraft. ### 2. Use Bounding Box for Regions Enter SW and NE coordinates to limit results to a map area. ### 3. Add Airline or Route Filters Use airline, departure, and arrival filters to reduce result volume. ### 4. Use Speed and Altitude Filters Exclude ground traffic or focus on airborne flights. ### 5. Search by Flight or Registration For a specific aircraft, use flight code, HEX, or registration. ### 6. Review the Summary Check total flights, airlines, speed range, altitude range, and update time range. ### 7. Sort the Results Sort by altitude, speed, updated time, airline, route, or aircraft type. ### 8. Review Aircraft Details Check type, registration, route, and position. ### 9. Export When Needed Export CSV for analysis or TXT for flight lists. ### 10. Verify Critical Findings Confirm important operational conclusions with official aviation sources when needed. --- ## 🛡️ Security, Privacy & Responsible Use Flight Tracker is intended for lawful aviation awareness and operational monitoring. Acceptable use cases include: - Tracking active flights - Monitoring airspace regions - Airline and fleet observation - Airport traffic awareness - Travel coordination - Aviation OSINT - Logistics support - Corporate travel monitoring - Executive protection workflows - Incident response support - Research and reporting Users should follow responsible use principles: - Do not use flight tracking data for stalking, harassment, or physical harm. - Do not misuse aircraft movement information to target individuals. - Do not treat ADS-B data as complete or perfectly real-time. - Do not use the tool for safety-critical navigation. - Verify critical operational details with official aviation sources. - Treat local request history as potentially sensitive on shared devices. - Store exported data responsibly. --- ## ⚙️ Technical Highlights - Real-time flight tracking module - Available at `dash.niamonx.io/flight_tracker` - Live ADS-B data - Supports broad active-flight monitoring - Supports individual flight tracking - Bounding box geographic filtering - Zoom control - Minimum speed filter - Minimum altitude filter - Flight IATA filter - Flight ICAO filter - Numeric flight number filter - HEX / registration filter - Airline IATA filter - Airline ICAO filter - ISO-2 flag filter - Departure airport filter - Arrival airport filter - Status filter - Client-side controls - Sortable result table - Pagination for large result sets - CSV export - TXT export - Local browser request history - Stores last 100 queries in browser - No raw upstream data shown - Plan-based query limits - Server-side limit enforcement - Suitable for ADS-B intelligence, aviation OSINT, logistics, travel monitoring, and operational awareness --- ## 📌 Usage Hints - Use an empty query to monitor all active flights. - Use a bounding box to limit results to a map region. - Combine BBOX with airline IATA for focused regional monitoring. - Use min speed to hide stationary or ground aircraft. - Use min altitude to focus on airborne traffic. - Use Flight IATA or ICAO for a known flight. - Use HEX / Reg to track a specific aircraft. - Use airline filters with comma-separated values. - Use departure and arrival filters for route-based tracking. - Sort by altitude, speed, update time, or route. - Export CSV for analysis. - Export TXT for flight lists. - Remember that ADS-B data may be delayed or incomplete. - Access depends on your plan and daily tool limits. - Local request history stores the last 100 queries in your browser. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX Flight Tracker** is a real-time ADS-B flight monitoring tool for tracking active flights worldwide. It supports broad traffic monitoring, region-based tracking, individual flight lookup, airline filtering, route filtering, speed and altitude filtering, aircraft HEX / registration search, status filtering, pagination, CSV export, TXT export, and local browser request history. The tool is designed for aviation OSINT, operational awareness, logistics, corporate travel monitoring, airspace observation, and real-time flight intelligence. Results should be treated as near-real-time aviation signals and verified with official sources for critical decisions. # ULP (Infostealer Logs) ULP (Infostealer Logs) # Public Breached ULP Search | Email / Username Leak Intelligence [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/dKfdBZFYDwAidvMx-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/dKfdBZFYDwAidvMx-image.png) ***The platform available at*** [dash.niamonx.io/ulp\_account\_search](https://dash.niamonx.io/ulp_account_search) ## Overview of the Service **Public Breached ULP Search** is a dedicated NiamonX search module designed to check whether an **email address** or **username** appears in public leak datasets processed by the **NiamonX ULP Engine**. The tool allows users to quickly verify exposure in large-scale public breach collections, with a focus on records related to emails, usernames, URLs, hosts, and associated credentials. This module is specifically optimized for **email and username lookups only**. Domain search, URL search, and advanced search will be implemented separately through dedicated controllers and pages. Public Breached ULP Search is intended for individuals, security analysts, SOC teams, compliance departments, and organizations that need to verify whether accounts, employees, or user identifiers have appeared in public leaked datasets. --- ## 🔍 How the Search Works When a user enters an email address or username, the system performs a lookup through the **NiamonX ULP Engine**. The search checks whether the submitted identifier appears in indexed public leak records. If matches are found, the system displays structured results containing related fields such as: - URL - Host - Email or username - Password - Indexed date - Record type - Available actions The search is designed to return results in seconds and supports large result pages for paid plans. Free preview access remains limited, while paid plans can load significantly more records per page. --- ## 🧩 What Can Be Searched Public Breached ULP Search currently supports only two main identifier types: - Email address - Username Examples: ```text test@example.org ``` ```text username ``` This module does **not** support the following search types inside the current page: - Domain search - URL search - IP search - Phone search - Full name search - Password search - Composite queries - Advanced multi-field queries These features may be available through separate NiamonX tools or future dedicated search pages. --- ## ⚙️ Search Interface The interface contains several key search and filtering controls. ### Email or Username The main input field where the user enters an email address or username. Example values: - `test@example.org` - `johnsmith` - `company.employee` - `security.user` ### Match Mode The current matching mode is: - **Exact** Exact matching helps reduce noise and ensures that results are directly related to the submitted email address or username. ### Page Limit The user can define how many records should be loaded per page. Example: ```text Page limit: 500 ``` Paid plans can load up to **10,000 records per page**. Free preview access remains limited to **100 records**. ### Example Email A quick-fill example for testing email-based search. ### Example Username A quick-fill example for testing username-based search. --- ## 📊 Dataset Scale Public Breached ULP Search is powered by the NiamonX ULP Engine and currently works with a large-scale leak intelligence index. Main dataset indicator: ```text 19B+ Data points ``` This means the system can check identifiers against more than **19 billion indexed data points** related to public leak datasets. The number may grow over time as new data is processed, cleaned, normalized, and indexed by the platform. --- ## 🧠 Key Features ### Email and Username Search The tool is focused specifically on checking whether an email or username appears in public leak datasets. ### NiamonX ULP Engine The module is powered by the internal NiamonX ULP Engine, which processes and indexes large-scale leak records for fast lookup. ### Fast Lookup Users can check exposure in seconds, depending on dataset size, search value, and current system load. ### Exact Match Mode Exact matching helps ensure that the returned records directly correspond to the searched identifier. ### Large Page Limits for Paid Plans Paid users can load up to **10,000 records per page**, making the tool suitable for large-scale security investigations and enterprise workflows. ### Free Preview Mode Free preview access is limited to **100 records**, allowing users to verify the presence of results before upgrading. ### Structured Results Table Search results are displayed in a structured table with fields such as URL, type, email or username, password, indexed date, and actions. ### Password Visibility Control Passwords are visible by default during a secured session and can be hidden with one click. This allows analysts to verify exposure while still maintaining control over sensitive display fields. ### Filtering System Users can filter loaded results by: - URL - Host - Email - Username - Record type ### Saved Records Important records can be saved for later review and investigation. ### Daily Query Limits The tool displays daily query usage based on the user’s current plan. Example: ```text Daily queries 300000 / 300000 Used today: 0 Plan: Sentinel Date: 2026-06-17 ``` --- ## 📋 Results Table After a successful search, results are displayed in a table. Main columns include:
ColumnDescription
URLThe URL connected to the leaked record
TypeThe detected record type
Email / UsernameThe matched email address or username
PasswordAssociated password field, if available
Indexed atDate or timestamp when the record was indexed
ActionsAvailable actions for the record
If no search has been performed, the interface displays: ```text Run a search to see breach records. No results loaded. ``` --- ## 📈 Search Statistics The interface provides quick summary indicators after a search. Available statistics include: ### Found Shows the total number of matching records discovered. ### Loaded Shows the number of records currently loaded into the interface. ### Hosts Shows the number of unique hosts connected to the results. ### Root Domains Shows the number of unique root domains identified in the loaded records. ### With Password Shows how many matched records contain a password field. These counters help users quickly understand the scope and severity of the exposure. --- ## 🔎 Filtering and Record Review The tool includes a filtering field for quickly narrowing down results. Users can filter by: - URL - Host - Email - Username This is useful when a single email or username appears across many records and the analyst needs to focus on specific services, domains, or data types. Example use cases: - Find all results from a specific host - Filter results related to one service - Check whether passwords are present - Identify repeated exposure across multiple websites - Review only records connected to corporate systems --- ## 🔐 Password Handling Some records may include associated password fields. In this secured session, passwords are visible by default and can be hidden with one click. Users must handle password data carefully. Passwords must only be used for defensive verification, account recovery, password reset decisions, or authorized security investigations. Users must not: - Reuse leaked passwords - Attempt unauthorized account access - Share passwords publicly - Export passwords without authorization - Use leaked credentials for credential stuffing, phishing, fraud, or social engineering Recommended defensive actions: - Reset exposed passwords immediately - Enable multi-factor authentication - Check whether the same password was reused elsewhere - Review account login history - Notify affected users where appropriate - Monitor for suspicious activity --- ## 🛡️ Security, Privacy & Ethics Public Breached ULP Search is designed for lawful defensive cybersecurity work. Acceptable use cases include: - Checking your own email or username - Verifying employee exposure with authorization - Investigating corporate account leaks - Supporting incident response - Performing compliance and security audits - Detecting credential reuse risks - Helping users secure compromised accounts Users must follow strict ethical rules: - Search only identifiers you own or are authorized to investigate. - Do not use the tool to target, stalk, harass, or deanonymize people. - Do not use exposed credentials for unauthorized access. - Do not redistribute leaked personal data. - Do not publish passwords or private records. - Do not attempt to bypass platform limits or access controls. - Treat all results as sensitive security intelligence. - Validate findings before taking operational or legal action. Abuse of the system may result in account restriction, suspension, or termination. --- ## ⚙️ Technical Highlights - Powered by **NiamonX ULP Engine** - Dedicated email and username search module - More than **19B+ indexed data points** - Exact match search mode - Fast lookup in seconds - Paid plans support up to **10,000 records per page** - Free preview limited to **100 records** - Structured result table - URL, host, email, username, password, and indexing metadata - Result filtering by URL, host, email, or username - Password visibility toggle - Saved records - Daily query usage counter - Plan-based access limits - Separate future controllers for domain, URL, and advanced search --- ## 🚦 Plan Limits and Access The module uses plan-based limits for daily queries and result loading. Example plan information: ```text Daily queries: 300000 / 300000 Used today: 0 Plan: Sentinel Date: 2026-06-17 ``` Access differences may include:
Access LevelLimitation
Free previewUp to 100 records
Paid plansUp to 10,000 records per page
Plan-based accessDaily query limits depend on subscription
These limits help protect system stability, prevent abuse, and ensure fair access to large-scale breach intelligence. --- ## 📌 Usage Hints - Use this module only for emails and usernames. - Use exact values for the best results. - Do not enter domains or URLs in this module. - Use separate NiamonX tools for domain, URL, or advanced search. - Check the “Found” counter to understand total exposure. - Check “With password” to identify credential-related risk. - Use filters to narrow results by URL, host, email, or username. - Hide password fields when screen sharing or working in public environments. - Save important records for later investigation. - Treat all results as sensitive security data. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or takedown-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Data Removal / Privacy Takedown Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX Public Breached ULP Search** is a dedicated email and username leak intelligence module powered by the **NiamonX ULP Engine**. It allows users to check in seconds whether an email address or username appears in large-scale public leak datasets containing more than **19 billion indexed data points**. The tool supports exact matching, structured results, password visibility control, filtering, saved records, plan-based daily query limits, and large page sizes for paid plans. It is designed for lawful security checks, credential exposure validation, incident response, compliance reviews, and defensive cybersecurity investigations. # Public Breached ULP Domain / IP Search | Domain and IP Breach Intelligence [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/2rVa5X8Ns6ndgMby-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/2rVa5X8Ns6ndgMby-image.png) ***The platform available at*** [dash.niamonx.io/ulp\_domain\_ip\_search](https://dash.niamonx.io/ulp_domain_ip_search) ## Overview of the Service **Public Breached ULP Domain / IP Search** is a consolidated breach intelligence module within the NiamonX platform. It is designed to scan public leak datasets for records related to a specific **domain** or **IP address** and generate a structured security report. The tool is powered by **NiamonX Domain Intelligence** and the **NiamonX ULP Engine**, allowing users to analyze compromised accounts, exposed URLs, affected subdomains, employee-related records, third-party identities, customer-style username records, and password-related exposure. This module is intended for companies, SOC teams, security analysts, incident response teams, compliance departments, and authorized cybersecurity researchers who need to understand whether a corporate domain or IP address appears in large-scale public leak datasets. The search is focused on **exact domains and IP addresses only**. Examples: ```text example.com ``` ```text 203.0.113.10 ``` Users must not enter full URLs, URL paths, emails, wildcards, or unrelated search values in this module. [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/gYLqiY8YnlsMtjc9-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/gYLqiY8YnlsMtjc9-image.png) --- ## 🔍 How the Search Works When a user enters a domain or IP address, the system performs an exact search across indexed ULP leak records. For domain-based searches, subdomains are automatically normalized to the root domain before searching. For example: ```text auth.example.com ``` is normalized and searched as: ```text example.com ``` This allows the system to consolidate breach intelligence across all related subdomains and hosts under the same root domain. The search returns a consolidated report that may include: - Total compromised accounts - Loaded rows in the current browser session - Unique hosts - Unique URLs - Subdomains - Employee-related records - Third-party records - Customer or username-only records - Password strength distribution - Records with passwords - Email records - Username records - Top URLs - Top subdomains - Graph and AI analysis The total number of compromised accounts is taken directly from the API when available, while category cards describe only the rows loaded in the current browser session. Hidden category totals are not guessed. --- ## 🧩 What Can Be Searched This module supports only exact domain and IP address searches. Supported values: - Root domains - Subdomains, normalized to root domain - IPv4 addresses - IPv6 addresses, if supported by the backend index Examples of valid searches: ```text example.com ``` ```text company.org ``` ```text 203.0.113.10 ``` Examples of invalid input for this module: ```text https://example.com/login ``` ```text example.com/login ``` ```text user@example.com ``` ```text *.example.com ``` ```text example ``` Domain, URL, email, username, and advanced search are handled through separate NiamonX modules or dedicated pages. --- ## ⚙️ Search Interface The interface contains several core controls and report indicators. ### Domain or IP The main input field where the user enters an exact domain or IP address. Example: ```text tesla.com ``` The field is intended only for domains or IP addresses. Users should not enter URLs, paths, emails, or wildcards. ### Match Mode The current match mode is: ```text Exact ``` Exact matching helps reduce noise and ensures that the report is generated around the submitted domain, normalized root domain, or IP address. ### Limit The result limit controls how many rows can be loaded into the current browser session. Example: ```text 10,000 ``` The report may show an exact total from the API while loading only a limited number of rows into the current session. ### Daily Queries The interface displays daily query limits based on the user’s plan. Example: ```text Daily queries 299998 / 300000 Used today: 2 Cooldown: 1s Plan: Sentinel ``` Daily limits help control usage, ensure platform stability, and prevent abuse. --- ## 📊 Dataset Scale Public Breached ULP Domain / IP Search is powered by a large-scale ULP intelligence dataset. Main dataset indicator: ```text 19B+ ULP rows ``` This means the module can search across more than **19 billion indexed ULP rows** related to public leak datasets. The dataset may include records containing URLs, hosts, emails, usernames, passwords, timestamps, and other leak-related metadata. --- ## 🧠 Key Features ### Domain and IP Intelligence The module provides consolidated breach intelligence for a specific domain or IP address. ### Root Domain Normalization Subdomains are normalized to the root domain before searching, allowing the tool to detect exposure across related hosts. ### Exact Match Search Exact matching helps ensure that the report is focused on the selected domain or IP address. ### Consolidated Security Report The tool generates a structured security report with key metrics, categories, and exposure indicators. ### Exact API Total The total number of compromised accounts can be displayed as an exact value from the API. ### Loaded Session Rows The report clearly separates the exact total from the rows currently loaded in the browser session. ### Employee Detection The system identifies employee-related records where the email domain matches the searched root domain or its subdomains. ### Third-Party Detection The system identifies external email domains that authenticated on the target domain or related services. ### Customer / Username-Only Records The module separates username-only records or identities without a corporate email domain. ### Password Strength Distribution Loaded compromised accounts are grouped by password strength. Common categories include: - Too weak - Weak - Medium - Strong ### URL and Host Analysis The report highlights top URLs, unique endpoints, unique hosts, and subdomains discovered in loaded records. ### Graph and AI Module The tool includes a Graph / AI section for visual analysis and AI-assisted interpretation of the breach report. [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/6TaDvpcBckHUdKn6-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/6TaDvpcBckHUdKn6-image.png) ### Saved Records Important records can be saved for later review and investigation. --- ## 📈 Security Report Structure After a search is completed, the module generates a structured report. Example report header: ```text Security Report for example.com Root domain • 2026-06-17 • 10,000 loaded rows ``` The report may include the following cards and sections. --- ## 📌 Compromised Accounts The **Compromised Accounts** card shows the total number of compromised accounts related to the searched domain or IP. Example: ```text Compromised Accounts (Exact API Total) 45,837 ``` This value represents the exact total returned by the API. The category cards below the total describe only the rows loaded in the current browser session. The system does not guess hidden category totals. --- ## 📥 Loaded Rows The **Loaded rows** card shows how many records are currently loaded in the browser session. Example: ```text Loaded rows 10,000 current cursor session ``` This is important because the full API total may be higher than the number of records loaded into the interface. For large reports, users may need to load additional pages or use cursor-based pagination. --- ## 🌐 Unique Hosts, URLs, and Subdomains The report summarizes infrastructure-related indicators. ### Unique Hosts Shows how many unique hosts were parsed from URL hosts. Example: ```text Unique hosts 41 ``` ### URLs Shows how many unique endpoints were found. Example: ```text URLs 250 ``` ### Subdomains Shows how many unique subdomains or hosts were detected in the loaded rows. Example: ```text Subdomains 41 ``` These indicators help analysts understand which services, login pages, applications, or infrastructure components are most commonly associated with leaked records. --- ## 👥 Employee Exposure The **Employees** section identifies records where the email domain matches the searched root domain or one of its subdomains. Example: ```text Employees Loaded compromised accounts: 221 ``` Employee records are important because they may indicate direct corporate account exposure. The section may also include password strength distribution:
Password StrengthDescription
Too weakVery risky passwords that may be simple, reused, or easily guessed
WeakLow-strength passwords requiring urgent review
MediumModerate-strength passwords that may still require reset depending on context
StrongStronger passwords, but still considered exposed if found in leaks
Example distribution:
StrengthCount
Too weak22
Weak3
Medium50
Strong146
Even strong passwords should be reset if they appear in breach records. --- ## 🏢 Third-Party Exposure The **Third-Parties** section identifies external email domains that authenticated on the searched target. Example: ```text Third-Parties Loaded compromised accounts: 8,127 ``` These records may represent: - Contractors - Vendors - Partners - External users - Customers using third-party emails - SSO or login activity involving non-corporate domains - Accounts created with external identities Third-party exposure is important because attackers may use compromised external accounts to access company systems, partner portals, support panels, or customer-facing services. Example password strength distribution:
StrengthCount
Too weak148
Weak82
Medium2,769
Strong5,113
--- ## 👤 Customer and Username-Only Records The **Customers** section includes username-only records or identities without a corporate email domain. Example: ```text Customers Loaded compromised accounts: 1,652 ``` These records may represent: - Customer accounts - Username-only logins - Non-email identities - Legacy accounts - Application-specific usernames - Records where email data is missing Example password strength distribution:
StrengthCount
Too weak84
Weak60
Medium594
Strong843
This section helps organizations understand user exposure beyond direct employee email accounts. --- ## 🔐 Password Exposure The report highlights how many loaded records contain passwords. Example: ```text With passwords 9,914 loaded rows ``` Password exposure is one of the most important risk indicators. If passwords are present, users should treat the affected records as sensitive security intelligence. Recommended actions: - Reset exposed passwords. - Check whether the password is still active. - Check whether the same password was reused elsewhere. - Enforce multi-factor authentication. - Review login history. - Investigate suspicious access events. - Notify affected users if required. - Disable or lock high-risk accounts if necessary. Passwords must never be used for unauthorized access, credential stuffing, phishing, fraud, or social engineering. --- ## 📧 Email and Username Records The report separates loaded rows by identity type. Example: ```text Email records 8,348 loaded rows ``` ```text Username records 1,652 loaded rows ``` Email records usually provide stronger identity correlation because they are connected to a specific domain or user account. Username records may require additional validation because usernames can be reused across multiple services and may not always uniquely identify one person. --- ## 🔗 Top URLs from Loaded Rows The report displays the most common URLs found in the loaded records. Example:
URLCount
auth.example.com3,299
auth.example.com/oauth2/v1/authorize1,463
auth.example.com/oauth2/v1/register941
auth.example.com/login609
auth.example.com/register506
example.com424
sso.example.com104
This section helps analysts identify the most affected endpoints. Common findings may include: - Login pages - OAuth endpoints - Registration pages - SSO portals - Customer portals - Admin panels - Application dashboards - API authentication endpoints High counts on authentication endpoints may indicate credential exposure involving login flows. --- ## 🧭 Top Subdomains from Loaded Rows The report also displays the most common subdomains or hosts found in loaded records. Example:
SubdomainCount
auth.example.com8,328
example.com1,215
sso.example.com239
accounts.example.com109
apps.example.com10
toolbox.example.com6
This section helps security teams identify which parts of the organization’s infrastructure are most represented in public leak data. High-risk subdomains may include: - Authentication systems - SSO portals - Employee portals - Payment systems - Admin panels - Developer tools - Customer account systems - Internal application gateways --- ## 🧠 Graph / AI Analysis The **Graph / AI** section provides visual and AI-assisted analysis of the domain or IP exposure. It may help users understand: - Relationships between hosts and leaked accounts - Clusters of exposed users - Common authentication endpoints - Employee vs third-party exposure - High-risk password patterns - Repeated infrastructure exposure - Potentially affected services - Prioritized remediation areas The AI component can assist with summarizing the report and highlighting important risks, but it should not replace manual analyst validation. --- ## 💾 Saved Records The **Saved records** section allows users to store important findings for later review. Saved records may be useful for: - Incident response tracking - Compliance documentation - Internal reporting - Rechecking high-risk accounts - Preparing remediation lists - Monitoring repeated exposure - Reviewing specific URLs or users Saved records should be handled as sensitive security data. --- ## 🚦 Pagination and Cursor State Large reports may contain more records than are loaded into the current browser session. The interface may show cursor-related information, such as: ```text Next page NaN cursor state ``` This indicates the current pagination or cursor state for loading additional records. The exact API total and the currently loaded rows should always be interpreted separately. Example: ```text Exact API Total: 45,837 Loaded rows: 10,000 ``` This means the API reports 45,837 total compromised accounts, while the browser currently displays and analyzes 10,000 rows. --- ## 🛡️ Security, Privacy & Ethics Public Breached ULP Domain / IP Search is designed for lawful defensive cybersecurity and authorized breach intelligence analysis. Acceptable use cases include: - Checking your own company domain - Investigating authorized corporate assets - Reviewing employee credential exposure - Assessing third-party login exposure - Supporting incident response - Supporting compliance audits - Monitoring exposed authentication endpoints - Identifying password reuse risk - Preparing remediation actions Users must follow strict ethical rules: - Search only domains, IPs, and assets you own or are authorized to investigate. - Do not use the tool to target companies, employees, customers, or individuals without authorization. - Do not use exposed credentials for unauthorized access. - Do not redistribute leaked passwords or personal data. - Do not publish sensitive records. - Do not perform credential stuffing, phishing, fraud, extortion, or social engineering. - Do not attempt to bypass access controls, rate limits, or plan restrictions. - Validate all findings before taking operational, legal, or security action. - Treat all reports as sensitive security intelligence. Abuse of the platform may result in account restriction, suspension, or termination. --- ## ✅ Recommended Remediation Workflow When exposure is found, security teams should follow a structured remediation process. ### 1. Validate the Report Confirm that the domain or IP belongs to the organization and that the records are relevant. ### 2. Prioritize Employee Accounts Employee records should be reviewed first because they may represent direct corporate access risk. ### 3. Check Password Exposure Focus on records with passwords, especially weak and very weak passwords. ### 4. Enforce Password Resets Reset exposed passwords and prevent reuse through password policy controls. ### 5. Enable MFA Require multi-factor authentication for affected accounts and critical systems. ### 6. Review Login Logs Check SIEM, IAM, VPN, SSO, email, and application logs for suspicious activity. ### 7. Investigate Affected URLs Review the top URLs and subdomains to identify exposed authentication surfaces. ### 8. Review Third-Party Exposure Check whether external accounts belong to vendors, partners, contractors, or customers. ### 9. Notify Stakeholders Inform internal security, legal, compliance, and affected users where appropriate. ### 10. Monitor Continuously Repeat checks periodically and monitor for new exposure. --- ## ⚙️ Technical Highlights - Powered by **NiamonX Domain Intelligence** - Uses the **NiamonX ULP Engine** - Searches across **19B+ ULP rows** - Exact domain and IP search - Root domain normalization for subdomains - Consolidated breach report - Exact compromised account total from API - Loaded-row analysis for current browser session - Employee, third-party, and customer categorization - Password strength distribution - Unique host detection - Unique URL and endpoint analysis - Subdomain extraction - Email vs username record separation - Records with password counter - Top URLs from loaded rows - Top subdomains from loaded rows - Graph / AI analysis - Saved records - Cursor-based pagination - Plan-based daily query limits - Cooldown protection - Suitable for SOC, compliance, incident response, and domain exposure monitoring --- ## 📌 Usage Hints - Enter only an exact domain or IP address. - Do not enter full URLs, paths, emails, or wildcards. - Subdomains are normalized to the root domain before searching. - Use the exact API total to understand full exposure. - Use loaded-row cards to analyze the currently loaded browser session. - Review employee records first for direct corporate risk. - Review third-party records for vendor, partner, and external identity exposure. - Review customer and username-only records separately. - Prioritize records with passwords. - Check top URLs to identify the most affected authentication endpoints. - Check top subdomains to understand infrastructure exposure. - Use Graph / AI for faster triage, but validate findings manually. - Save important records for investigation and reporting. - Treat all downloaded or saved records as sensitive security material. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or takedown-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Data Removal / Privacy Takedown Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX Public Breached ULP Domain / IP Search** is a consolidated domain and IP breach intelligence module designed to scan public leak datasets and generate a structured security report. It searches across more than **19 billion ULP rows**, normalizes subdomains to the root domain, calculates exact compromised account totals from the API, and analyzes loaded rows by employees, third parties, customers, URLs, hosts, subdomains, password exposure, and password strength. The tool is built for lawful defensive cybersecurity, domain exposure monitoring, SOC workflows, incident response, and compliance investigations. All findings should be validated before action and handled as sensitive security intelligence. # Identity Intelligence Identity Intelligence # Identity360 Report | Digital Footprint Intelligence [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/4nGTLUYdcUhYcGko-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/4nGTLUYdcUhYcGko-image.png) ***The platform available at*** [dash.niamonx.io/identity360\_report](https://dash.niamonx.io/identity360_report) ## Overview of the Service **Digital Footprint Intelligence** is an advanced identity intelligence tool within the NiamonX platform. The main report generated by this module is called **Identity360 Report**. Identity360 Report provides a unified digital identity overview by combining results from multiple NiamonX intelligence modules: - Public Breached Search - ULP Account Search - Alias Radar - Google Footprint - CrossTrace The tool is designed to help individuals, cybersecurity analysts, SOC teams, compliance departments, investigators, and authorized security professionals understand how a specific email address or username appears across public breach datasets, stealer log evidence, public account traces, username reconnaissance sources, and Google ecosystem signals. The report is built as a consolidated identity profile. Instead of checking each module manually, the user starts one report and receives a structured overview of exposure, related identifiers, public accounts, evidence links, breach blocks, ULP records, and analytical risk indicators. --- ## 🔍 How the Report Works When a user creates an Identity360 report, the platform starts a multi-module investigation for the submitted target. Supported target types: - Email address - Username For email-based targets, the system may also derive the email local part and run username-focused modules against it as a correlation lead. For example, if the target is: ```text example.name@domain.com ``` the platform may also check: ```text example.name ``` This derived username should be treated only as a correlation lead, not as confirmed ownership. One billed request starts the report. After that, the browser checks the report progress through AJAX polling every few seconds. Status checks do not consume additional daily tool quota, and polling stops permanently after the final report is ready. This design allows long-running intelligence modules to continue processing while the user sees real-time progress inside the interface. --- ## 🧩 Main Purpose Identity360 Report helps answer questions such as: - Has this email address appeared in public breach datasets? - Are there credential-related records connected to this identity? - Are there ULP or stealer-log records for the email or username? - Are there public accounts connected to the identifier? - Are there usernames, names, phone numbers, domains, or other related identifiers? - Are there public profile traces across platforms? - What is the overall exposure risk? - Which evidence links support the findings? - Which modules found the strongest signals? The tool is especially useful for identity exposure analysis, account compromise investigation, personal digital footprint review, employee risk monitoring, and incident response. --- ## ⚙️ Report Creation Interface The report creation interface includes the following main elements. ### Available Requests Today Shows the number of remaining report requests available under the current plan. Example format: ```text Available requests today 597 / 600 Used today: 3 Plan: Sentinel Date: 2026-06-17 ``` ### Create Report Starts a new Identity360 report. ### Target Type The user selects or enters an email address or username. Supported examples: ```text user@example.com ``` ```text username ``` ### Email Local-Part Correlation For email targets, the system can also run username modules against the email local part. This is useful because many users reuse the same nickname across multiple public platforms. However, these matches must be interpreted carefully. A username match does not automatically prove that the account belongs to the same person. --- ## 📊 Report Progress After the report starts, the interface displays processing status. Example status elements: ```text Processing report… 60% Report ID: ************ Executive summary: running ``` The report may show: - Processing percentage - Report ID - Module status - Executive summary status - Number of completed modules - Number of running modules - Number of pending modules - Error or skipped module indicators The report is considered final only after all required modules finish, fail, or are skipped according to the backend state. --- ## 🧠 Processing Modules Identity360 Report combines several intelligence modules into one unified profile. ### Public Breached Search Public Breached Search checks indexed public breach datasets for the submitted target. It may return: - Breach blocks - Credential blocks - Source names - Personal identifiers - Exposed emails - Related phones - Related names - Password-related indicators - Risk signals This module is useful for understanding whether the target appears in historical public breach collections. --- ### ULP Account Search ULP Account Search checks stealer-log and ULP-style account evidence by email or username. It may return: - ULP records - Hosts - Account identities - Password evidence - URLs - Indexed dates - Related services - Evidence links This module is especially important because ULP records may indicate that credentials were captured from infected devices, browser storage, or other compromise sources. --- ### Alias Radar Alias Radar performs detailed username reconnaissance across public platforms. It may return: - Public profile matches - Platform names - Display names - Profile URLs - Avatars or profile images - Account metadata - Confidence scores - Extracted profile details When Alias Radar is run from an email local part, matches should be treated as possible correlation leads rather than confirmed identity ownership. --- ### Google Footprint Google Footprint checks public Google account and Google ecosystem signals. It may return: - Google-related public signals - Account presence indicators - Public profile hints - Ecosystem metadata - Google-linked exposure signals If the module is skipped, pending, or incomplete, the report should clearly show that Google Footprint data is not available yet. --- ### CrossTrace CrossTrace performs fast public account-presence checks by email or username. It may return: - Direct account presence traces - Platform-level signals - Public account indicators - Profile URLs - Confidence scores - Related usernames - Avatars or public images CrossTrace is useful for fast identity correlation across public platforms. --- ## 📌 Executive Summary The Executive Summary provides a high-level interpretation of the report. It may include: - Overall risk level - Analytical risk score - Main exposure drivers - Number of breach blocks - Number of credential blocks - Number of ULP records - Number of public accounts - Number of evidence links - Number of Google signals - Key findings from completed modules The summary helps users quickly understand whether the target has low, medium, high, or critical exposure. --- ## 🚨 Analytical Risk Score Identity360 Report includes an **Analytical Risk Score**. The score is calculated from multiple risk drivers, such as: - Credential exposure in breach blocks - ULP records containing password evidence - Public breach appearances - Public account footprint across platforms - Number of evidence links - Presence of sensitive identifiers - Cross-platform identity correlation - Volume and quality of confirmed signals Example risk levels may include: - Low - Medium - High - Critical A critical score means that the report contains strong exposure indicators, such as credential-related records, multiple breach appearances, or high-confidence public identity traces. The risk score is an analytical indicator. It should support investigation, not replace human validation. --- ## 👤 Profile Summary The Profile Summary aggregates identifiers discovered during the report. Possible identifier types include: - Email addresses - Usernames - Phone numbers - Names - Domains - Public account handles - Related services - Evidence-linked platforms This section helps analysts understand the broader digital identity graph connected to the target. Important: related identifiers should be interpreted with context. Some values may be confirmed evidence, while others may be weaker correlation signals. --- ## 🔗 Evidence Links The Evidence Links section collects links and source references discovered by the report. Evidence links may come from: - ULP records - Public breach evidence - Alias Radar profiles - CrossTrace account traces - Google Footprint signals - Public platform checks Each evidence link helps the user understand where a signal came from. Evidence links may point to: - Public profiles - Service login pages - Account presence endpoints - Historical breach-related URLs - ULP-related hosts - Platform-specific account traces Evidence links should be handled carefully and used only for lawful investigation and validation. --- ## 🌐 Public Accounts and Traces The Public Accounts and Traces section displays public profile or account-presence findings. A result may include:
FieldDescription
PlatformName of the detected service or platform
CategorySocial, media, Google, other, or another category
Display namePublic name found on the platform
UsernameUsername or handle, if available
Source moduleAlias Radar, CrossTrace, or another module
ConfidenceEstimated confidence score
Profile linkLink for manual validation
Confidence scores help analysts prioritize review. For example: - **100** may indicate a strong direct signal. - **70–80** may indicate a useful but still reviewable correlation. - Lower scores should be treated as weaker leads. Public account traces do not always prove ownership. They should be validated before being used in legal, compliance, or operational decisions. --- ## 🧱 Breach Exposure The Breach Exposure section summarizes public breach dataset appearances. It may include: - Total breach blocks - Credential blocks - Risk level - Source names - Whether password-related data exists - Whether personal data exists - Field counts - Group counts A breach block represents a structured group of fields from a particular breach source or collection. Credential blocks are especially important because they may contain password-related evidence or login-related exposure. --- ## 🔐 ULP Account Evidence The ULP Account Evidence section shows stealer-log or ULP-style account records connected to the target. It may include:
ColumnDescription
DateIndexed or observed date
HostRelated service, domain, or application
IdentityMatched email or username
PasswordPassword field, if available and permitted
URLEvidence or related service URL
The section may also show summary counters: - Total ULP records - Loaded records - Unique hosts - Records with passwords ULP evidence should be considered high-risk because it may indicate credential capture, malware compromise, browser credential theft, or reused credentials. --- ## 🔎 Filtering and Review The report interface may include filters for accounts, traces, records, and evidence. Users can review: - Public accounts - Breach sources - Credential blocks - ULP hosts - Evidence links - Related identifiers - Google signals - Module-specific findings Filtering helps analysts focus on the most relevant signals, especially in large reports with many records. --- ## 🧾 Clean Report JSON Identity360 Report can expose a clean structured JSON representation of the report. This JSON may include: - Report status - Report ID - Target - Target type - Created timestamp - Updated timestamp - Finished timestamp - Polling interval - Module states - Progress - Counters - Risk score - Risk drivers - Identifiers - Evidence links - Public accounts - Photos - Timeline - Module-specific raw or normalized data Clean JSON is useful for: - API integrations - SOC workflows - Internal dashboards - Case management systems - Threat intelligence pipelines - Compliance evidence - Automated reporting Sensitive values should be masked or protected depending on user permissions, session security, and export policy. --- ## 🕒 Timeline The report may include a timeline of discovered events and sources. Timeline entries may include: - Breach source names - ULP record dates - Public account discovery events - Evidence timestamps - Module processing milestones This helps analysts understand the chronological order of exposure indicators. For example, ULP evidence dated recently may require more urgent response than older historical breach appearances. --- ## 🖼️ Photos and Avatars Some modules may detect public profile images or avatars. These may come from: - Public profiles - Avatar services - Social platforms - Account metadata - CrossTrace results - Alias Radar results Profile images are useful for manual correlation, but they must not be treated as proof of identity without additional evidence. --- ## 🧠 Correlation Logic Identity360 Report is built around correlation, not blind certainty. The system combines multiple signal types: - Direct breach matches - Credential evidence - Email-based account traces - Username-based account traces - Public profile metadata - Evidence links - Related identifiers - Domain and host appearances - Module confidence scores Strong findings usually come from multiple independent signals pointing to the same target. Weak findings may be useful leads but should be validated before action. --- ## 🔐 Password and Sensitive Data Handling Some records may contain password evidence or other sensitive fields. Users must handle this data carefully. Passwords and sensitive values must only be used for: - Defensive verification - Account recovery - Password reset decisions - Incident response - Internal security review - Authorized employee exposure investigation Users must not: - Attempt unauthorized login - Perform credential stuffing - Share passwords publicly - Sell or trade leaked data - Use the data for harassment, fraud, phishing, or extortion - Publish private records - Export sensitive fields without authorization When screen sharing, reporting, or exporting, sensitive values should be masked unless full visibility is strictly required and authorized. --- ## 🛡️ Security, Privacy & Ethics Digital Footprint Intelligence is intended for lawful security work and authorized identity exposure analysis. Acceptable use cases include: - Checking your own email or username - Investigating employee exposure with authorization - Supporting incident response - Reviewing public account footprint - Validating breach exposure - Detecting credential compromise - Monitoring executive or VIP exposure - Performing compliance and security audits - Helping users secure compromised accounts Users must follow strict rules: - Search only targets you own or are authorized to investigate. - Do not use the report to stalk, harass, deanonymize, or target individuals. - Do not use exposed credentials for unauthorized access. - Do not redistribute leaked personal data. - Do not publish private identifiers or passwords. - Do not bypass platform limits, access controls, or masking. - Treat all findings as sensitive intelligence. - Validate results before legal, HR, compliance, or operational action. Abuse of the system may result in account restriction, suspension, or termination. --- ## ✅ Recommended Remediation Workflow When the report shows meaningful exposure, users should follow a structured response process. ### 1. Review the Executive Summary Start with the risk score, risk level, and risk drivers. ### 2. Check Credential Blocks Prioritize breach blocks that contain credential exposure. ### 3. Review ULP Evidence ULP records with passwords should be treated as high priority. ### 4. Validate Public Accounts Check public accounts and traces manually before drawing conclusions. ### 5. Reset Exposed Passwords Reset affected passwords and remove reused credentials. ### 6. Enable MFA Enable or enforce multi-factor authentication on affected accounts. ### 7. Review Login History Check account activity, IAM logs, SSO events, VPN access, email logs, and cloud service logs. ### 8. Check for Password Reuse Identify whether exposed passwords were reused across corporate or personal accounts. ### 9. Notify Affected Users Notify the affected person or internal team when appropriate and legally permitted. ### 10. Save Evidence Securely Store the report only in secure internal systems with restricted access. ### 11. Continue Monitoring Repeat checks periodically or enable continuous monitoring for high-risk identities. --- ## ⚙️ Technical Highlights - Unified digital identity report - Combines Public Breached Search, ULP Account Search, Alias Radar, Google Footprint, and CrossTrace - Supports email and username targets - Email local-part correlation for username modules - One billed request starts the report - AJAX progress polling every few seconds - Status polling does not consume daily quota - Executive summary - Analytical risk score - Risk drivers - Breach blocks - Credential blocks - ULP account evidence - Public accounts and traces - Evidence links - Google ecosystem signals - Profile summary - Related identifiers - Public profile confidence scores - Photos and avatar collection - Timeline of evidence - Clean report JSON - Module-level status tracking - Suitable for SOC, OSINT, compliance, incident response, and identity exposure workflows --- ## 📌 Usage Hints - Use an email or username as the target. - For email targets, review local-part username matches as correlation leads only. - Start with the risk score and risk drivers. - Treat ULP records with passwords as high priority. - Validate public account traces manually. - Review confidence scores before making conclusions. - Use evidence links for verification. - Check module status to understand whether the report is complete. - Do not assume pending or skipped modules found nothing. - Use Clean Report JSON for integrations and internal workflows. - Mask sensitive values when exporting or sharing reports. - Treat every report as confidential security intelligence. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or takedown-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Data Removal / Privacy Takedown Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX Digital Footprint Intelligence / Identity360 Report** is a unified identity exposure report that combines breach intelligence, ULP account evidence, public username reconnaissance, Google ecosystem signals, and public account tracing into one structured profile. The tool helps users understand whether an email or username is connected to public breaches, credential exposure, stealer-log records, public accounts, evidence links, and cross-platform identity traces. It is designed for lawful defensive cybersecurity, personal exposure checks, employee risk monitoring, incident response, compliance review, and digital footprint analysis. All findings should be validated before action and handled as sensitive security intelligence. # Alias Radar | Username Intelligence [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/g7L6CRnr2Kpq8cHS-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/g7L6CRnr2Kpq8cHS-image.png) The platform available at [**dash.niamonx.io/alias\_radar**](https://dash.niamonx.io/alias_radar) — known as **Alias Radar** — is an advanced username intelligence module within the NiamonX platform. It is designed to discover public username traces across social networks, forums, gaming platforms, developer communities, media services, financial platforms, OSINT sources, and other publicly accessible digital spaces. ## Overview of the Service **Alias Radar** helps analysts investigate whether a username appears across public platforms and online communities. The tool performs a backend-powered username scan, tracks progress in real time, removes duplicate and technical scanner noise, and returns a clean analyst-friendly report with meaningful account matches only. The service is intended for cybersecurity analysts, OSINT researchers, SOC teams, fraud investigators, compliance teams, brand protection specialists, and authorized users who need to identify public username presence across multiple online sources. Alias Radar is not designed to prove identity ownership automatically. A matching username should be treated as an investigative lead and verified manually by comparing public profile content, avatars, creation dates, platform IDs, bios, linked accounts, activity patterns, and other contextual signals. --- ## 🔍 How the Scan Works When a user submits a username, Alias Radar starts a backend scan through the NiamonX infrastructure. The scan checks the submitted username across thousands of supported sites and services. The system then processes raw matches, removes technical API noise, deduplicates repeated results, enriches profiles where possible, and presents only useful clickable findings. One request is consumed only when the scan starts. Live status checks do not consume additional tool quota. The browser checks scan progress every few seconds and stops polling permanently after the backend returns a final status. Typical scan flow: 1. User enters a username. 2. The scan request is sent to the NiamonX backend. 3. The backend checks supported public platforms. 4. Live progress is displayed in the browser. 5. Raw results are cleaned and deduplicated. 6. Enriched account details are extracted when available. 7. The final report is generated with categories, scores, identifiers, and profile links. --- ## 🧩 What Can Be Searched Alias Radar accepts usernames only. Valid examples: ```text niamonx ``` ```text @niamonx ``` If a username starts with `@`, the symbol is accepted and removed automatically before scanning. The tool does not accept: - Full URLs - Email addresses - Phone numbers - Domains - IP addresses - Search operators - Wildcards - Full names - Passwords - Multi-field composite queries Input rules:
RuleRequirement
Input typeUsername only
Allowed charactersLetters, numbers, dot, underscore, hyphen
Length2–64 characters
Leading `@`Accepted and removed automatically
URLsNot allowed
Email addressesNot allowed
--- ## ⚙️ Scan Interface The Alias Radar interface contains the following main sections. ### New Username Scan This section allows the user to start a new scan. Main fields: - Username input - Advanced scan options - Scan start button - Backend source indicator - Quota information The interface reminds users to enter a username without a URL. --- ### Advanced Scan Options Advanced scan options may allow the system to adjust how the username scan is performed. Depending on platform configuration, these options may control scan depth, enrichment behavior, supported source groups, or backend processing preferences. Advanced settings are designed for users who need more detailed reconnaissance while keeping the final output clean and analyst-friendly. --- ### Live Scan Status The live scan status panel shows the current state of the scan. It may display: - Current status - Current phase - Polling state - Number of status checks - Scan percentage - Number of checked sites - Completion timestamp - Elapsed time Example status values: ```text DONE ``` ```text Polling off ``` ```text 100% 2499 / 2499 sites ``` Polling runs once every few seconds and stops permanently after a final scan status is received. [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/Y54qvMegoPGfZ9H6-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/Y54qvMegoPGfZ9H6-image.png) --- ## 📊 Summary Section After a scan is completed, Alias Radar generates a structured summary. The summary may include: - Tool name - Daily request quota - Submitted username - Scan status - Found accounts - Progress percentage - Elapsed time - Extended profiles - Countries - Interest tags - Raw matches before and after cleaning Example summary structure: ```text Tool: alias_radar Status: DONE Found accounts: 22 Progress: 100% Elapsed time: 1m 50s Extended profiles: 6 Raw matches cleaned: 66 → 22 ``` The “raw matches cleaned” value is important because automated username scans often return noisy technical responses. Alias Radar filters those raw results and keeps only useful public matches. --- ## 🧠 Key Features ### Public Username Reconnaissance Alias Radar checks whether a username appears across public platforms and online communities. ### Large Source Coverage The scan can check thousands of supported sites and services. Example interface output may show: ```text 2499 / 2499 sites ``` ### Live Progress Tracking The user can follow the scan in real time while the backend processes supported platforms. ### Quota-Safe Polling Only the initial scan request consumes tool quota. Status polling does not consume additional daily requests. ### Cleaned Results Technical API noise, duplicate records, scanner definitions, and low-value diagnostic responses are removed before the final report is displayed. ### Deduplication The system merges duplicate matches and presents clean account-level findings. ### Analyst-Friendly Report Results are displayed as readable account cards with profile links, categories, scores, and extracted details. ### Enriched Account Details Where available, Alias Radar extracts useful public metadata, such as: - Display name - Bio - Avatar - Platform user ID - Username - Account creation date - Follower count - Following count - Repository count - Steam ID - Channel ID - Profile URL - Public platform-specific identifiers ### Categories and Interest Tags The tool groups results by categories and interest tags to help analysts understand the target’s public footprint. Possible categories may include: - Social - Code - Gaming - Forum - Messaging - Video - Streaming - Finance - Trading - Media - Security - Research - Sharing - Photo - Other ### Country Signals When available, the report may show country indicators inferred from public platform data or source metadata. Country signals should be treated as contextual hints, not confirmed residence or nationality. ### Extracted Identifiers Alias Radar extracts useful identifiers from public profiles and enriched records. Examples: - Username - Platform user ID - Steam ID - Twitch channel ID - Gravatar hash - GitHub user ID - Profile URL - Display name ### Copyable Report and Clean JSON The tool can provide a copyable analyst report and clean JSON output without raw API URLs, scanner logs, or noisy technical definitions. --- ## 📋 Found Accounts The **Found Accounts** section displays cleaned and deduplicated public matches only. Each account card may include:
FieldDescription
SitePlatform or service where the username was found
CategoryPlatform category such as Social, Code, Gaming, Forum, Finance, or Media
Display namePublic name shown on the profile, if available
UsernameMatched username
ScoreConfidence or relevance score
AvatarPublic profile image, if available
Profile linkClickable link to the public profile
MetadataExtracted public details returned by the backend
The interface may also include a filter field. Users can filter results by: - Site - URL - Category - Detail - Username - Public metadata --- ## 🧮 Score and Confidence Each found account may include a score. The score helps analysts prioritize results. Higher scores usually indicate stronger signals, such as: - Exact username match - Direct public profile - Enriched platform metadata - Public avatar - Stable platform identifier - Matching display name - Strong profile availability Lower scores may still be useful but should be reviewed more carefully. Example interpretation:
Score RangeMeaning
90–100Strong match or highly relevant public profile
70–89Good match, usually worth manual review
50–69Possible match or weaker public signal
Below 50Low-confidence signal, if shown
A score does not prove that all accounts belong to the same person. It only helps prioritize manual investigation. --- ## 🧬 Extended Profiles Some platforms return richer public data than others. An extended profile may include: - Public avatar - Display name - Bio - Creation date - Platform ID - Follower count - Following count - Public repositories - Public gists - Channel ID - Nickname - Account-specific metadata Examples of enriched platforms may include social networks, developer communities, gaming platforms, media services, and avatar providers. Extended profiles are especially useful for correlation because they provide additional public context beyond a simple username match. --- ## 🏷️ Categories and Interest Tags Alias Radar groups discovered accounts into categories and interest tags. Categories help analysts understand where the username appears. Possible categories:
CategoryDescription
SocialSocial networking platforms
CodeDeveloper platforms and code communities
GamingGaming profiles and game-related services
ForumPublic forums and discussion boards
MessagingMessaging or communication platforms
VideoVideo platforms
StreamingStreaming services
FinanceFinance, trading, donation, or payment-related platforms
MediaMedia, avatar, and content platforms
SecurityCybersecurity, breach, or OSINT-related sources
OtherPlatforms that do not fit a primary category
Interest tags help summarize the visible public footprint. Example tags may include: - gaming - forum - coding - messaging - video - social - streaming - trading - finance - security - sharing - photo - media These tags are useful for quick triage but should not be treated as personal conclusions without validation. --- ## 🌍 Country Signals Alias Radar may show country indicators when country-related signals are available. Example format: ```text Countries: us, ru ``` Country indicators can come from public platform data, source metadata, or backend enrichment. They should be interpreted carefully. A country signal may reflect platform region, profile metadata, content language, account history, or source classification. It does not necessarily confirm the person’s nationality, current location, or legal residence. --- ## 🔎 Extracted Identifiers The **Extracted Identifiers** section collects useful identifiers discovered during the scan. Possible extracted identifiers include:
Identifier TypeExample Use
UsernameConfirms the matched alias
Steam IDUseful for gaming profile correlation
GitHub IDUseful for developer profile correlation
Twitch Channel IDUseful for streaming or gaming analysis
Gravatar hashUseful for avatar and email-hash correlation
Platform UIDStable account identifier on a specific service
Profile URLDirect link for manual verification
Extracted identifiers help analysts connect results across platforms, but they must be validated before conclusions are made. --- ## 💾 Clean Analyst Report Alias Radar is designed to provide a clean report that can be copied into internal notes, SOC cases, OSINT documentation, or compliance workflows. The report may include: - Username - Scan status - Found accounts - Categories - Scores - Profile links - Enriched details - Countries - Interest tags - Extracted identifiers - Cleaned match count - Scan metadata The clean report intentionally avoids unnecessary scanner internals, noisy logs, raw API definitions, and irrelevant technical records. --- ## 🧾 Clean JSON Output In addition to the visual report, Alias Radar can provide clean JSON output. This is useful for: - API workflows - Internal dashboards - Case management systems - Threat intelligence pipelines - SOC automation - Evidence storage - Compliance reporting - Repeated monitoring Clean JSON should contain meaningful normalized results rather than noisy low-level scanner output. --- ## 🚦 Daily Quota Alias Radar uses daily plan-based request limits. The interface may display: ```text Available requests today: 999 Daily limit: 1000 Used today: 1 ``` Important quota behavior: - One request is consumed only when the scan starts. - Live status checks do not consume tool quota. - Polling runs every few seconds. - Polling stops permanently after a final status is received. - Daily limits depend on the user’s plan. This design allows users to monitor long-running scans without wasting quota on status checks. --- ## 🛡️ Implementation Security Alias Radar includes several security and reliability protections. ### Quota Protection Only the initial scan request is billed against the tool quota. Repeated status checks are not counted as additional scan requests. ### Controlled Polling Polling runs at a fixed interval and stops permanently after a final status is received. ### Input Normalization Leading `@` symbols are automatically removed. ### Input Restriction The tool accepts only usernames with allowed characters and length limits. ### Noise Reduction Technical scanner noise, duplicated raw matches, rate-limit artifacts, and irrelevant diagnostic records are removed from the final view. ### Analyst-Safe Output The final report focuses on public account traces and avoids exposing unnecessary backend internals. --- ## 📌 Result Interpretation Alias Radar results are public technical signals. A matching username does not prove that all accounts belong to the same person. Users should treat each result as a lead and validate it manually. Recommended validation signals: - Profile avatar - Display name - Bio - Account creation date - Public posts or activity - Linked accounts - Platform-specific ID - Language - Location hints - Reused profile images - Cross-platform links - Similar interests or categories - Historical username usage Some platforms may block automated checks, enforce rate limits, return uncertain responses, or expose only partial public data. Alias Radar hides noisy diagnostic records and focuses on useful clickable findings. --- ## ✅ Recommended Analyst Workflow A careful review process should follow these steps. ### 1. Start With High-Score Results Review accounts with the highest scores first. ### 2. Check Enriched Profiles Prioritize profiles with avatars, bios, creation dates, public IDs, or activity metadata. ### 3. Compare Public Signals Compare usernames, display names, avatars, links, and platform identifiers. ### 4. Separate Confirmed Signals From Leads Do not treat every username match as confirmed ownership. ### 5. Review Categories Use categories to understand whether the username appears mostly in social, gaming, code, forum, finance, or media contexts. ### 6. Extract Stable Identifiers Record stable IDs such as Steam ID, GitHub ID, Gravatar hash, or platform UID. ### 7. Preserve Evidence Carefully Save only what is necessary and permitted under applicable policy and law. ### 8. Avoid Overclaiming Use cautious wording such as “possible match,” “public trace,” or “correlation lead” unless ownership is verified. --- ## 🧠 Common Use Cases Alias Radar can support many legitimate workflows. ### Personal Digital Footprint Review Users can check where their own username appears publicly. ### Cybersecurity Investigation Security teams can identify public platform presence connected to known aliases. ### Threat Intelligence Analysts can map usernames used in forums, developer spaces, gaming communities, or public OSINT sources. ### Fraud and Abuse Investigation Authorized teams can investigate suspicious aliases connected to fraud, spam, impersonation, or account abuse. ### Brand and Executive Protection Organizations can monitor usernames related to executives, employees, projects, or brands. ### SOC and Incident Response Alias Radar can help correlate usernames found in logs, breach records, stealer logs, or suspicious activity. ### Compliance and Risk Review Teams can document public account exposure in a structured and repeatable format. --- ## 🛡️ Security, Privacy & Ethics Alias Radar is intended for lawful OSINT, defensive cybersecurity, fraud prevention, compliance, and authorized investigation. Users must follow strict ethical rules: - Search only usernames that you own or are authorized to investigate. - Do not use the tool to stalk, harass, threaten, shame, or target individuals. - Do not claim identity ownership based only on username matches. - Do not publish personal information discovered through the tool. - Do not use public traces for social engineering, phishing, extortion, or impersonation. - Do not attempt to bypass platform restrictions or access private data. - Do not contact individuals aggressively based on unverified results. - Validate all findings before operational, legal, HR, or compliance actions. - Treat reports as sensitive intelligence when used in investigations. Responsible use is essential because username reconnaissance can create false positives if interpreted incorrectly. --- ## ⚙️ Technical Highlights - Username intelligence module - Powered by NiamonX Backend - Public username reconnaissance across thousands of sites - Supports usernames with letters, numbers, dot, underscore, and hyphen - Leading `@` accepted and removed automatically - Live scan status - Fixed-interval polling - Polling stops after final status - Only initial scan consumes quota - Cleaned and deduplicated results - Technical API noise removal - Analyst-friendly account cards - Profile links - Category grouping - Score-based prioritization - Enriched account details when available - Extracted identifiers - Country signals when available - Interest tags - Copyable analyst report - Clean JSON output - Suitable for OSINT, SOC, fraud, compliance, and identity correlation workflows --- ## 📌 Usage Hints - Enter only a username, not a URL. - A leading `@` is accepted and removed automatically. - Use 2–64 characters. - Allowed characters are letters, numbers, dot, underscore, and hyphen. - Review high-score results first. - Treat each account as a lead, not proof. - Compare avatars, bios, creation dates, public IDs, and links. - Use extracted identifiers for stronger correlation. - Check categories and interest tags for quick triage. - Remember that some sites may block or limit automated checks. - Use clean JSON for integrations and internal workflows. - Store reports securely when used for investigations. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or takedown-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Data Removal / Privacy Takedown Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX Alias Radar** is a username intelligence tool that discovers public username traces across social networks, forums, gaming platforms, developer communities, media services, finance-related platforms, security sources, and OSINT databases. It starts a backend scan, tracks progress live, removes duplicate and technical records, enriches account details when available, extracts identifiers, groups results by category, and produces a clean analyst-friendly report. The tool is designed for lawful OSINT, defensive cybersecurity, identity correlation, fraud prevention, SOC workflows, and digital footprint analysis. Results should always be treated as public technical signals and manually verified before making conclusions about identity or ownership. # Google Footprint | Google Account & Drive Intelligence [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/h89tgFlx92bGyNiH-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/h89tgFlx92bGyNiH-image.png) The platform available at [**dash.niamonx.io/google\_footprint**](https://dash.niamonx.io/google_footprint) — known as **Google Footprint** — is a specialized intelligence module within the NiamonX platform designed to analyze public and technical traces of Google accounts, Gaia IDs, Google Drive files, and Google Sheets documents through the backend NiamonX API. ## Overview of the Service **Google Footprint** helps users collect a structured footprint of a Google identity or shared Google file. The tool can analyze a Gmail or Google email address, a Gaia ID, or a Google Drive / Google Sheets file identifier and return available public and technical signals. The module is designed for cybersecurity analysts, OSINT researchers, SOC teams, compliance departments, fraud investigators, and authorized security professionals who need to validate Google-related public traces during an investigation. Google Footprint can return information such as Google profile metadata, Gaia ID, avatar status, account type indicators, Google Chat signals, Maps profile availability, public contribution indicators, Drive file metadata, file owners, sharing role, technical JSON, and backend response diagnostics. The tool does not provide unauthorized access to private Google data. It only returns signals available through supported public, technical, or backend-accessible checks. --- ## 🔍 How the Analysis Works When a user starts a new analysis, the platform sends the selected input to the NiamonX backend API. Supported input types include: - Gmail / Google email address - Gaia ID - Google Drive file ID - Google Sheets file ID - Full Google Drive or Google Sheets URL Before the external request is performed, the system validates the input format. This helps prevent invalid requests, malformed values, unsupported identifiers, and accidental submission of unrelated data. The backend then performs the supported checks and returns a structured response. The interface displays a summary, account profile information, Google service signals, Maps indicators, Drive metadata, links, and technical JSON when requested. The result can be returned from cache or generated through a fresh backend check, depending on the request options and backend support. --- ## 🧩 What Can Be Analyzed Google Footprint supports several Google-related input types. ### Email A Gmail or Google account email address. Example: ```text alex@gmail.com ``` This mode checks the detected Google Account footprint and may return a Gaia ID when available through the API. [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/FjRJtweoae4zYWRv-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/FjRJtweoae4zYWRv-image.png) ### Gaia ID A numeric Google Account identifier. Example: ```text 112085282135050284090 ``` This mode is useful when the analyst already has a Gaia ID and needs to check related public or technical signals. [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/Vh0bK7ABYKj05X8f-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/Vh0bK7ABYKj05X8f-image.png) ### Google Drive / Google Sheets A Google Drive or Google Sheets file can be analyzed by pasting either the file ID or the full URL. Example file ID: ```text 1BxiMVs0XRA5nFMdKvBdBZjgmUUqptlbs74OgvE2upms ``` Example supported inputs may include: - Google Drive file ID - Google Sheets document ID - Full Google Drive URL - Full Google Sheets URL The tool may return file metadata, sharing role, owners, MIME type, checksum, title, size, creation date, modification date, and technical JSON depending on backend availability and file visibility. [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/ArTouPZNI1voYfKY-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/ArTouPZNI1voYfKY-image.png) --- ## ⚙️ New Analysis Interface The **New Analysis** section allows the user to choose the input type and submit the request to the backend API. Main interface elements:
FieldDescription
Input typeEmail, Gaia ID, Google Drive, or Google Sheets
Target valueThe email, Gaia ID, file ID, or file URL to analyze
Request `include_raw`Includes technical raw data for diagnostics and deeper analysis
Refresh without cacheRequests a fresh backend check when supported
Backend indicatorShows that the request is processed through the NiamonX API
--- ## 🧠 Key Features ### Google Account Analysis The tool can analyze Google account signals connected to a Gmail or Google email address. Possible returned fields include: - Email address - Gaia ID - Avatar type - Profile picture status - Profile modification date - Google user type - Google Chat entity type - Enterprise user flag - Public calendar flag - Play Games profile flag ### Gaia ID Detection When available, the tool returns the Google account’s Gaia ID. A Gaia ID is a stable Google account identifier that can help analysts correlate technical Google signals across different public or semi-public contexts. ### Avatar Analysis Google Footprint can identify whether the account uses a custom avatar or a default Google avatar. Possible values: - Custom avatar: Yes / No - Default avatar: Yes / No - Avatar URL or preview, when available - Profile picture availability A custom avatar can be useful for manual correlation, but it should not be treated as proof of identity by itself. ### Google Services Signals The module may check for available signals connected to Google services. Possible services and indicators include: - Google Photos - Google Maps - Google Meet - Google Chat - Google Calendar - Google Play Games - Enterprise account flags Some service indicators may not be returned for every request type. If activated services are not found or not returned, the interface should clearly display that no service data was available for that request. ### Google Maps / Contributions The module can show available Google Maps public footprint signals. Possible fields include: - Maps profile page availability - Reviews - Ratings - Photos - Contribution indicators - Review count - Rating count The presence of a Maps profile does not prove current activity. It only indicates that a public or technical Maps-related signal was detected. ### Google Drive / Sheets Metadata For Google Drive or Google Sheets targets, the tool may return file-level metadata. Possible fields include: - File title - File size - MIME type - Checksum - Creation date - Modification date - Sharing role - Owners - Links - Technical metadata - Raw JSON response This is useful for validating public files, checking exposed shared documents, reviewing ownership indicators, and documenting Drive-related evidence. ### Technical JSON The tool can expose technical JSON for deeper diagnostics. This is useful for: - SOC workflows - API integrations - Technical investigations - Internal documentation - Evidence preservation - Debugging backend responses - Comparing cached and fresh responses Raw technical output should be handled carefully and shared only with authorized users. --- ## 📊 Summary Section After an analysis is completed, Google Footprint displays a structured summary. The summary may include: - Request status - Input type - Cache status - Timestamp - Target - Module type - API duration - Total request time - Backend stderr output, if any Example structure: ```text Status: OK Type: EMAIL Cache: fresh Module: email API duration: 2044 ms Total request time: 2048.92 ms Cache: No stderr: — ``` This section helps analysts understand how the result was generated and whether the response came from a fresh backend check or cached data. --- ## 👤 Google Account Section The **Google Account** section displays the primary account-level findings. Possible fields include:
FieldDescription
EmailGoogle or Gmail address analyzed by the tool
Gaia IDGoogle account identifier returned by the backend
AvatarAvatar status or profile picture availability
Custom avatarIndicates whether a custom avatar exists
Default avatarIndicates whether the account uses the default avatar
Profile editLast detected profile edit timestamp, when available
User typeGoogle account type signal
Google ChatChat entity signal, such as PERSON
Enterprise userIndicates whether enterprise-related account signals are detected
Play Games profileIndicates whether Play Games profile data was found
Public calendarIndicates whether public calendar signals were found
The exact returned fields depend on the input type, backend support, Google-side availability, and cache/fresh request behavior. --- ## 🧬 Google User Types and Signals Google Footprint may return technical account-type indicators. Example signal: ```text GOOGLE_USER ``` This indicates that the checked identity is detected as a Google user through the supported backend logic. Other service-related fields may show whether specific Google ecosystem signals were available. Important: these indicators are technical signals. They should not be interpreted as complete account activity logs or proof that the user is currently active. --- ## 🖼️ Avatar and Profile Picture Analysis Avatar data can help analysts correlate a Google account with other public identity traces. Possible avatar-related indicators: - Profile picture exists - Custom avatar is used - Default avatar is not used - Avatar preview is available - Avatar URL is returned by the backend A custom avatar may be useful for manual comparison with other platforms, but it should always be validated with additional context. Recommended correlation signals: - Same profile image across platforms - Similar display name - Matching username - Same public links - Consistent timestamps - Related account metadata - Similar profile content Avatar matching alone should not be treated as identity proof. --- ## 🗺️ Google Maps / Contributions The **Google Maps / Contributions** section helps identify whether Maps-related public signals are available. Possible fields include:
FieldDescription
Profile pageIndicates whether a Maps profile page is available
ReviewsReview data or count, if available
RatingsRating data or count, if available
PhotosPublic contribution photos, if available
ContributionsPublic contribution indicators
If the report shows that a profile page is available but reviews or ratings are empty, it means that a Maps profile signal exists but no review or rating details were returned for that request. This section is useful for OSINT, fraud analysis, identity correlation, and digital footprint review. --- ## 📁 Google Drive and Google Sheets Analysis When a Google Drive or Google Sheets file is submitted, the module can check public and technical metadata associated with the file. Possible metadata includes: - File title - MIME type - File size - Checksum - Created time - Modified time - Owners - Sharing status - User role - Public links - Technical JSON This feature is useful for: - Checking exposed public documents - Reviewing shared file metadata - Validating ownership signals - Investigating leaked links - Documenting OSINT evidence - Understanding whether a Drive or Sheets file exposes metadata The tool does not bypass Google permissions. Returned data depends on what is available to the backend check. --- ## 🔗 Links Section The **Links** section collects available profile, Maps, Drive, or technical links returned by the backend. Links may include: - Google profile links - Google Maps profile links - Google Drive file links - Google Sheets links - Avatar links - Public service links Links are useful for manual validation and evidence review. Users should avoid opening suspicious or unknown links outside a safe analysis environment. --- ## 🧾 Request Options Google Footprint includes additional request options for deeper analysis and diagnostics. ### `include_raw` The `include_raw` option returns additional technical data when supported. Use cases: - Debugging backend responses - Reviewing raw API fields - Comparing normalized vs raw output - Preserving technical evidence - Advanced analyst workflows Raw output may contain verbose or sensitive technical details and should be handled carefully. ### Refresh Without Cache The refresh option requests a fresh backend check when supported. This is useful when: - The analyst needs the newest available response - Previous data may be outdated - Cache behavior needs to be bypassed - A file or profile may have changed recently Important: forcing refresh requests a fresh result, but the final behavior depends on backend API support and Google-side response behavior. --- ## 💾 Local Request History Google Footprint stores request history locally in the user’s browser through `localStorage`. This helps users access recent checks without server-side history navigation. Local storage may include: - Recent targets - Input types - Request timestamps - Basic request metadata Because the history is browser-local, it may be cleared if the user clears browser data, switches devices, or uses another browser profile. Sensitive targets should be handled carefully, especially on shared devices. --- ## 🚦 Cache and Fresh Results The interface may show whether a result was returned from cache or generated fresh. Possible cache states:
StateMeaning
cachedThe API returned a previously stored result
freshA new check was performed or fresh data was returned
no cacheThe result was not served from cache
force refreshThe user requested a fresh check
A cached result can be useful for speed and stability, but it may not reflect the latest available state. A force-refresh request asks the backend to perform a fresh check, but backend rules, provider limitations, and Google-side behavior may still affect the final response. --- ## 🧠 Result Interpretation Google Footprint results should be interpreted as technical footprint signals. The presence of a profile, Gaia ID, avatar, service signal, Maps page, or Drive metadata does not prove that the account is currently active. Important interpretation rules: - A Google profile signal means the account was detected, not necessarily recently used. - A custom avatar helps with correlation, but does not prove identity alone. - A Gaia ID is a technical identifier, not a complete identity profile. - Maps signals may indicate public availability, not current activity. - Drive metadata depends on file permissions and backend visibility. - Cached results may reflect earlier checks. - Missing service data does not always mean the service is absent. - Backend-supported checks may vary by input type. Analysts should combine Google Footprint results with other evidence, such as breach data, public profiles, account activity logs, OSINT findings, and internal investigation context. --- ## ✅ Recommended Analyst Workflow A careful analysis process should follow these steps. ### 1. Select the Correct Input Type Use Email for Gmail or Google account addresses, Gaia ID for known numeric identifiers, and Drive / Sheets for file investigations. ### 2. Validate the Target Make sure the submitted value is correctly formatted before running the check. ### 3. Review the Summary Check status, cache state, API duration, total request time, and backend diagnostics. ### 4. Review Google Account Signals Look for Gaia ID, avatar status, user type, profile modification date, and service indicators. ### 5. Check Maps and Service Data Review Maps profile availability, contribution signals, Calendar, Chat, Play Games, and enterprise flags. ### 6. Analyze Drive Metadata For file targets, review title, MIME type, owners, sharing role, creation date, modification date, and links. ### 7. Use Raw JSON Carefully Enable raw output only when technical details are needed for deeper analysis. ### 8. Compare With Other Sources Correlate results with Alias Radar, CrossTrace, breach intelligence, ULP data, and manual OSINT checks. ### 9. Avoid Overclaiming Treat all signals as technical indicators unless supported by additional evidence. ### 10. Store Evidence Securely Keep reports and JSON output in secure internal systems when used for investigations. --- ## 🛡️ Security, Privacy & Ethics Google Footprint is intended for lawful OSINT, defensive cybersecurity, fraud prevention, compliance review, and authorized investigation. Users must follow strict ethical rules: - Analyze only accounts, Gaia IDs, or files that you own or are authorized to investigate. - Do not use the tool to stalk, harass, intimidate, shame, or target individuals. - Do not claim identity ownership based on a single Google signal. - Do not attempt to access private Google data or bypass permissions. - Do not use discovered links for phishing, impersonation, fraud, or social engineering. - Do not publish personal information discovered through the tool. - Do not misuse avatar, Maps, or Drive metadata to deanonymize people. - Validate all findings before legal, HR, compliance, or operational decisions. - Treat technical JSON and reports as sensitive investigation material. The tool provides technical footprint intelligence. Responsible interpretation is required to avoid false positives and privacy harm. --- ## ⚙️ Technical Highlights - Google account footprint analysis - Supports Gmail / Google email addresses - Supports Gaia ID lookup - Supports Google Drive and Google Sheets file IDs or URLs - Powered by backend NiamonX API - Input validation before external request - Optional raw technical output with `include_raw` - Optional cache bypass with refresh request - Summary with status, module, cache, timing, and diagnostics - Google Account section with email, Gaia ID, avatar, user type, and profile modification data - Google services indicators - Google Maps / Contributions section - Google Drive metadata extraction - Owners, links, MIME type, checksum, size, and timestamps when available - Local browser request history through `localStorage` - Clean analyst-friendly interface - Suitable for OSINT, SOC, fraud analysis, compliance, and digital footprint investigations --- ## 📌 Usage Hints - Use Email mode for Gmail or Google account addresses. - Use Gaia ID mode when you already have a numeric Google account identifier. - Use Drive / Sheets mode for Google file IDs or full Google Drive / Google Sheets URLs. - Enable `include_raw` for technical diagnostics and deeper analysis. - Use refresh without cache when the latest available result is important. - Check cache status before interpreting freshness. - A profile or Gaia ID does not prove recent activity. - Missing services do not always mean the services are absent. - Treat Google Maps and avatar signals as correlation hints. - Validate Drive metadata manually when used as evidence. - Store reports securely when used in investigations. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or takedown-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Data Removal / Privacy Takedown Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX Google Footprint** is a Google account and file intelligence module that helps collect structured public and technical signals for Gmail accounts, Gaia IDs, Google Drive files, and Google Sheets documents. It can return account metadata, Gaia identifiers, avatar information, Google service signals, Maps profile indicators, Drive file metadata, owners, links, timing information, cache state, and technical JSON. The tool is designed for lawful OSINT, defensive cybersecurity, fraud analysis, compliance checks, SOC workflows, and digital footprint investigations. All findings should be treated as technical signals and validated with additional context before making conclusions. # CrossTrace | Username & Email Intelligence [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/kL0bT579cghDfPRX-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/kL0bT579cghDfPRX-image.png) The platform available at [**dash.niamonx.io/cross\_trace**](https://dash.niamonx.io/cross_trace) — known as **CrossTrace** — is a fast public identity intelligence module within the NiamonX platform. It is designed to search for public account traces connected to a username or email address and convert raw discovery signals into a clean, analyst-friendly report. ## Overview of the Service **CrossTrace** helps users discover public account-presence signals and profile traces associated with a single username or email address. The tool checks multiple public sources through the NiamonX backend, tracks scan progress live, removes technical scanner noise, and displays only readable, useful findings. The module is designed for cybersecurity analysts, OSINT researchers, SOC teams, fraud investigators, compliance departments, brand protection teams, and authorized users who need to quickly understand where a username or email may appear across public platforms. CrossTrace supports two main investigation modes: - Username search - Email search The final report may include clickable public profiles, account-presence indicators, avatars, platform categories, confidence scores, extracted public details, clean JSON, and a copyable analyst report. CrossTrace is not intended to prove account ownership automatically. A username match or email-presence signal should be treated as an investigative lead and manually verified using additional context. --- ## 🔍 How the Scan Works When a user starts a CrossTrace scan, the system creates one backend job through the NiamonX infrastructure. The backend checks supported public sources for traces linked to the submitted username or email address. While the job is running, the browser checks the scan status every few seconds using the existing scan ID. Only the initial scan consumes one daily request. Live status checks do not consume additional tool quota. Typical workflow: 1. The user enters a username or email address. 2. CrossTrace validates and normalizes the input. 3. A backend scan starts. 4. The interface displays live scan progress. 5. The backend checks supported public sources. 6. Raw scanner responses are cleaned and deduplicated. 7. Technical API endpoints, debug data, and noisy records are hidden. 8. The final report displays public traces, profile links, presence signals, categories, avatars, and scores. Polling stops immediately after a final status is reached, such as Done, failed, cancelled, or error. --- ## 🧩 What Can Be Searched CrossTrace supports two target types. ### Username A username can be entered with or without a leading `@`. Examples: ```text niamonx ``` ```text @niamonx ``` If the username starts with `@`, the symbol is accepted and removed automatically. Allowed username characters: - Letters - Numbers - Dot - Underscore - Hyphen The user should not enter a URL. ### Email A complete email address can be submitted as an email target. Example: ```text name@example.com ``` CrossTrace automatically detects the target as an email when the submitted value is a valid email address. --- ## 🚫 Unsupported Input CrossTrace is focused on usernames and email addresses only. The user should not submit: - Full URLs - Domains only - IP addresses - Phone numbers - Full names - Passwords - Wildcards - Search operators - Multi-field composite queries - Private tokens or API keys For domain, IP, breach, ULP, Google, or advanced identity reports, users should use the appropriate dedicated NiamonX module. --- ## ⚙️ New CrossTrace Scan Interface The scan interface contains the main controls required to start a new investigation. Main fields and panels:
ElementDescription
Username or email addressMain target input field
Scan optionsOptional scan configuration
Recent targetsQuick access to recent local targets
Live scan statusReal-time backend job progress
SummaryFinal report statistics
Found tracesCleaned and deduplicated results
Daily quotaPlan-based request usage
The interface clearly states that one daily request is consumed only when a scan starts. Live status checks do not consume tool quota. --- ## 📡 Live Scan Status The **Live Scan Status** section shows real-time progress until the scan reaches a final state. It may display: - Current status - Polling state - Timestamp - Current scan phase - Number of status checks - Progress percentage - Number of checked sources - Completion state Example status structure: ```text DONE Polling off Scan completed 9 status checks 100% 732 / 732 sources ``` Polling behavior: - Waits several seconds between checks - Uses the existing scan ID - Does not consume additional quota - Does not overlap requests - Stops permanently after a final status This makes CrossTrace suitable for live interactive analysis without wasting daily request limits on status checks. --- ## 📊 Summary Section After the scan completes, CrossTrace generates a summary of the discovered traces. The summary may include: - Tool name - Daily requests remaining - Target - Target type - Status - Found traces - Profile links - Presence signals - Progress - Elapsed time - Cache status - Identity categories - Unique sites - Avatar count Example summary format: ```text Tool: cross_trace Target: username Target type: Username Status: DONE Found traces: 12 Profile links: 10 Presence signals: 2 Progress: 100% Elapsed time: 41s Cached result: No Unique sites: 12 Avatars: 2 ``` The summary helps analysts quickly understand how many useful public traces were found and how many of them include direct profile links. [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/OEFjzkxgxDA5GCmF-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/OEFjzkxgxDA5GCmF-image.png) --- ## 🧠 Key Features ### Username and Email Intelligence CrossTrace can search public traces for both usernames and email addresses. ### Fast Backend Scan The tool starts one backend job and tracks it until completion. ### Live Progress The user can monitor scan progress in real time. ### Quota-Safe Status Checks Only the initial scan is quota-billed. Status checks use the existing scan ID and do not call the tool quota runner. ### Cleaned Results CrossTrace removes raw scanner endpoints, technical API data, debug logs, credentials, and noisy low-value records. ### Deduplication Repeated matches are merged into clean, unique traces. ### Public Profile Links When the scanner returns or safely derives a human-readable public profile URL, CrossTrace displays it as a clickable profile link. ### Account-Presence Signals Some services expose only whether an account appears to exist. CrossTrace labels these as account-presence signals. ### Avatars When available, public avatars are displayed for easier manual correlation. ### Categories Results are grouped into useful categories such as Identity, Streaming, Developer, Gaming, Social, Payments, Security, and Other. ### Confidence Scores Each trace may include a score to help analysts prioritize review. ### Clean JSON and Copyable Report CrossTrace can produce clean JSON and a copyable analyst report without raw API endpoints, job logs, scanner debug data, or credentials. --- ## 📋 Found Traces The **Found Traces** section displays cleaned and deduplicated results only. Each trace card may include:
FieldDescription
SitePlatform or source where the trace was found
CategorySource category, such as Identity, Gaming, Developer, or Social
NamePublic name or username shown by the source
Signal typeDirect profile or account-presence signal
ScoreConfidence or relevance score
AvatarPublic avatar, if available
DetailsExtra public metadata, if returned
Profile linkClickable profile URL, when available
The interface may also include filtering by: - Site - Category - Name - Signal - Detail This helps analysts focus on specific source types or high-value findings. --- ## 🔗 Profile Links vs Presence Signals CrossTrace separates findings into two important types. ### Public Profile Links A public profile link is a human-readable URL that can be opened and manually reviewed. Examples of profile-link evidence may include: - Public user profile - Public developer profile - Public gaming profile - Public streaming profile - Public social profile - Public avatar profile These links are useful because they allow the analyst to manually verify the account. ### Account-Presence Signals An account-presence signal means the system detected that a username or email appears to be associated with a service, but a public profile link may not be available. This may happen when: - A service exposes only availability checks - A profile is not publicly accessible - The source confirms existence but does not return public metadata - The scanner can detect the account but cannot safely derive a readable profile URL CrossTrace labels these results clearly as account signals. Presence signals are useful leads, but they should be interpreted more cautiously than direct profile links. --- ## 🧮 Score and Confidence Each trace may include a score. The score helps prioritize review and indicates the strength of the public signal. Example interpretation:
Score RangeInterpretation
90–100Very strong trace, usually a direct or enriched profile
80–89Strong trace, often a direct profile with reliable matching
70–79Useful trace, worth manual validation
60–69Presence signal or weaker public account indicator
Below 60Low-confidence signal, if displayed
A high score does not prove account ownership. It only indicates that the trace is technically strong or relevant enough to review first. --- ## 🏷️ Categories CrossTrace groups results into categories to make the report easier to understand. Common categories include:
CategoryDescription
IdentityIdentity or avatar-related services
StreamingStreaming and creator platforms
DeveloperCode, developer, and repository platforms
GamingGaming accounts and game-related platforms
SocialSocial networking services
PaymentsPayment, donation, or monetization platforms
SecurityCybersecurity, breach, or threat-intelligence related sources
OtherSources that do not fit a main category
Categories help analysts understand the type of public footprint connected to the target. For example, a username appearing across Developer and Gaming categories may suggest reuse across technical and gaming communities, while Identity or avatar services may help with cross-platform correlation. --- ## 🖼️ Avatars and Public Images Some CrossTrace results may include public avatars. Avatars can help analysts compare public profiles across platforms. Useful avatar-based correlation signals: - Same image reused across multiple services - Similar image style - Matching display name - Matching profile bio - Same username and avatar combination - Same linked accounts Avatar similarity should not be treated as proof of identity by itself. It should be combined with usernames, platform IDs, profile content, timelines, and additional evidence. --- ## 🧬 Enriched Metadata When available, CrossTrace may show enriched metadata for a trace. Possible metadata includes: - Display name - Username - Avatar - Platform identifier - Source category - Signal type - Profile URL - Public account details Some traces may return no extra public details. In that case, the interface clearly indicates that no extra public details were returned for that trace. This keeps the report transparent and avoids inventing unsupported information. --- ## 🧾 Clean JSON and Analyst Report CrossTrace can provide export-ready evidence summaries. The clean report may include: - Target - Target type - Scan status - Found traces - Unique sites - Profile links - Presence signals - Categories - Scores - Avatars - Public details - Timing information - Cache status The clean JSON output is useful for: - SOC workflows - Case management systems - OSINT documentation - Fraud investigations - Threat intelligence pipelines - Compliance records - Internal reporting - Automation and enrichment pipelines The output intentionally excludes raw API endpoints, job logs, scanner debug data, and credentials. --- ## 🚦 Daily Quota CrossTrace uses plan-based daily request limits. Example quota display: ```text Available requests today: 999 Daily limit: 1000 Used today: 1 Plan: Sentinel ``` Quota behavior: - One request is consumed when a scan starts. - Status checks do not consume quota. - Polling uses the existing scan ID. - Polling stops after a final status. - Daily limits depend on the user’s plan. This prevents unnecessary quota usage while still allowing live progress tracking. --- ## 💾 Recent Targets The interface may include a **Recent Targets** section. This helps users quickly rerun or review recent username and email checks. Recent target history should be treated carefully because usernames and emails may be sensitive in an investigation context. On shared devices, users should clear local browser data when necessary. --- ## 🧠 Result Interpretation CrossTrace results are public technical signals. A username match or email-presence signal does not prove that an account belongs to a specific person. Each result should be treated as a lead. Recommended validation checks: - Open public profile links when available. - Compare display names. - Compare avatars. - Review usernames and spelling. - Check platform-specific identifiers. - Compare account creation dates when available. - Review public activity and linked accounts. - Check whether the profile references the same websites, locations, interests, or aliases. - Compare the result with other NiamonX modules such as Alias Radar, Google Footprint, Identity360, ULP Search, or breach intelligence. Some services expose only account availability signals. CrossTrace labels those as account signals and hides technical endpoints to keep the report safe and readable. --- ## ✅ Recommended Analyst Workflow A careful CrossTrace investigation should follow this process. ### 1. Choose the Correct Target Type Use a username for alias-based checks or a complete email address for email-based traces. ### 2. Start the Scan Submit the target and let the backend job complete. ### 3. Review the Summary Check found traces, profile links, presence signals, unique sites, avatars, elapsed time, and cache status. ### 4. Prioritize Direct Profiles Start with direct profile links because they allow manual review. ### 5. Review High-Score Results High-score traces should be checked first. ### 6. Separate Profile Links From Presence Signals Presence signals are useful but weaker than direct public profile links. ### 7. Compare Public Details Use avatars, display names, usernames, linked accounts, and identifiers for correlation. ### 8. Avoid Overclaiming Use cautious wording such as “possible trace,” “public signal,” or “account-presence indicator” unless ownership is verified. ### 9. Export Evidence Use clean JSON or the copyable analyst report for internal documentation. ### 10. Store Results Securely Treat reports as sensitive investigation data, especially when they contain emails, usernames, avatars, or account-presence signals. --- ## 🛡️ Security, Privacy & Ethics CrossTrace is intended for lawful OSINT, defensive cybersecurity, fraud prevention, brand protection, compliance, and authorized investigation. Users must follow strict ethical rules: - Search only usernames or email addresses that you own or are authorized to investigate. - Do not use CrossTrace to stalk, harass, shame, threaten, or target individuals. - Do not claim identity ownership based only on a username match or presence signal. - Do not use account traces for phishing, impersonation, social engineering, fraud, or extortion. - Do not attempt to access private accounts or bypass platform restrictions. - Do not publish personal information discovered through the tool. - Do not contact individuals aggressively based on unverified results. - Validate all findings before legal, HR, compliance, or operational decisions. - Treat exported reports as sensitive intelligence material. Responsible interpretation is essential because public account discovery can produce false positives, especially when usernames are reused by different people. --- ## ⚙️ Technical Highlights - Username and email intelligence module - Powered by NiamonX Backend - Supports username search - Supports email search - Live progress until Done - One backend job per scan - One daily request consumed only when the scan starts - Status checks do not consume tool quota - Polling interval between checks - No overlapping status requests - Polling stops after Done, failed, cancelled, or error status - Checks hundreds of public sources - Cleaned and deduplicated matches - Raw scanner endpoints hidden - Technical API data hidden - Public profile links when available - Account-presence signal labeling - Avatars when available - Category grouping - Confidence scores - Clean JSON output - Copyable analyst report - Recent targets support - Suitable for OSINT, SOC, fraud, compliance, and identity correlation workflows --- ## 📌 Usage Hints - Enter a username without a URL. - A leading `@` is accepted for usernames and removed automatically. - Enter a complete email address for email-based checks. - Review direct profile links first. - Treat presence signals as weaker leads. - Use scores to prioritize review. - Compare avatars, names, identifiers, timelines, and linked accounts. - Do not assume all matching usernames belong to the same person. - Use clean JSON for internal workflows and evidence storage. - Treat exported results as sensitive investigation material. - Validate findings manually before taking action. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or takedown-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Data Removal / Privacy Takedown Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX CrossTrace** is a fast username and email intelligence module that searches for public account traces and account-presence signals across supported public sources. It starts one backend scan, tracks progress live, cleans and deduplicates raw results, hides technical scanner data, and presents a readable analyst report with profile links, presence signals, avatars, categories, scores, clean JSON, and export-ready summaries. The tool is designed for lawful OSINT, defensive cybersecurity, fraud investigation, brand protection, SOC workflows, compliance review, and identity correlation. All results should be treated as public technical signals and manually verified before making conclusions about identity or ownership. # Networks and WiFi Networks and WiFi # Wifi Map & Data Search | WiFi Hotspot Intelligence [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/abnnkejRlTgUK2uM-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/abnnkejRlTgUK2uM-image.png) The platform available at **[https://dash.niamonx.io/wifi\_data](https://dash.niamonx.io/wifi_data)** — known as **Wifi Map & Data Search** — is a WiFi hotspot intelligence and research tool within the NiamonX platform. It allows authorized users to search publicly available WiFi hotspot datasets by BSSID, ESSID, or WiFi key indicators and visualize matching access points on an interactive map. ## Overview of the Service **Wifi Map & Data Search** is designed for research, security analysis, wireless exposure review, and OSINT-style investigation of publicly available WiFi hotspot records. The tool allows users to search known hotspot data using several search modes, including BSSID, ESSID, and WiFi key. Results may include network identifiers, security type, weak-key indicators, approximate coordinates, and map visualization. The service is intended strictly for lawful research, defensive security, infrastructure audit, and awareness purposes. It must not be used to access networks without authorization. WiFi data can be sensitive because it may include network names, access point identifiers, approximate locations, and historical credential-like values. Users must handle results responsibly and comply with local laws. --- ## 🔍 How the Search Works When a user enters a query, the system searches a publicly available WiFi hotspot dataset using the selected mode. Supported search modes include: - BSSID search - ESSID search - WiFi key search The backend returns matching records, and the interface displays them in a structured results table. If coordinates are available, matching points can also be shown on a Leaflet map powered by OpenStreetMap. The system supports rate limiting and short-term caching. Cache is typically valid for a few minutes, which helps reduce repeated backend requests for identical queries. Example search flow: 1. Select a search mode. 2. Enter a BSSID, ESSID, or WiFi key indicator. 3. Submit the query. 4. Review matching hotspot records. 5. Check security type and weak-key indicators. 6. View approximate location on the map when coordinates are available. 7. Export visible rows when needed. 8. Use results only for lawful and authorized research. --- ## 🧩 What Can Be Searched Wifi Map & Data Search supports several query types. ### BSSID BSSID is the MAC address of a wireless access point. Example format: ```text 00:11:22:33:44:55 ``` BSSID search is useful when the analyst has a known access point identifier and wants to check whether it appears in the dataset. --- ### ESSID ESSID is the public WiFi network name, often shown as the visible WiFi name on devices. Example: ```text Office_WiFi ``` ESSID searches may support different match modes: - `substr` - `prefix` - `exact` This allows users to search for networks by full name, prefix, or partial string. --- ### WiFi Key WiFi key search allows checking whether a specific known key value appears in the dataset. This mode should be used carefully and only for defensive or authorized research, such as verifying whether a weak or reused test password appears in public data. Sensitive keys should be masked in documentation, reports, screenshots, and exports. Example masked format: ```text ******** ``` --- ## ⚙️ Search Modes The tool supports multiple modes depending on the type of value being searched.
ModeDescription
`bssid`Search by access point MAC address
`essid`Search by WiFi network name
`wifikey` / `password`Search by WiFi key indicator
Depending on the interface version, the WiFi key mode may be shown as `password`, `wifikey`, or similar internal naming. --- ## 🔎 ESSID Match Modes ESSID search can use different matching modes.
Match ModeDescription
`substr`Finds ESSIDs containing the entered text
`prefix`Finds ESSIDs starting with the entered text
`exact`Finds only exact ESSID matches
Examples: ```text substr: finds "Office_WiFi_Main" when searching "WiFi" ``` ```text prefix: finds "Office_5G" when searching "Office" ``` ```text exact: finds only "Office_WiFi" ``` Using exact mode reduces noise. Substring mode is useful for broad discovery but may return unrelated results. --- ## 📊 Results Table After a successful search, matching records are shown in a structured table. Typical columns include:
ColumnDescription
BSSIDNumeric or internal BSSID representation
BSSID stringStandard MAC address format
ESSIDWiFi network name
WiFi KeyKey value, if present and permitted
SecurityDetected or inferred security type
WeakWeak-key or weak-security indicator
CoordsLatitude and longitude, if available
ActionsAvailable record actions
Sensitive fields such as WiFi keys should be masked when screenshots, reports, or documentation are shared. Example safe display format: ```text BSSID: 00:11:22:33:44:55 ESSID: Example_Network WiFi Key: ******** Security: WPA2/WPA3 Coords: 47.0000, 35.0000 ``` --- ## 🗺️ Map View The tool includes a map view for records with coordinates. The map is based on Leaflet and OpenStreetMap. The interface may display up to a limited number of points, for example: ```text Map: up to 200 points ``` The map helps users visually understand the geographic distribution of matching access points. Map use cases: - Reviewing hotspot concentration - Checking approximate network location - Validating whether a BSSID appears in an expected area - Identifying exposed or outdated records - Supporting wireless infrastructure audits Coordinates should be treated as sensitive. They may represent approximate or historical locations and should not be used for harassment, trespassing, or unauthorized access. --- ## 🧠 Key Features ### Public WiFi Dataset Search The tool searches publicly available WiFi hotspot records for research and analysis. ### BSSID Lookup Users can search for a specific access point MAC address. ### ESSID Lookup Users can search by network name with substring, prefix, or exact matching. ### WiFi Key Indicator Search Users can check whether known key values appear in the dataset for authorized security review. ### Security Heuristics The tool displays inferred security information such as WPA2, WPA3, WEP, or open-network indicators when available. ### Weak Indicator The system may mark a record as weak when the key is empty, simple, reused, or when the detected security configuration appears low-security. ### Coordinates Records may include latitude and longitude. ### Leaflet Map Matching records with coordinates can be visualized on an interactive map. ### Rate Limit The interface shows remaining requests and reset timing. ### Cache Repeated searches may be cached for a short time. ### Local Request History Recent searches are stored locally in the browser. ### CSV Export Visible rows can be exported to CSV. --- ## 🚦 Rate Limit and Cache Wifi Map & Data Search includes rate limiting and caching. Example rate-limit format: ```text Limit: 119 left / reset 600s ``` This means the user has a certain number of requests remaining until the reset window. Cache behavior: ```text Cache is valid for approximately 3 minutes. ``` Caching helps reduce repeated backend lookups for identical queries and improves response speed. Rate limits help protect the service from abuse and ensure fair access. --- ## 🕓 Request History The **Request History** panel stores recent searches locally in the browser. History entries may include: - Search mode - Query value - ESSID match mode - Timestamp Example safe history format: ```text bssid 00:11:22:33:44:55 17.06.2026, 21:47:35 ``` Local history is useful for repeating previous searches, but it may contain sensitive search values. Users should clear browser data or local history when working on shared or public devices. --- ## 📤 CSV Export The tool can export visible rows to CSV. CSV export may include: - BSSID - ESSID - Security type - Weak indicator - Coordinates - Other visible record fields Sensitive values such as WiFi keys should be masked or excluded before sharing externally. CSV exports should be stored securely and used only for authorized research, reporting, or internal audit workflows. --- ## 🔐 Security Field Interpretation The **Security** column is based on heuristics and available dataset values. Possible security labels may include: - Open - WEP - WPA - WPA2 - WPA3 - WPA2/WPA3 - Unknown Some internal numeric values may map to security guesses. Example interpretation: ```text 128 = possible WEP / Open 225 = possible WPA2 ``` These values are heuristic and should not be treated as guaranteed technical truth. Manual validation is recommended for security audits. --- ## ⚠️ Weak Indicator The **Weak** field helps identify potentially risky hotspot records. A network may be marked weak when: - The key is empty - The key is very short - The key is simple or common - The key appears in weak-password patterns - The security type is low - The network appears open or outdated - The encryption method is weak or uncertain Weak indicators should be treated as triage signals, not final conclusions. Organizations should review their own networks and replace weak configurations with strong WPA2/WPA3 security and unique passwords. --- ## 🧠 Result Interpretation WiFi dataset results should be interpreted carefully. Important notes: - Records may be historical. - Coordinates may be approximate. - ESSID names are not unique. - BSSID values can be spoofed or replaced. - WiFi keys may be outdated. - Security labels are heuristic. - A record appearing in the dataset does not guarantee current network availability. - A matching WiFi key must not be used for unauthorized access. - Map points may not represent the current physical location of an access point. The tool should be used for research, verification, and defensive awareness, not for intrusion or unauthorized connectivity. --- ## ✅ Recommended Research Workflow A responsible workflow should follow these steps. ### 1. Select the Correct Mode Use BSSID for access point identifiers, ESSID for network names, and WiFi key search only for authorized security review. ### 2. Use Exact Search When Possible Exact search reduces false positives, especially for ESSID values. ### 3. Review Security and Weak Indicators Check whether the record suggests weak security or risky configuration. ### 4. Check Coordinates Carefully Use map data as approximate context, not absolute proof. ### 5. Avoid Exposing Keys Mask WiFi keys in reports, screenshots, and documentation. ### 6. Export Only What Is Needed Use CSV export only for authorized workflows. ### 7. Remediate Owned Networks If a network you control appears with a weak key or exposed record, rotate credentials and update security settings. ### 8. Validate Before Action Do not assume that dataset records are current or fully accurate. --- ## 🛡️ Security, Privacy & Responsible Use Wifi Map & Data Search is a sensitive OSINT and research tool. It must be used responsibly. Acceptable use cases include: - Auditing your own WiFi networks - Checking whether known BSSIDs appear in public datasets - Reviewing exposure of organizational hotspots - Researching weak or reused WiFi configurations - Defensive wireless security assessment - Academic or statistical analysis of public WiFi data - Mapping public hotspot exposure trends - Supporting compliance and risk reviews Strictly prohibited use includes: - Unauthorized access to WiFi networks - Attempting to connect using discovered keys - Trespassing to reach network locations - Harassment or stalking based on coordinates - Publishing sensitive WiFi keys - Selling or redistributing access credentials - Using results for intrusion, fraud, or abuse - Targeting private homes or individuals - Bypassing network access controls Users must comply with the laws of their jurisdiction and platform rules. Misuse may result in account restriction or termination. --- ## 🔧 Remediation Recommendations If an owned or authorized network appears in search results with risky data, recommended actions include: ### Change the WiFi Password Immediately rotate exposed or weak credentials. ### Use WPA2/WPA3 Avoid WEP, open networks, and outdated encryption. ### Use a Strong Unique Key Use a long, random password that is not reused elsewhere. ### Disable WPS WPS can introduce additional attack surface. ### Rename Sensitive ESSIDs Avoid exposing company names, addresses, personal names, or device roles in the ESSID. ### Segment Guest Networks Keep guest WiFi separate from internal systems. ### Review Router Firmware Update access point firmware and apply security patches. ### Monitor for Re-Exposure Recheck periodically after remediation. --- ## ⚙️ Technical Highlights - WiFi hotspot intelligence tool - Available at `dash.niamonx.io/wifi_data` - Searches publicly available WiFi hotspot datasets - Supports BSSID search - Supports ESSID search - Supports WiFi key indicator search - ESSID match modes: substring, prefix, exact - Results table with BSSID, ESSID, security, weak indicator, coordinates, and actions - Leaflet map visualization - OpenStreetMap base layer - Map displays up to a limited number of points - Rate-limit counter - Short-term cache of approximately 3 minutes - Local browser request history - CSV export for visible rows - Security heuristics - Weak-key heuristics - Intended for research, audit, OSINT, and defensive security workflows --- ## 📌 Usage Hints - Use BSSID mode for exact access point MAC lookup. - Use ESSID exact mode when searching for a precise network name. - Use ESSID prefix or substring mode for broader discovery. - Treat coordinates as approximate or historical. - Do not use discovered keys for unauthorized access. - Mask WiFi keys in reports and screenshots. - Use the Weak field as a triage signal. - Use Security as a heuristic, not a guaranteed classification. - Cache is valid for approximately 3 minutes. - Rate limit shows remaining requests. - CSV export includes visible rows. - Clear local history on shared devices. - Check local laws before using WiFi dataset intelligence. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX Wifi Map & Data Search** is a WiFi hotspot intelligence tool for searching publicly available hotspot records by BSSID, ESSID, or WiFi key indicators. It provides structured results, security heuristics, weak-key indicators, coordinates, Leaflet map visualization, rate limiting, short-term caching, local browser history, and CSV export. The tool is intended for lawful research, wireless security auditing, OSINT analysis, exposure review, and defensive remediation. It must never be used for unauthorized network access, harassment, credential misuse, or privacy-invasive activity. # IP Intelligence Search | Global IP Lookup [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/P649caNtAG4947kE-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/P649caNtAG4947kE-image.png) The platform available at **[https://dash.niamonx.io/global\_iplookup](https://dash.niamonx.io/global_iplookup)** — known as **IP Intelligence Search (Global IP Lookup)** — is a global IP intelligence and infrastructure analysis tool within the NiamonX platform. It allows users to search detailed information about IPv4 and IPv6 addresses using the NiamonX Crawler database catalog and receive structured data about geolocation, ASN, organization, ISP, open ports, services, hostnames, domains, vulnerabilities, fingerprints, and raw service metadata. ## Overview of the Service **IP Intelligence Search (Global IP Lookup)** is designed for analysts, SOC teams, cybersecurity researchers, incident responders, infrastructure owners, and OSINT specialists who need to understand what is publicly observable about a specific IP address. The tool provides a consolidated view of an IP address from a global crawler database. It can show the IP’s network ownership, ASN, organization, ISP, country, region, city, coordinates, related hostnames, associated domains, exposed ports, detected products, service banners, HTTP metadata, SSL-related data when available, vulnerability aggregation, CVSS scoring, tags, labels, and raw JSON for deeper inspection. The module accepts only IP addresses. Domains, URLs, paths, and search operators are not valid inputs. --- ## 🔍 How the Search Works When a user enters an IPv4 or IPv6 address, the tool queries the global crawler database catalog and returns the available record for that IP. The returned information may include: - General IP information - ASN and network ownership - ISP and organization - Country, region, city, and coordinates - Map location - Hostnames - Domains - Open ports - Protocols - Products and versions - Service details - HTTP metadata - SSL metadata, when available - Vulnerability data - CVE count - Maximum CVSS score - Scan dates - Raw service JSON - Historical layers, when available and enabled The tool displays general information first, then provides a detailed services and ports table. Large service responses are rendered lazily, meaning details are shown only when the user expands a specific service row. This reduces browser and DOM load, especially for IPs with many open services. --- ## 🧩 What Can Be Searched Global IP Lookup supports: - IPv4 addresses - IPv6 addresses Valid examples: ```text 1.1.1.1 ``` ```text 8.8.8.8 ``` ```text 2001:4860:4860::8888 ``` Unsupported inputs: ```text example.com ``` ```text https://example.com ``` ```text example.com/login ``` ```text 1.1.1.1:443 ``` The tool expects only a clean IPv4 or IPv6 value. --- ## ⚙️ Search Interface The interface contains the main input and optional historical data setting. ### IP Address The main field where the user enters an IPv4 or IPv6 address. Example: ```text 1.1.1.1 ``` The interface clearly states: ```text Only IPv4 or IPv6. No domains or URLs. ``` ### Historical Data The **Historical Data** option allows the server to return archival information when supported. Historical layers may include older observations, previous ports, older banners, previous technologies, or past service states. Important: historical data is returned only when available and supported by the backend. --- ## 📊 General Information After a successful lookup, the tool displays a general information panel for the IP address. Possible fields include:
FieldDescription
IPQueried IPv4 or IPv6 address
ASNAutonomous System Number
OrganizationNetwork owner or responsible organization
ISPInternet Service Provider
CountryCountry and country code
Region / CityGeographic region and city
CoordinatesLatitude and longitude
PortsNumber of observed ports
ServicesNumber of service records
HostsNumber of hostnames
DomainsNumber of related domains
TagsNumber of tags or labels
Example structure: ```text IP: 1.1.1.1 ASN: AS13335 Organization: Example Network Project ISP: Example ISP Country: Australia (AU) Region / City: QLD / Brisbane Coordinates: -27.48159, 153.0175 Ports: 11 Services: 12 Vulns: 0 ``` This section gives users a quick operational overview of the IP address before reviewing individual services. --- ## 🗺️ Geolocation and Map The tool includes a geolocation map powered by Leaflet and OpenStreetMap. The map displays the approximate location of the IP address based on geolocation data returned by the crawler database. Possible location fields: - Country - Country code - Region - Region code - City - Latitude - Longitude Important interpretation notes: - IP geolocation is approximate. - The city may represent network registration, routing, infrastructure, or geolocation provider estimation. - Coordinates may not represent the physical location of a device. - Cloud, CDN, VPN, proxy, and resolver IPs may show provider locations rather than end-user locations. Geolocation should be used as context, not as precise physical attribution. --- ## 🏷️ Tags and Labels The tool can display tags and labels returned by the crawler database. Examples of possible tags: - CDN - Cloud - VPN - Proxy - Resolver - Hosting - Mail - Web - Database - Industrial - IoT - Remote access If no tags are returned, the interface may display: ```text No ``` Tags help analysts quickly classify the IP, but they should be treated as metadata rather than final conclusions. --- ## 🌐 Hostnames and Domains The tool displays hostnames and domains associated with the IP address when available. ### Hostnames Hostnames may include DNS names, reverse DNS names, or observed service names. Example: ```text one.one.one.one ``` ### Domains Domains may include root domains or associated domains found in the crawler data. Example: ```text one.one ``` Important notes: - Hostnames and domains may be historical. - Shared infrastructure may host many unrelated domains. - CDN and cloud IPs can be associated with multiple customers. - A hostname association does not always mean exclusive ownership of the IP. --- ## 🔌 Services and Ports The **Services / Ports** section displays observed open ports and detected services. The table may include:
ColumnDescription
PortPort number
ProtocolTCP or UDP
Product / VersionDetected product and version
CVEsNumber of linked CVEs
Max CVSSMaximum vulnerability severity score
ScanScan date
Example service rows: ```text 53 TCP — 0 — 2026-06-17 443 TCP CloudFlare 0 — 2026-06-17 8880 TCP CloudFlare 0 — 2026-06-17 ``` The table can be filtered by port or product name, allowing analysts to quickly find relevant services. --- ## 🔎 Service Filtering and Sorting The services table supports quick filtering. Users can search by: - Port number - Product name - Version - Protocol - Service text Example: ```text Filter: 443 ``` ```text Filter: CloudFlare ``` Sorting by columns helps analysts prioritize: - Exposed services - Highest CVSS score - Most recent scan date - Specific ports - Specific protocols - Products with known vulnerabilities --- ## 🧾 Service Details Clicking the disclosure button on a service row opens detailed service information. The details view may include: ### Main - Product - Version - Operating system - Scan date ### HTTP - HTTP status - Server header - Page title - Redirect location - WAF or CDN indicator - Headers hash - HTML hash - DOM hash - Robots data - Sitemap data - Security.txt data - Components ### Location - City - Country - Coordinates ### Vulnerabilities - CVE list - CVSS scores - Vulnerability metadata, when available ### Raw JSON - Full normalized service record returned by the backend This drill-down structure allows the interface to remain fast while still providing deep technical visibility when needed. --- ## 🌐 HTTP Metadata For HTTP or HTTPS services, the tool may show HTTP-level metadata. Possible fields include:
FieldDescription
StatusHTTP status code
ServerServer response header
TitleHTML page title
LocationRedirect target
WAFWeb application firewall or CDN indicator
ComponentsDetected technologies
HTML hashHash of returned HTML
Headers hashHash of headers
DOM hashDOM fingerprint
Security.txtSecurity policy file data, if found
Robots.txtRobots file data, if found
SitemapSitemap data, if found
Example: ```text Status: 301 Server: cloudflare Title: 301 Moved Permanently Location: / ``` HTTP metadata is useful for web service fingerprinting, CDN detection, redirect analysis, and change tracking. --- ## 🧬 Hashes and Fingerprints The tool may display multiple hashes and fingerprints. Examples: - HTML hash - Headers hash - DOM hash - Server hash - Title hash - Banner hash - Service hash These hashes are useful for: - Detecting repeated infrastructure - Finding similar services - Tracking changes over time - Fingerprinting web applications - Comparing banners - Identifying reused templates - Monitoring service drift A hash does not identify a service by itself. It is a technical fingerprint that should be interpreted with context. --- ## 🛡️ Vulnerability Aggregation The tool aggregates vulnerability data for services when CVEs are available. The service table may show: - Number of CVEs - Maximum CVSS score - Vulnerability details - A severity color label ### CVSS Color Labels The interface may use color labels based on CVSS score. General interpretation:
CVSS RangeSeverity
≤ 4Low
4–7Medium
≥ 7High
The **Max CVSS** field shows the maximum vulnerability score associated with the service. Important: a CVE association does not always prove exploitability. Product detection, version accuracy, configuration, and exposure context must be validated manually. --- ## 📦 Raw JSON Viewer Each service can include a raw JSON view. Raw JSON may contain: - Product detection - HTTP metadata - Scan timestamp - Organization - ISP - ASN - Port - Protocol - Hostnames - Domains - Location - CPE / CPE 2.3 identifiers - Hashes - Banner data - Scanner metadata - Transport information - Vulnerability data Raw JSON is useful for: - Technical diagnostics - API workflows - Evidence preservation - Security reporting - Advanced analysis - Integration with SIEM or case systems - Comparing normalized and raw fields Raw data should be handled carefully because it may include detailed infrastructure fingerprints. --- ## 🕓 Historical Data When the **Historical Data** option is enabled, the backend may return archival information if supported. Historical data can help analysts understand: - Previously open ports - Past service banners - Old product versions - Previous hostnames - Infrastructure changes - Exposure timeline - Service drift - Reappearance of risky services Important interpretation: ```text When History is enabled, the server may return historical layers if supported. ``` Historical data may not be available for every IP address and should be clearly separated from current observations. --- ## 📤 Export and Copy Options The tool supports analyst-friendly export and copy workflows. Possible output options include: - Summary copying - JSON copying - CSV export - Raw service JSON viewing - Filtered service review CSV export is useful for: - Port inventory - Exposure reports - Vulnerability review - Asset documentation - SOC workflows - Compliance evidence - Incident response records Exports should be stored securely, especially when they include infrastructure fingerprints or vulnerability data. --- ## 🕘 Request History The tool may store entered IPs in local browser history through LocalStorage. History can help users quickly repeat previous lookups. Local history may include: - IP address - Query timestamp - Search mode - History option state - Basic result metadata Because this history is browser-local, it may be cleared when users delete browser data or switch devices. On shared devices, local history should be cleared after sensitive investigations. --- ## 🧠 Key Features ### Global IP Lookup Search detailed information about IPv4 and IPv6 addresses. ### NiamonX Crawler Database Results come from the global crawler database catalog. ### General IP Intelligence Shows ASN, organization, ISP, country, region, city, coordinates, ports, services, hostnames, domains, and tags. ### Geolocation Map Displays approximate location on a Leaflet / OpenStreetMap map. ### Service and Port Inventory Lists observed open ports, protocols, products, versions, scan dates, CVE counts, and Max CVSS. ### Vulnerability Aggregation Aggregates CVE and CVSS data per service when available. ### Raw JSON Allows detailed inspection of service-level raw records. ### Lazy Rendering Large service details are rendered only when opened, reducing browser load. ### Historical Data Can request archival information when supported. ### Filtering and Sorting Users can search services by port or product name and sort columns. ### Export Supports summary / JSON copy and CSV export. ### Local History Stores previously entered IPs locally in the browser. --- ## ✅ Recommended Analyst Workflow A practical IP investigation workflow should follow these steps. ### 1. Enter a Clean IP Address Use only IPv4 or IPv6. Do not include domains, URLs, ports, or paths. ### 2. Review General Information Check ASN, organization, ISP, country, region, city, coordinates, ports, services, hostnames, and domains. ### 3. Check Geolocation Use the map for approximate context, but do not treat it as exact physical attribution. ### 4. Review Open Ports Sort and filter services by port, product, scan date, or CVSS score. ### 5. Expand Important Services Open details for exposed web services, remote access services, databases, or unusual ports. ### 6. Review Vulnerability Data Check CVE count and Max CVSS, but validate product and version accuracy before making conclusions. ### 7. Inspect Raw JSON When Needed Use raw data for deeper technical analysis or integration workflows. ### 8. Compare Current and Historical Data Enable historical data when investigating exposure changes over time. ### 9. Export Evidence Use CSV or JSON export for internal reporting. ### 10. Validate Before Action Confirm important findings with additional tools, asset owners, or direct authorized scans. --- ## 🛡️ Security, Privacy & Responsible Use IP Intelligence Search is intended for lawful cybersecurity, OSINT, asset analysis, incident response, and exposure management. Acceptable use cases include: - Checking your own infrastructure - Investigating suspicious IPs - Reviewing exposed services - SOC triage - Threat intelligence enrichment - Vulnerability exposure review - Asset inventory validation - Incident response - Historical infrastructure analysis - Compliance reporting Users must follow responsible use rules: - Do not use the tool to attack systems. - Do not use exposed services for unauthorized access. - Do not exploit vulnerabilities discovered through the tool. - Do not harass, disrupt, or target third-party infrastructure. - Validate vulnerability findings before escalation. - Respect applicable laws and authorization boundaries. - Treat exported infrastructure data as sensitive. - Use results for defensive and analytical purposes only. --- ## ⚙️ Technical Highlights - Global IP intelligence search - Available at `dash.niamonx.io/global_iplookup` - Powered by NiamonX Crawler database catalog - Supports IPv4 and IPv6 - Rejects domains and URLs - Optional historical data - General IP profile - ASN, organization, ISP, country, city, and coordinates - Leaflet geolocation map - Hostnames and domains - Tags and labels - Services and ports table - TCP and UDP support - Product and version detection - HTTP metadata - SSL metadata when available - CPE and CPE 2.3 identifiers - Vulnerability aggregation - CVE counts - Max CVSS field - CVSS color labels - Port and product filtering - Column sorting - Service detail disclosure - Lazy rendering for large responses - Raw JSON viewer - Summary / JSON copy - CSV export - LocalStorage history of entered IPs - Suitable for SOC, OSINT, vulnerability review, asset monitoring, and incident response workflows --- ## 📌 Usage Hints - Enter only an IPv4 or IPv6 address. - Do not enter domains, URLs, paths, or IP:port values. - Use the service search field to filter by port or product name. - Check Max CVSS for quick vulnerability triage. - Expand service details for HTTP headers, banners, fingerprints, and raw JSON. - Use historical data when investigating changes over time. - Treat geolocation as approximate. - Treat CVE matches as leads until validated. - Use CSV export for service inventory. - Use JSON copy for technical workflows. - Clear local history on shared devices. - Use findings only for lawful defensive analysis. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX IP Intelligence Search (Global IP Lookup)** is a global IP intelligence tool for analyzing IPv4 and IPv6 addresses through the NiamonX Crawler database catalog. It provides ASN, organization, ISP, geolocation, hostnames, domains, open ports, services, products, HTTP metadata, fingerprints, CVEs, CVSS scores, historical layers, raw JSON, filtering, sorting, CSV export, and local lookup history. The tool is designed for lawful OSINT, SOC triage, threat intelligence, vulnerability review, asset monitoring, compliance, and incident response. Results should be treated as intelligence signals and validated before operational or security decisions. # IP Calculator | IPv4 Subnet, Converter & Network Toolkit [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/TqE85F1QQRo882IK-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/TqE85F1QQRo882IK-image.png) The platform available at **[https://dash.niamonx.io/ipcalc\_net](https://dash.niamonx.io/ipcalc_net)** — known as **IP Calculator** — is a universal IPv4 network toolkit within the NiamonX platform. It helps users calculate subnets, convert IPv4 values between different representations, derive subnet masks, check address ranges, calculate usable hosts, work with wildcard masks, and perform practical network planning tasks. ## Overview of the Service **IP Calculator** is designed for network engineers, system administrators, cybersecurity analysts, DevOps teams, students, and technical users who need a fast and reliable way to calculate IPv4 subnet information. The tool combines several network utilities in one interface: - Subnet Calculator - Base Converter - Mask Calculator - Network Tools - CIDR Aggregation - IP Membership Check It can calculate network address, broadcast address, subnet mask, wildcard mask, first host, last host, total addresses, usable hosts, IP class, private range status, decimal representation, binary representation, hexadecimal representation, and mask representations. All computations are performed server-side, and access is controlled through plan-based query limits. --- ## 🔍 How the Tool Works The user can either enter a full CIDR value or provide an IP address and prefix separately. Example CIDR input: ```text 10.0.0.1/24 ``` The tool parses the address, applies the prefix, and calculates the full subnet range. For example, for: ```text 10.0.0.1/24 ``` the tool returns: ```text Network: 10.0.0.0 Broadcast: 10.0.0.255 Mask: 255.255.255.0 First host: 10.0.0.1 Last host: 10.0.0.254 Total: 256 Usable: 254 ``` The interface also shows technical representations of both the IP address and subnet mask in decimal, binary, and hexadecimal formats. --- ## 🧩 Main Tool Modules IP Calculator includes several practical modules. ### Subnet Calculator Calculates subnet boundaries and host ranges from an IPv4 address and CIDR prefix. Useful for: - Network planning - IP range validation - Firewall rule preparation - Routing configuration - Infrastructure documentation - Lab exercises - Security segmentation ### Base Converter Converts IPv4 values between different formats. Supported conversion types may include: - IP address - Subnet mask - Prefix - Decimal - Binary - Hexadecimal ### Mask Calculator Calculates subnet mask and prefix information. It can also derive the minimal prefix required for a desired number of hosts. ### Network Tools Provides additional utilities for CIDR aggregation, range operations, and membership checks. ### CIDR Aggregation Helps combine compatible networks into a shorter aggregated CIDR block when possible. ### IP Membership Check Checks whether a specific IP address belongs to a selected subnet or range. --- ## ⚙️ Interface Structure The interface is divided into practical tabs and panels. Main sections:
SectionPurpose
Subnet CalculatorCalculate subnet range and host information
Base ConverterConvert IP values between decimal, binary, hex, and CIDR formats
Mask CalculatorCalculate prefix, mask, wildcard, and host capacity
Network ToolsWork with aggregation, ranges, and membership checks
Request HistoryReview recent local calculations
The interface also displays daily query limits based on the current plan. Example: ```text 59999 / 60000 Queries remaining / total Plan: Sentinel ``` --- ## 🧮 Subnet Calculator The **Subnet Calculator** is the main module for IPv4 subnet analysis. Users can provide input in two ways: ### CIDR Input Example: ```text 10.0.0.1/24 ``` ### IP + Prefix Input Example: ```text IP: 192.168.1.10 Prefix: /24 ``` Both input methods produce the same type of subnet output. --- ## 📊 Subnet Output Fields After calculation, the tool displays the subnet details.
FieldDescription
NetworkFirst address of the subnet
BroadcastBroadcast address of the subnet
MaskSubnet mask in dotted decimal format
PrefixCIDR prefix length
WildcardInverse subnet mask
First hostFirst usable host address
Last hostLast usable host address
TotalTotal number of addresses in the subnet
UsableNumber of usable host addresses
ClassIPv4 class
PrivateWhether the address belongs to a private range
Example result: ```text Network: 10.0.0.0 Broadcast: 10.0.0.255 Mask: 255.255.255.0 Prefix: 24 Wildcard: 0.0.0.255 First host: 10.0.0.1 Last host: 10.0.0.254 Total: 256 Usable: 254 Class: A Private: Yes ``` --- ## 🌐 Network Address The **Network** field shows the first address of the subnet. Example: ```text 10.0.0.0 ``` The network address identifies the subnet itself and is normally not assigned to a regular host. --- ## 📡 Broadcast Address The **Broadcast** field shows the last address of the subnet. Example: ```text 10.0.0.255 ``` In traditional IPv4 networking, the broadcast address is used to send packets to all hosts in the subnet. For most standard subnets, the broadcast address is not assigned to a normal host. --- ## 🎭 Subnet Mask The **Mask** field shows the subnet mask in dotted decimal notation. Example: ```text 255.255.255.0 ``` A subnet mask defines which part of the IP address belongs to the network and which part belongs to host addressing. --- ## 🧱 Prefix The **Prefix** field shows the CIDR prefix length. Example: ```text /24 ``` The prefix indicates how many bits are used for the network portion. Common prefixes:
PrefixMaskTypical Use
/8255.0.0.0Large private or enterprise blocks
/16255.255.0.0Medium-sized internal networks
/24255.255.255.0Common LAN subnet
/30255.255.255.252Point-to-point links
/31255.255.255.254Point-to-point links with special handling
/32255.255.255.255Single host route
--- ## 🃏 Wildcard Mask The **Wildcard** field shows the inverse of the subnet mask. Example: ```text 000000FF (0.0.0.255) ``` Wildcard masks are commonly used in: - ACL rules - Routing policies - Network matching - Firewall logic - Cisco-style configurations For a `/24` subnet, the mask is: ```text 255.255.255.0 ``` and the wildcard is: ```text 0.0.0.255 ``` --- ## 🖥️ First and Last Host The tool calculates the usable host range. Example for `/24`: ```text First host: 10.0.0.1 Last host: 10.0.0.254 ``` These are the first and last usable IP addresses in the subnet. For special prefixes such as `/31` and `/32`, usable host logic is handled as an edge case. --- ## 🔢 Total and Usable Addresses The **Total** field shows the total number of addresses in the subnet. The **Usable** field shows how many addresses can typically be assigned to hosts. Example: ```text Total: 256 Usable: 254 ``` For most IPv4 subnets, usable addresses exclude the network and broadcast addresses. Special cases: - `/31` is commonly used for point-to-point links. - `/32` represents a single host route. The tool accounts for usable host count in these edge cases. --- ## 🏷️ Class Detection The tool detects the traditional IPv4 class of the entered address. IPv4 class ranges:
ClassRangeNotes
A1.0.0.0 – 126.255.255.255Large networks
B128.0.0.0 – 191.255.255.255Medium networks
C192.0.0.0 – 223.255.255.255Smaller networks
D224.0.0.0 – 239.255.255.255Multicast
E240.0.0.0 – 255.255.255.255Reserved / experimental
Class detection is useful for educational and compatibility contexts, although modern networking primarily uses CIDR. --- ## 🔐 Private Range Check The **Private** field indicates whether the IP belongs to a private IPv4 range. Private IPv4 ranges:
RangeCIDR
10.0.0.0 – 10.255.255.25510.0.0.0/8
172.16.0.0 – 172.31.255.255172.16.0.0/12
192.168.0.0 – 192.168.255.255192.168.0.0/16
Example: ```text Private: Yes ``` Private addresses are normally used inside internal networks and are not directly routed on the public Internet. --- ## 🔄 Representations The **Representations** section shows the IP address and mask in multiple numeric bases. For the IP: ```text 10.0.0.1 ``` the tool may show: ```text IP (dec): 167772161 IP (bin): 00001010000000000000000000000001 IP (hex): 0A000001 ``` For the mask: ```text 255.255.255.0 ``` the tool may show: ```text Mask (dec): 4294967040 Mask (bin): 11111111111111111111111100000000 Mask (hex): FFFFFF00 ``` These representations are useful for: - Low-level networking - Binary subnetting exercises - Debugging address calculations - Protocol analysis - Security tooling - Developer workflows --- ## 🔢 Base Converter The **Base Converter** supports conversion between IP-related formats. Supported values may include: - IPv4 dotted decimal - Decimal integer - Binary - Hexadecimal - Prefix - Mask - Wildcard Example decimal value: ```text 4294967295 ``` Example binary value: ```text 11111111111111111111111111111111 ``` Example hexadecimal value: ```text FFFFFFFF ``` The converter helps users move between human-readable IP formats and machine-level representations. --- ## 🎯 Mask Calculator The **Mask Calculator** can derive subnet information from a prefix or from required host capacity. Example prefix input: ```text prefix = 24 ``` Expected output: ```text /24 255.255.255.0 ``` The mask calculator can also derive the minimal prefix for a required number of hosts. Example use case: ```text Required hosts: 200 ``` The tool calculates the smallest subnet that can contain the requested number of usable addresses. This is useful for: - VLAN planning - Office network planning - Cloud subnet sizing - Lab design - Address allocation - Avoiding wasted IP space --- ## 🧩 CIDR Aggregation CIDR aggregation helps combine adjacent networks into a shorter summary route when possible. Example use cases: - Route summarization - Firewall rule simplification - ACL optimization - Cloud network planning - Reducing routing table entries - Grouping related subnets Aggregation should be used carefully because an overly broad summary may include addresses that should not be covered by a rule. --- ## ✅ IP Membership Check The membership check helps determine whether an IP belongs to a given subnet. Example question: ```text Does 192.168.1.50 belong to 192.168.1.0/24? ``` Expected result: ```text Yes ``` This is useful for: - Firewall troubleshooting - VPN routing checks - Access control validation - Network segmentation review - Incident response - Log analysis --- ## 🕓 Request History The tool stores recent calculations locally in the user’s browser. Example behavior: ```text We store the last 200 queries locally in your browser. ``` History entries may include: - Tool mode - Input value - Calculated range - Timestamp - Conversion type - Result summary Example history item: ```text subnet 10.0.0.1/24 10.0.0.0..10.0.0.255 17.06.2026, 21:53:23 ``` Request history is useful for repeating calculations, reviewing previous subnet work, and documenting network planning sessions. Because history is stored locally in the browser, it may be cleared by deleting browser data or using another device. --- ## 🚦 Query Limits and Plan Access IP Calculator uses plan-based query limits. Example: ```text 59999 / 60000 Queries remaining / total Plan: Sentinel ``` Important points: - Computations are performed server-side. - Plan limits are enforced. - Remaining query count is displayed in the interface. - Local history does not replace server-side usage limits. --- ## 🧠 Key Features ### Universal IPv4 Toolkit Combines subnet calculation, conversion, mask calculation, and network utilities. ### CIDR Support Accepts CIDR notation such as: ```text 192.168.1.10/24 ``` ### IP + Prefix Input Users can enter IP and prefix separately. ### Subnet Range Calculation Returns network, broadcast, first host, last host, total addresses, and usable addresses. ### Wildcard Mask Calculates wildcard mask in hexadecimal and dotted decimal formats. ### Base Conversion Converts IP and mask values to decimal, binary, and hexadecimal. ### Class Detection Detects traditional IPv4 class. ### Private Range Detection Checks whether an IP belongs to RFC1918-style private address ranges. ### Edge Case Handling Handles usable host calculations for `/31` and `/32`. ### Mask Calculator Derives prefix and mask values, including host-based sizing. ### CIDR Aggregation Supports network summarization workflows. ### Membership Check Checks whether an IP belongs to a specific subnet. ### Local Request History Stores up to 200 recent calculations in the browser. --- ## 📌 Practical Examples ### Example 1: Standard LAN Subnet Input: ```text 192.168.1.10/24 ``` Result: ```text Network: 192.168.1.0 Broadcast: 192.168.1.255 Mask: 255.255.255.0 Usable hosts: 254 Private: Yes ``` Use case: - Office LAN - Home network - Small VLAN --- ### Example 2: Larger Private Subnet Input: ```text 192.168.1.10/20 ``` Result: ```text Network: 192.168.0.0 Broadcast: 192.168.15.255 ``` Use case: - Larger internal segment - Lab environment - Department-level subnet --- ### Example 3: Decimal Conversion Input: ```text 4294967295 ``` Possible output: ```text IP: 255.255.255.255 Binary: 11111111111111111111111111111111 Hex: FFFFFFFF ``` Use case: - Low-level networking - Binary conversion - Developer debugging --- ### Example 4: Prefix to Mask Input: ```text prefix: 24 ``` Output: ```text /24 255.255.255.0 Wildcard: 0.0.0.255 ``` Use case: - Firewall rules - Router configuration - Documentation --- ## ✅ Recommended Workflow A practical workflow depends on the user’s goal. ### For Subnet Planning 1. Enter CIDR notation or IP + prefix. 2. Review network and broadcast address. 3. Check usable host count. 4. Confirm private/public status. 5. Copy mask and wildcard values for configuration. ### For Firewall Rules 1. Calculate subnet and wildcard mask. 2. Validate range boundaries. 3. Check membership for test IPs. 4. Avoid overly broad CIDR blocks. ### For Cloud Networking 1. Calculate required host capacity. 2. Use Mask Calculator to derive minimal prefix. 3. Reserve space for growth. 4. Validate non-overlap with existing networks. ### For Troubleshooting 1. Convert IPs to binary or decimal. 2. Compare masks. 3. Check IP membership. 4. Confirm network boundaries. --- ## 🛡️ Security and Responsible Use IP Calculator is a technical utility intended for legitimate network planning, education, administration, and cybersecurity workflows. Acceptable use cases include: - Subnet planning - VLAN design - Firewall configuration - Routing documentation - Cloud network sizing - VPN troubleshooting - Incident response - Log analysis - Security lab exercises - Network education Users should apply results carefully: - Validate configurations before deploying them. - Avoid overly broad firewall rules. - Confirm CIDR ranges before adding routes. - Check overlap between networks. - Use membership checks before changing access controls. - Document subnet decisions clearly. - Treat local history as potentially sensitive on shared devices. --- ## ⚙️ Technical Highlights - Universal IPv4 network toolkit - Available at `dash.niamonx.io/ipcalc_net` - Subnet Calculator - Base Converter - Mask Calculator - Network Tools - CIDR input support - IP + Prefix input support - Network address calculation - Broadcast address calculation - Subnet mask calculation - Wildcard mask calculation - First and last host calculation - Total and usable address count - IPv4 class detection - Private range check - Decimal representation - Binary representation - Hexadecimal representation - Mask conversion - Prefix conversion - Wildcard conversion - CIDR aggregation - IP membership check - Edge handling for `/31` and `/32` - Server-side computation - Plan-based query limits - Local browser history - Stores last 200 queries locally - Suitable for network engineering, DevOps, SOC, education, and infrastructure planning --- ## 📌 Usage Hints - Use either CIDR or IP + Prefix in the Subnet tab. - Converter supports IP, mask, prefix, decimal, binary, and hex. - Mask Calculator can derive the minimal prefix for required hosts. - Use wildcard masks for ACL and firewall logic. - Check private/public status before routing decisions. - Use membership checks before changing firewall rules. - Be careful with aggregation because it may include extra addresses. - Recheck `/31` and `/32` behavior when working with point-to-point or host routes. - Store exported or copied calculations carefully if they describe internal infrastructure. - Clear local history on shared devices. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX IP Calculator** is a universal IPv4 subnet and conversion toolkit for calculating network ranges, broadcast addresses, subnet masks, wildcard masks, usable hosts, decimal / binary / hexadecimal representations, CIDR aggregation, and IP membership. It is designed for network planning, routing, firewall configuration, cloud infrastructure, SOC workflows, DevOps, education, and troubleshooting. The tool performs calculations server-side, enforces plan-based limits, and stores the last 200 queries locally in the browser for convenience. # IP / Domain Explorer | IP and Domain Geolocation & Network Intelligence [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/7phTj7Rq0a904rUE-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/7phTj7Rq0a904rUE-image.png) The platform available at **[https://dash.niamonx.io/ipexplorer](https://dash.niamonx.io/ipexplorer)** — known as **IP / Domain Explorer** — is a lightweight IP and domain intelligence tool within the NiamonX platform. It allows users to check geographic, network, ASN, ISP, reverse DNS, and infrastructure attributes for an IPv4 address, IPv6 address, or domain name. ## Overview of the Service **IP / Domain Explorer** is designed to quickly identify where an IP address or domain is located from a network intelligence perspective and which organization, ISP, Autonomous System, and infrastructure attributes are associated with it. The tool combines internal NiamonX systems with public databases to provide a structured overview of IP or domain metadata. It is useful for cybersecurity analysts, SOC teams, system administrators, fraud investigators, OSINT researchers, compliance teams, and technical users who need a fast way to understand the basic network profile of an address or domain. The module supports: - IPv4 addresses - IPv6 addresses - Domains - Internationalized domain names entered in Unicode The result includes location, coordinates, timezone, currency, network ownership, ASN, reverse DNS, and classification flags such as proxy, hosting, or mobile network. --- ## 🔍 How the Tool Works When a user enters an IP address or domain name, IP / Domain Explorer performs a lookup through internal systems and public intelligence databases. For domain input, the tool resolves or analyzes the domain and returns the available network and geolocation information. For IP input, the tool directly checks the IP address against available IP intelligence sources. The returned result is displayed as a structured report containing: - Location - Coordinates - Network owner - ISP - Organization - Autonomous System - Reverse DNS - Hosting / proxy / mobile flags - Timezone - Currency - HTTP status - Source information The result is intended to provide quick situational awareness, not a final legal or attribution conclusion. --- ## 🧩 What Can Be Searched IP / Domain Explorer accepts the following input types. ### IPv4 Address Example: ```text 1.1.1.1 ``` ### IPv6 Address Example: ```text 2606:4700:4700::1111 ``` ### Domain Name Example: ```text example.com ``` ### Internationalized Domain Name Domains with Unicode characters are supported when accepted by the backend. Example: ```text пример.рф ``` The tool should not be used with full URLs, URL paths, or unrelated search operators. Invalid examples: ```text https://example.com/login ``` ```text example.com/path/page.html ``` ```text 1.1.1.1:443 ``` For best results, users should enter only a clean IP address or domain name. --- ## ⚙️ Search Interface The main interface contains a simple input field. ### IP Address or Domain The user enters an IPv4 address, IPv6 address, or domain. Example: ```text 1.1.1.1 ``` The interface indicates that IPv4, IPv6, and domains are supported, including IDN domains entered in Unicode. After submission, the tool returns a structured result panel. --- ## 📊 Result Overview A successful lookup displays a short summary at the top of the result. Example structure: ```text Successfully: 1.1.1.1 Location: Australia, Queensland, South Brisbane Coordinates: -27.476600, 153.016600 Network: Cloudflare, Inc / APNIC and Cloudflare DNS Resolver project AS: AS13335 Cloudflare, Inc. - CLOUDFLARENET Flags: Hosting ``` This summary gives the user a quick understanding of: - Whether the lookup succeeded - Where the IP is geographically mapped - Which organization or ISP operates it - Which AS network it belongs to - Whether it is marked as hosting, proxy, or mobile infrastructure --- ## 🌍 Location Information The tool returns geographic fields associated with the IP or resolved domain. Possible location fields include:
FieldDescription
ContinentContinent name
Continent codeShort continent code
CountryCountry name
Country codeISO country code
Region codeShort region or state code
Region nameFull region or state name
CityCity associated with the IP
DistrictDistrict or area, if available
Postal codePostal or ZIP code, if available
LatitudeApproximate latitude
LongitudeApproximate longitude
Example: ```text Continent: Oceania Country: Australia Region: Queensland City: South Brisbane Latitude: -27.476600 Longitude: 153.016600 ``` Geolocation data should be treated as approximate. It may represent a network registration location, provider infrastructure, routing endpoint, cloud region, or database estimate rather than the exact physical location of a device or user. --- ## 🗺️ Coordinates and Map When latitude and longitude are available, the result can show a map link or map view. Coordinates are useful for: - Approximate location review - Network region analysis - Fraud investigation context - Infrastructure mapping - SOC triage - OSINT enrichment - Regional routing analysis Important interpretation: - IP coordinates are not GPS coordinates of a person. - Cloud and CDN IPs often map to provider infrastructure. - VPN, proxy, and hosting IPs may not represent the real user location. - Geolocation accuracy varies by provider and region. Coordinates should be used as context, not as proof of physical presence. --- ## 🏢 Network and Organization The tool displays network ownership and provider details. Possible fields include:
FieldDescription
ISPInternet Service Provider
OrganizationOrganization associated with the IP
ASAutonomous System Number and organization
AS NameAutonomous System name
NetworkCombined provider and organization information
Example: ```text ISP: Cloudflare, Inc Organization: APNIC and Cloudflare DNS Resolver project AS: AS13335 Cloudflare, Inc. AS Name: CLOUDFLARENET ``` This information is useful for identifying whether an address belongs to a hosting provider, corporate network, residential ISP, CDN, DNS resolver, mobile operator, cloud platform, or other infrastructure type. --- ## 🔢 ASN Information The **AS** field identifies the Autonomous System associated with the IP. An Autonomous System is a network or group of networks operated under a single routing policy. Example: ```text AS13335 Cloudflare, Inc. ``` ASN information is useful for: - Network attribution - Routing analysis - Threat intelligence enrichment - Provider identification - Abuse reporting - Firewall and allowlist decisions - Infrastructure mapping ASN ownership should not be confused with end-user identity. Many users, services, and customers can share infrastructure under the same ASN. --- ## 🔁 Reverse DNS The **Reverse DNS** field shows the PTR hostname associated with the IP address when available. Example: ```text one.one.one.one ``` Reverse DNS is useful for: - Identifying service naming - Confirming provider ownership - Enriching logs - Detecting mail infrastructure - Reviewing hosting patterns - Investigating suspicious IPs Reverse DNS is not always present, and when present, it may be outdated, generic, or controlled by the network operator. --- ## 🏷️ Flags and Attributes IP / Domain Explorer can display infrastructure attributes. Common flags include:
FlagMeaning
Mobile NetworkIndicates whether the IP appears to belong to a mobile network
ProxyIndicates whether the IP may be associated with proxy infrastructure
HostingIndicates whether the IP appears to belong to hosting, cloud, CDN, or data center infrastructure
Example: ```text Mobile Network: false Proxy: false Hosting: true ``` These attributes help users quickly understand the type of infrastructure behind an IP. Important: flags are based on available intelligence and heuristics. They should be used as indicators, not absolute proof. --- ## 🕒 Time Zone and UTC Offset The tool returns timezone information based on the geolocation result. Possible fields: - Time zone - UTC offset Example: ```text Time zone: Australia/Brisbane Offset: UTC+10 ``` Timezone information is useful for: - Event correlation - Log analysis - Regional context - Fraud review - Incident timeline construction - Travel or access pattern analysis Because IP geolocation may be approximate, timezone data should also be treated as contextual. --- ## 💱 Currency The result may include the local currency for the detected country. Example: ```text Currency: AUD ``` Currency is useful for enrichment and regional context, especially in fraud analysis, compliance workflows, and user-location review. --- ## 🌐 HTTP Code and Source The result can include request-level metadata such as HTTP code and data source. Example: ```text HTTP Code: 200 Source: niamonx.io ``` The HTTP code indicates whether the lookup request succeeded at the service level. The source field identifies the platform or internal lookup provider used for the result display. --- ## 🧠 Key Features ### IP and Domain Lookup Supports IPv4, IPv6, and domain names. ### IDN Support Internationalized domain names can be entered in Unicode when supported. ### Geolocation Returns continent, country, region, city, postal code, latitude, and longitude. ### Map Link Coordinates can be used for map-based location review. ### Network Ownership Shows ISP, organization, ASN, and AS name. ### Reverse DNS Returns PTR hostname when available. ### Infrastructure Flags Displays proxy, hosting, and mobile network indicators. ### Timezone and Currency Adds regional context for investigations and analysis. ### Local Request History The interface includes request history for previous lookups. ### Regularly Updated Data Data is updated regularly through internal systems and public databases. --- ## 🧾 Results Table The detailed results table provides field-by-field explanations. Typical fields include:
FieldMeaning
ContinentGeographic continent
Continent codeShort continent identifier
CountryCountry name
Country codeISO country code
Region codeState or region abbreviation
Region nameFull state or region
CityCity name
DistrictDistrict, if available
Postal codePostal code, if available
LatitudeApproximate latitude
LongitudeApproximate longitude
Time zoneTimezone name
Offset UTCUTC offset
CurrencyLocal currency
ISPInternet service provider
OrganizationOwning or related organization
ASAutonomous System
AS NameAS network name
Reverse DNSPTR hostname
Mobile NetworkMobile network indicator
ProxyProxy indicator
HostingHosting / cloud / data center indicator
RequestedOriginal query
HTTP CodeLookup response code
SourceData source identifier
The table is useful for copying values into reports, incident notes, or enrichment workflows. --- ## 🔍 Common Use Cases IP / Domain Explorer can support many legitimate workflows. ### SOC Triage Quickly enrich suspicious IPs from alerts, logs, SIEM events, or EDR telemetry. ### Threat Intelligence Identify ASN, organization, and hosting flags for IPs connected to suspicious infrastructure. ### Fraud Analysis Check whether a user IP appears to be a proxy, hosting provider, or mobile network. ### Access Review Compare login IP geolocation with expected user location. ### Infrastructure Audit Check how owned domains or IPs appear in public geolocation and network databases. ### Abuse Reporting Identify the responsible ISP or ASN before submitting abuse reports. ### OSINT Investigation Enrich IPs and domains during lawful public-source investigations. ### Compliance and Risk Review Document regional and infrastructure attributes of network indicators. --- ## 🧠 Result Interpretation IP and domain intelligence should be interpreted carefully. Important notes: - IP geolocation is approximate. - Hosting and proxy flags are indicators, not proof. - Reverse DNS may be missing or outdated. - Domains may resolve to CDN or cloud infrastructure. - CDN IPs may represent provider edge locations, not the real origin server. - Mobile and proxy classifications may vary by data source. - ASN identifies network ownership, not necessarily the person or organization using the service. - A domain may use different IPs over time. - Results should be correlated with logs, DNS records, threat intelligence, and internal context. The tool is best used as an enrichment layer, not as a single source of truth. --- ## ✅ Recommended Analyst Workflow A practical workflow should follow these steps. ### 1. Enter the IP or Domain Use a clean IPv4 address, IPv6 address, or domain name. ### 2. Review Location Check country, region, city, coordinates, timezone, and map. ### 3. Review Network Ownership Check ISP, organization, ASN, and AS name. ### 4. Check Flags Look for hosting, proxy, or mobile network indicators. ### 5. Review Reverse DNS Use PTR data to understand service naming or provider context. ### 6. Compare With Logs Correlate the lookup result with timestamps, user activity, SIEM events, or application logs. ### 7. Avoid Overclaiming Do not treat geolocation as exact physical attribution. ### 8. Document Findings Use the field table in reports or case notes when appropriate. ### 9. Repeat if DNS Changes For domains, repeat the lookup if DNS records may have changed. ### 10. Validate Critical Conclusions Use additional sources before making security, compliance, or legal decisions. --- ## 🛡️ Security, Privacy & Responsible Use IP / Domain Explorer is intended for lawful network intelligence, cybersecurity, troubleshooting, and OSINT enrichment. Acceptable use cases include: - Checking your own IP or domain - Enriching security logs - Investigating suspicious IPs - Reviewing infrastructure ownership - Fraud and abuse analysis - Network troubleshooting - SOC triage - Threat intelligence enrichment - Compliance reporting - Domain and DNS investigation Users should follow responsible use rules: - Do not use geolocation data for stalking, harassment, or physical targeting. - Do not claim exact personal location from IP geolocation. - Do not use proxy or hosting flags as final proof of wrongdoing. - Do not harass network owners or abuse contacts based on weak indicators. - Validate important findings with additional evidence. - Treat local lookup history as potentially sensitive on shared devices. - Use the tool only for lawful and ethical analysis. --- ## ⚙️ Technical Highlights - IP and domain intelligence lookup - Available at `dash.niamonx.io/ipexplorer` - Supports IPv4 - Supports IPv6 - Supports domains - Supports IDN domains in Unicode - Uses internal systems and public databases - Returns continent, country, region, city, district, and postal code - Provides latitude and longitude - Map link for coordinates - Timezone and UTC offset - Currency enrichment - ISP and organization - Autonomous System Number - AS name - Reverse DNS - Proxy indicator - Hosting indicator - Mobile network indicator - HTTP response code - Source field - Request history - Regularly updated data - Suitable for SOC, OSINT, fraud analysis, network troubleshooting, and infrastructure review --- ## 📌 Usage Hints - Enter only an IP address or domain name. - Do not enter full URLs or paths. - Use IPv4 or IPv6 for direct IP lookup. - Use domain lookup when you need resolved network context. - Treat geolocation as approximate. - Check ASN and organization for network ownership. - Use hosting and proxy flags as indicators, not final proof. - Review reverse DNS for additional context. - For CDN-backed domains, remember that the IP may belong to the CDN, not the origin server. - Correlate results with logs and other intelligence sources. - Use the tool responsibly; data is updated regularly. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX IP / Domain Explorer** is a fast IP and domain intelligence tool for checking geolocation, ASN, ISP, organization, reverse DNS, proxy status, hosting status, mobile network status, timezone, currency, and related network metadata. It supports IPv4, IPv6, standard domains, and Unicode IDN domains. The tool is designed for SOC triage, OSINT enrichment, fraud analysis, infrastructure review, network troubleshooting, and compliance workflows. Results should be interpreted as contextual intelligence and validated with additional sources when used for important decisions. # GlobeLine Ping | High-Level IP Availability & RTT Check [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/YDg6IMAFhElZLFW0-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/YDg6IMAFhElZLFW0-image.png) The platform available at **[https://dash.niamonx.io/gl\_ping](https://dash.niamonx.io/gl_ping)** — known as **GlobeLine Ping** — is a high-level network availability and latency diagnostic tool within the NiamonX platform. It allows users to check whether an IPv4 or IPv6 address is reachable and measure connection quality through network echo requests. ## Overview of the Service **GlobeLine Ping** is designed to provide a fast and clear health check for an IP address. The tool sends several network echo requests to the selected IP and calculates key network quality metrics, including availability, packet loss, minimum latency, average latency, maximum latency, jitter, and individual RTT values. The tool is useful for system administrators, SOC analysts, DevOps engineers, network engineers, infrastructure owners, cybersecurity teams, and technical users who need to quickly verify whether a host is online and how stable the connection is from the checking location. GlobeLine Ping is a high-level diagnostic utility. It does not perform port scanning, service enumeration, exploitation, or deep packet inspection. It only checks reachability and latency characteristics for the submitted IP address. --- ## 🔍 How the Tool Works When a user enters an IPv4 or IPv6 address, GlobeLine Ping sends several network echo requests from the NiamonX checking infrastructure. The tool then calculates and displays: - Availability status - Number of packets sent - Number of packets received - Packet loss percentage - Minimum RTT - Average RTT - Maximum RTT - Jitter - Individual RTT values - Difference from average latency - RTT quality category - Source location of the check, when available Example result summary: ```text ONLINE 1.59 ms Packets: 3/3 Losses: 0% MIN RTT: 1.291 ms AVG RTT: 1.588 ms MAX RTT: 1.795 ms JITTER: 0.264 ms Source Location: Santa Clara, US ``` This gives the user a quick understanding of whether the IP is reachable and whether the connection appears stable. --- ## 🧩 What Can Be Checked GlobeLine Ping supports direct IP address checks. Supported input types: - IPv4 address - IPv6 address Examples: ```text 1.1.1.1 ``` ```text 8.8.8.8 ``` ```text 2606:4700:4700::1111 ``` Unsupported input types: ```text example.com ``` ```text https://example.com ``` ```text 1.1.1.1:443 ``` ```text example.com/path ``` The tool expects only a clean IPv4 or IPv6 address. Domains and URLs are not accepted in this module. --- ## ⚙️ Search Interface The interface contains a simple IP input field. ### IP Address The user enters the target IP address. Example: ```text 1.1.1.1 ``` The interface states that IPv4 and IPv6 are supported and that the user should enter only the IP address, without domains or URLs. After the check is completed, GlobeLine Ping displays the result status, summary metrics, packet statistics, RTT table, and source location. --- ## 📊 Result Overview The main result panel gives a fast status summary. Possible status values:
StatusMeaning
ONLINEThe IP responded to the network echo requests
OFFLINEThe IP did not respond or could not be reached
UNKNOWNThe result could not be confidently determined
Example: ```text ONLINE 1.59 ms ``` The large latency value shown next to the status usually represents the average RTT or primary response time. --- ## 📦 Packet Statistics The tool displays packet delivery statistics. Example: ```text Packages received/sent: 3/3 Losses: 0% ``` ### Received / Sent Shows how many echo responses were received compared to how many requests were sent. Example: ```text 3/3 ``` This means all three requests received responses. ### Packet Loss Packet loss shows the percentage of requests that did not receive a response. Example: ```text 0% ``` Packet loss is one of the most important indicators of connection reliability. --- ## ⏱️ RTT Metrics RTT means **Round-Trip Time**. It measures how long it takes for a request to reach the target and for the response to return. GlobeLine Ping calculates several RTT values. ### Minimum RTT The fastest response time observed during the check. Example: ```text MIN RTT: 1.291 ms ``` ### Average RTT The average response time across all received packets. Example: ```text AVG RTT: 1.588 ms ``` ### Maximum RTT The slowest response time observed during the check. Example: ```text MAX RTT: 1.795 ms ``` Together, these values help users understand the connection’s speed and stability. --- ## 📉 Jitter Jitter measures variation between response times. Example: ```text JITTER: 0.264 ms ``` Low jitter means responses are consistent. High jitter means latency is unstable, which may indicate: - Network congestion - Routing instability - Wireless interference - Provider-level issues - Intercontinental routing - Packet scheduling delays - Saturated links - Temporary infrastructure problems Jitter is especially important for real-time services such as VoIP, video calls, gaming, remote desktops, and streaming. --- ## 🌍 Source Location The result may include the source location of the check. Example: ```text Source Location: Santa Clara, US ``` This tells the user where the ping check was performed from. Source location matters because latency depends strongly on distance and routing. A target may respond quickly from one region and slowly from another. For example: - A US server may respond quickly from a US checking node. - The same server may show higher latency from Europe or Asia. - CDN and anycast services may route users to different nearby nodes. --- ## 📊 Individual RTT Table GlobeLine Ping displays individual packet measurements. Example table:
\#RTT msΔ from AVGCategory
11.795+0.207MID
21.291-0.298OK
31.679+0.091OK
### RTT The measured round-trip time for each individual request. ### Δ from AVG Shows how far the individual RTT differs from the average RTT. Positive values mean the packet was slower than average. Negative values mean the packet was faster than average. ### Category A simple quality label for the individual response. Possible labels may include: - OK - MID - SLOW - LOST - ERROR The exact label depends on the tool’s internal classification logic. --- ## 📶 Packet Loss Bar The packet loss bar visualizes the percentage of lost packets. Example: ```text Packet Loss: 0% ``` Interpretation:
Packet LossMeaning
0%Excellent packet delivery
1–2%Minor loss, usually acceptable but worth watching
3–5%Noticeable instability
5–10%Significant network quality issue
10%+Serious connectivity problem
Even small packet loss can affect real-time applications. --- ## 🧠 Latency Interpretation RTT values depend on distance, routing, network congestion, and target infrastructure. General interpretation:
Average RTTInterpretation
0–20 msVery low latency
20–60 msGood latency
60–120 msModerate latency
120–250 msHigh but often normal for long-distance routing
250–300+ msVery high latency, often intercontinental or problematic
Timeout / no responseHost may be offline, filtered, or blocking echo requests
RTT values above 250–300 ms often indicate intercontinental routing, unstable paths, overloaded networks, or problematic channels. Important: a high RTT does not always mean the target is broken. It may simply be far away or routed through a distant network path. --- ## 🧠 Key Features ### IP Availability Check The tool determines whether an IP address appears reachable. ### IPv4 and IPv6 Support Both modern IPv4 and IPv6 targets are supported. ### High-Level Ping The tool performs several echo requests and calculates summary statistics. ### RTT Measurement Minimum, average, and maximum round-trip time are displayed. ### Packet Loss Calculation The tool shows packet delivery success and loss percentage. ### Jitter Calculation Latency variation is calculated to help evaluate connection stability. ### Individual Packet Details Each request is listed with RTT, difference from average, and quality category. ### Source Location The origin location of the check is shown when available. ### Local Request History Search history is stored locally in the browser through LocalStorage. ### Lightweight Diagnostic Design The tool is simple, fast, and focused on availability and latency rather than deep service analysis. --- ## 🕓 Request History GlobeLine Ping stores request history locally in the user’s browser. Important behavior: ```text The history is stored locally in your browser and is not sent to the server. ``` History may include: - Checked IP address - Result status - Average RTT - Packet loss - Timestamp - Source location, when available Because history is local, it may be cleared if the user clears browser data, switches devices, or uses another browser profile. On shared devices, users should clear browser history or LocalStorage when ping targets are sensitive. --- ## ✅ Recommended Diagnostic Workflow A practical troubleshooting workflow should follow these steps. ### 1. Enter the IP Address Use only IPv4 or IPv6. Do not enter a domain, URL, port, or path. ### 2. Check Availability Look at the main status: ONLINE or OFFLINE. ### 3. Review Packet Loss If packet loss is above 0%, repeat the test and compare results. ### 4. Review RTT Values Check minimum, average, and maximum RTT. ### 5. Review Jitter High jitter may indicate unstable routing or network congestion. ### 6. Check Individual Packets Look for spikes, inconsistent values, or lost responses. ### 7. Consider Source Location Compare the source region with the target’s expected location. ### 8. Repeat From Other Tools if Needed If the result is critical, verify from another network or monitoring system. ### 9. Correlate With Other Signals Use logs, traceroute, service checks, uptime monitoring, firewall rules, and provider status pages to confirm the issue. ### 10. Document the Result Use the metrics in incident notes or troubleshooting reports. --- ## 🔎 Common Use Cases GlobeLine Ping can support many technical workflows. ### Server Availability Check Quickly confirm whether a server IP responds. ### Network Troubleshooting Check whether latency or packet loss is affecting connectivity. ### Incident Response Verify if an IP is reachable during outage investigation. ### Route Quality Review Use RTT and jitter as a first indicator of network path quality. ### Infrastructure Monitoring Perform quick spot checks on public infrastructure. ### CDN and Anycast Testing Compare response behavior from the tool’s source location. ### Firewall Validation Determine whether ICMP-style echo requests are allowed or blocked. ### ISP or Hosting Issue Review Use packet loss and RTT data as basic evidence for support tickets. --- ## ⚠️ Result Interpretation Notes Ping results should be interpreted carefully. Important limitations: - Some hosts block ICMP or echo requests. - OFFLINE does not always mean the service is down. - A web server may be online even if ping is blocked. - Firewalls may drop echo requests. - Packet loss can be temporary. - RTT depends on distance and routing. - Source location affects latency. - Anycast IPs may route to different nodes from different regions. - A small sample size gives a quick check, not long-term monitoring. For critical systems, use additional checks such as TCP connection tests, HTTP status checks, traceroute, DNS checks, and continuous monitoring. --- ## 🛡️ Security, Privacy & Responsible Use GlobeLine Ping is intended for lawful network diagnostics and infrastructure monitoring. Acceptable use cases include: - Checking your own servers - Testing authorized infrastructure - Verifying network reachability - Diagnosing latency and packet loss - Supporting incident response - Troubleshooting routing issues - Monitoring public service availability - Creating basic network reports Users should follow responsible use principles: - Do not use the tool to harass or overload third-party systems. - Do not repeatedly test targets without a legitimate reason. - Do not treat ping failure as proof of compromise or outage. - Do not use results as the only source for critical operational decisions. - Respect applicable laws and network policies. - Treat local history as potentially sensitive on shared devices. --- ## ⚙️ Technical Highlights - High-level IP ping tool - Available at `dash.niamonx.io/gl_ping` - Supports IPv4 - Supports IPv6 - IP-only input - No domains or URLs accepted - Availability status: ONLINE / OFFLINE - Multiple echo requests per check - Packets received / sent - Packet loss percentage - Minimum RTT - Average RTT - Maximum RTT - Jitter calculation - Individual RTT table - Delta from average RTT - Quality category per packet - Packet loss visualization - Source location display when available - Local browser history through LocalStorage - History is not sent to the server - Suitable for network diagnostics, infrastructure checks, SOC workflows, DevOps, and troubleshooting --- ## 📌 Usage Hints - Enter only an IPv4 or IPv6 address. - Do not enter domains, URLs, ports, or paths. - ONLINE means the IP responded to the echo requests. - OFFLINE may also mean ICMP is blocked. - Check packet loss before judging connection quality. - Compare MIN, AVG, and MAX RTT for latency stability. - Use jitter to identify unstable connections. - RTT above 250–300 ms usually indicates high-latency routing. - Repeat the check if results are inconsistent. - Consider the source location when interpreting latency. - Use other diagnostics for critical systems. - Local history stays in the browser and is not sent to the server. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX GlobeLine Ping** is a high-level IP availability and latency diagnostic tool for IPv4 and IPv6 addresses. It sends several network echo requests, determines whether the target is online, and calculates packet loss, minimum RTT, average RTT, maximum RTT, jitter, individual response times, and source location. The tool is designed for lawful network diagnostics, infrastructure monitoring, DevOps workflows, SOC triage, and incident response. Results should be interpreted as quick network health indicators and confirmed with additional diagnostics when used for critical decisions. # GeoPing | Multi-Location IP Availability & Latency Check [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/o0BWVrEsIThZ1oPN-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/o0BWVrEsIThZ1oPN-image.png) The platform available at **[https://dash.niamonx.io/geoping](https://dash.niamonx.io/geoping)** — known as **GeoPing** — is a multi-location network diagnostic tool within the NiamonX platform. It allows users to check IPv4 and IPv6 availability from several geographic locations at the same time and compare latency, packet loss, jitter, and route quality by region. ## Overview of the Service **GeoPing** is designed to help users understand how reachable and responsive an IP address is from different parts of the world. Unlike a single-location ping test, GeoPing performs parallel checks from multiple geographic nodes and aggregates the results into a structured report. This makes it useful for identifying regional connectivity differences, routing problems, CDN behavior, network instability, and global availability issues. The tool is intended for network engineers, DevOps teams, SOC analysts, system administrators, infrastructure owners, hosting providers, cybersecurity teams, and technical users who need to evaluate IP-level connectivity from several locations. GeoPing supports: - IPv4 addresses - IPv6 addresses - Multi-location availability checks - Regional RTT comparison - Packet loss analysis - Jitter measurement - Best / worst location detection - Median and average latency metrics - Local browser-based request history The tool accepts only IP addresses. Domains, URLs, ports, and paths are not supported in this module. --- ## 🔍 How the Tool Works When a user enters an IPv4 or IPv6 address, GeoPing launches parallel availability checks from several geographic locations. Each location sends multiple network echo requests to the target IP. The tool then calculates per-location metrics and global aggregated statistics. The result includes: - Overall number of test locations - Number of online locations - Number of offline locations - Average RTT across locations - Median average RTT - Global minimum RTT - Global maximum RTT - Average packet loss - Best location by average RTT - Worst location by average RTT - Per-location availability status - Per-location minimum, average, and maximum RTT - Per-location jitter - Packets received / sent - Packet loss percentage - Individual RTT values Example summary: ```text Total: 5 ONLINE: 5 OFFLINE: 0 Host: 1.1.1.1 Locations: 5 AVG: 1.716 ms Median AVG: 1.580 ms Global MIN: 0.982 ms Global MAX: 3.134 ms Average Loss: 0.00% Best: Singapore, SG Worst: London, GB ``` This allows users to quickly understand whether the IP is globally reachable and whether any region has unusual latency or packet loss. --- ## 🧩 What Can Be Checked GeoPing supports direct IP address checks. Supported input types: - IPv4 address - IPv6 address Valid examples: ```text 1.1.1.1 ``` ```text 8.8.8.8 ``` ```text 2606:4700:4700::1111 ``` Unsupported input examples: ```text example.com ``` ```text https://example.com ``` ```text 1.1.1.1:443 ``` ```text example.com/path ``` GeoPing expects only a clean IPv4 or IPv6 address. --- ## ⚙️ Check Interface The GeoPing interface contains a simple input field and result sections. ### IP Address The user enters the target IP address. Example: ```text 1.1.1.1 ``` The interface indicates that IPv4 and IPv6 are supported and that only an IP address should be entered. After the request is processed, the tool displays: - Summary block - Per-location result cards - Individual RTT lists - Packet loss values - Request history --- ## 📊 Summary Section The **Summary** section provides a global view of the test. Typical fields include:
FieldDescription
TotalTotal number of locations used for the test
ONLINENumber of locations where the IP responded
OFFLINENumber of locations where the IP did not respond
HostChecked IP address
LocationsNumber of geographic test sources
AVGAverage latency across test locations
Median AVGMedian of per-location average RTT values
Global MINLowest RTT measured across all packets and locations
Global MAXHighest RTT measured across all packets and locations
Average LossAverage packet loss across all locations
BestLocation with the lowest average RTT
WorstLocation with the highest average RTT
Example: ```text ONLINE: 5 OFFLINE: 0 AVG: 1.716 ms Average Loss: 0.00% Best: Singapore, SG Worst: London, GB ``` This block helps users quickly identify whether the target is reachable globally and which regions have the best or worst connectivity. --- ## 🌍 Multi-Location Testing GeoPing runs checks from multiple geographic locations. Example locations may include: - Clifton, US - London, GB - Frankfurt am Main, DE - Amsterdam, NL - Singapore, SG Each location has its own result card showing availability and latency metrics. This is useful because network performance can vary significantly by region. For example: - A target may be fast from Europe but slow from Asia. - A CDN or anycast IP may route each region to a nearby node. - A firewall may allow traffic from one region but block another. - A routing issue may affect only one geography. - A hosting provider may have regional packet loss. --- ## ✅ Availability Status Each location returns an availability status. Common statuses:
StatusMeaning
ONLINEThe IP responded from that location
OFFLINENo response was received from that location
UNKNOWNThe result could not be confidently determined
Example: ```text ONLINE 1.83 ms Location: Clifton, US ``` If the IP is online from some regions and offline from others, this may indicate routing filters, regional firewall rules, DDoS protection behavior, provider issues, or temporary network problems. --- ## ⏱️ RTT Metrics RTT means **Round-Trip Time**. It measures how long a packet takes to travel from the test location to the target IP and back. Each location card may include: - MIN RTT - AVG RTT - MAX RTT - JITTER - RTT list Example: ```text Location: Frankfurt am Main, DE MIN: 0.982 ms AVG: 1.580 ms MAX: 2.166 ms JITTER: 0.592 ms Packets: 3/3 Losses: 0% ``` ### Minimum RTT The fastest response observed from that location. ### Average RTT The average response time from that location. ### Maximum RTT The slowest response observed from that location. ### RTT List The individual response times for each packet. Example: ```text RTT list: 1.250, 1.188, 1.250 ``` --- ## 📉 Jitter Jitter measures the variation between individual RTT values. Low jitter means the connection is stable. High jitter may indicate: - Network congestion - Routing instability - Provider-level issues - Packet scheduling delays - Wireless or last-mile problems - Intercontinental routing instability - Saturated links - Temporary packet queuing Example: ```text JITTER: 0.036 ms ``` A low jitter value is especially important for real-time applications such as VoIP, video calls, gaming, streaming, remote desktops, and interactive services. --- ## 📦 Packet Loss Packet loss shows how many requests failed compared to how many were sent. Example: ```text Packages received/sent: 3/3 Losses: 0% ``` Packet loss interpretation:
Packet LossMeaning
0%Excellent delivery
1–2%Minor loss, usually acceptable but should be monitored
3–5%Noticeable instability
5–10%Significant network problem
10%+Severe connectivity issue
Packet loss from one region but not others may indicate a regional routing problem or filtering issue. --- ## 🏆 Best and Worst Locations GeoPing automatically identifies the best and worst locations by average RTT. Example: ```text The Best: Singapore, SG (1.229 ms) The Worst: London, GB (2.515 ms) ``` ### Best Location The location with the lowest average RTT. This usually indicates the shortest or most efficient route from the test source to the target. ### Worst Location The location with the highest average RTT. This may indicate longer routing distance, less efficient routing, congestion, filtering, or provider-level latency. The best and worst labels are comparative within the current test, not absolute judgments of the target infrastructure. --- ## 📊 Aggregated Metrics GeoPing includes global aggregated metrics across all locations. ### Global Average Shows the overall average latency across test sources. ### Median Average Shows the median of per-location average RTT values. Median is useful because it is less affected by one unusually slow or fast location. ### Global Minimum Shows the fastest observed response from all locations. ### Global Maximum Shows the slowest observed response from all locations. ### Average Loss Shows the average packet loss across all test locations. These metrics help users understand global route quality at a glance. --- ## 🧠 Latency Interpretation Latency depends on geography, routing, peering, infrastructure, congestion, and target configuration. General RTT interpretation:
Average RTTInterpretation
0–20 msVery low latency
20–60 msGood latency
60–120 msModerate latency
120–250 msHigh latency
250–300+ msVery high latency, often intercontinental or problematic
TimeoutNo response, filtering, or target unavailable
Important: low latency from multiple regions may indicate anycast routing, CDN edge infrastructure, or globally distributed network design. High latency from one region may not mean the target is down. It may simply reflect distance, routing path, or provider differences. --- ## 🛰️ Anycast and CDN Interpretation GeoPing is especially useful for checking anycast and CDN-style infrastructure. For anycast services, the same IP address can be routed to different physical or logical locations depending on where the request originates. This can explain why an IP may show very low latency from multiple regions at the same time. Possible interpretations: - Anycast routing is working efficiently. - CDN edge nodes are close to the test sources. - DNS resolver or public service infrastructure is distributed. - Each region may reach a different backend node. - One region may be affected by routing or peering issues while others are healthy. GeoPing does not prove the exact physical destination server. It shows observed connectivity from each test source. --- ## 🕓 Request History GeoPing stores entered IP addresses in the user’s browser through LocalStorage. Important behavior: ```text The history of entered IP addresses is stored in your browser. ``` History may include: - Checked IP address - Timestamp - Summary status - Average RTT - Best / worst locations - Packet loss values The history is local to the browser and may be cleared when the user deletes browser data, switches devices, or uses another browser profile. On shared devices, users should clear local history when checked IPs are sensitive. --- ## 🧠 Key Features ### Multi-Location Ping Checks the same IP address from multiple geographic test sources. ### IPv4 and IPv6 Support Supports both IPv4 and IPv6 targets. ### Parallel Availability Checks Runs availability checks across several regions. ### Per-Location Results Each location shows status, RTT metrics, jitter, packets, loss, and RTT list. ### Aggregated Summary Shows global metrics such as average RTT, median, global min, global max, and average loss. ### Best / Worst Location Detection Automatically identifies the fastest and slowest test locations by average RTT. ### Packet Loss Analysis Displays packet loss per location and average loss globally. ### Jitter Measurement Shows latency stability for each geographic source. ### Local History Stores entered IPs locally in the browser. ### Regional Route Insight Helps compare network performance by geography. --- ## ✅ Recommended Diagnostic Workflow A practical GeoPing workflow should follow these steps. ### 1. Enter the IP Address Use only IPv4 or IPv6. Do not enter domains, URLs, ports, or paths. ### 2. Review Global Summary Check total locations, online count, offline count, average RTT, median RTT, and average packet loss. ### 3. Identify Best and Worst Locations Compare the fastest and slowest regions. ### 4. Review Per-Location Cards Check each location’s minimum, average, maximum RTT, jitter, and packet loss. ### 5. Look for Regional Problems Identify locations with high RTT, high jitter, packet loss, or offline status. ### 6. Compare With Expected Geography Consider whether the target is expected to be close to the fastest region. ### 7. Repeat if Needed Run another check if the issue appears temporary or inconsistent. ### 8. Correlate With Other Tools Use traceroute, HTTP checks, DNS checks, CDN monitoring, firewall logs, and provider status pages for deeper analysis. ### 9. Document Findings Use the summary and per-location metrics in troubleshooting reports or incident notes. ### 10. Validate Critical Issues Confirm important outages or routing problems with additional monitoring sources. --- ## 🔎 Common Use Cases GeoPing can support many technical workflows. ### Global Availability Check Confirm whether an IP is reachable from multiple regions. ### CDN and Anycast Testing Check how an anycast IP behaves from different geographic sources. ### Regional Routing Diagnostics Identify whether latency or packet loss affects specific regions. ### Incident Response Quickly determine whether an outage is global or region-specific. ### Hosting Provider Comparison Compare responsiveness of infrastructure from different test locations. ### Network Performance Review Evaluate latency consistency and jitter across regions. ### Firewall and Filtering Validation Check whether an IP responds from some countries but not others. ### SLA and Monitoring Support Use multi-location metrics as supporting evidence for service-quality review. --- ## ⚠️ Result Interpretation Notes GeoPing results should be interpreted carefully. Important limitations: - Some hosts block echo requests. - Offline from one region does not always mean the service is down. - A host can serve HTTP traffic even if ping is blocked. - Firewalls may treat test locations differently. - Anycast IPs may route each location to a different node. - RTT depends on distance, routing, and provider peering. - Small packet samples provide a quick diagnostic snapshot, not long-term monitoring. - Local or regional congestion may affect results temporarily. - GeoPing does not identify the exact physical server behind an anycast IP. For critical production systems, GeoPing should be combined with continuous monitoring and application-level checks. --- ## 🛡️ Security, Privacy & Responsible Use GeoPing is intended for lawful network diagnostics and infrastructure monitoring. Acceptable use cases include: - Checking your own servers - Testing authorized infrastructure - Reviewing regional availability - Diagnosing packet loss - Measuring latency and jitter - Supporting incident response - Monitoring CDN and anycast behavior - Validating firewall and routing behavior - Creating troubleshooting reports Users should follow responsible use principles: - Do not use the tool to harass or overload third-party systems. - Do not repeatedly test targets without a legitimate reason. - Do not treat ping failure as proof of full service outage. - Do not use results as the only source for critical operational decisions. - Respect applicable laws and network policies. - Treat local history as potentially sensitive on shared devices. --- ## ⚙️ Technical Highlights - Multi-location IP ping tool - Available at `dash.niamonx.io/geoping` - Supports IPv4 - Supports IPv6 - IP-only input - No domains or URLs accepted - Parallel checks from multiple geographic locations - Availability status by location - Global ONLINE / OFFLINE summary - Minimum RTT per location - Average RTT per location - Maximum RTT per location - Jitter per location - Packets received / sent - Packet loss per location - Individual RTT list - Global average RTT - Median average RTT - Global minimum RTT - Global maximum RTT - Average packet loss - Best location by average RTT - Worst location by average RTT - Source geography display - LocalStorage request history - Suitable for network diagnostics, DevOps, SOC, incident response, CDN checks, and global availability monitoring --- ## 📌 Usage Hints - Enter only an IPv4 or IPv6 address. - Do not enter domains, URLs, ports, or paths. - Use the global summary to check overall availability. - Use per-location cards to identify regional issues. - Compare best and worst locations for route quality. - Check packet loss before judging reliability. - Check jitter to detect unstable latency. - High RTT may be normal for long-distance routing. - Offline from one region may indicate filtering, not full outage. - Repeat tests if the result is unexpected. - Use additional diagnostics for production incidents. - Local history is stored in the browser through LocalStorage. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX GeoPing** is a multi-location IP availability and latency diagnostic tool for IPv4 and IPv6 addresses. It performs parallel checks from several geographic locations and returns global availability, per-location RTT metrics, packet loss, jitter, individual response times, best and worst locations, median latency, and aggregated performance indicators. The tool is designed for global availability checks, CDN and anycast validation, routing diagnostics, incident response, DevOps workflows, SOC triage, and infrastructure monitoring. Results should be treated as a regional network-performance snapshot and validated with additional diagnostics for critical decisions. # GlobeLine DNS | DNS Query & Record Intelligence [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/4GOkV5o0ZjC9CRWK-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/4GOkV5o0ZjC9CRWK-image.png) The platform available at **[https://dash.niamonx.io/gl\_dns](https://dash.niamonx.io/gl_dns)** — known as **GlobeLine DNS** — is a DNS intelligence and domain record lookup tool within the NiamonX platform. It allows users to perform DNS queries for a domain name and aggregate the returned records by type, including A, AAAA, MX, NS, TXT, and other records when available in the raw response. ## Overview of the Service **GlobeLine DNS** is designed to help users quickly inspect DNS configuration for a domain or subdomain. The tool performs DNS queries through the NiamonX resolver infrastructure and presents the results in a clean, structured format. It shows which record types were requested, which record types were resolved, how many records were found, request timing, resolver information, and individual DNS records grouped by type. GlobeLine DNS is useful for: - Domain configuration review - DNS troubleshooting - Mail infrastructure checks - Security and SPF validation - OSINT enrichment - SOC triage - Infrastructure monitoring - Domain migration checks - Incident response - Technical documentation The tool accepts domain names only. Users should enter a clean domain or subdomain without protocol, slashes, paths, or URL parameters. --- ## 🔍 How the Tool Works When a user enters a domain name, GlobeLine DNS performs DNS queries for the selected record types. Supported record types include: - A - AAAA - MX - NS - TXT If no record type is selected, the tool automatically uses type **A**. After the request is completed, the interface displays: - Query status - Number of returned records - Domain name - Request time - Resolver - Requested record types - Resolved record types - Count per record type - TTL information when available - Individual record values - Source location for returned records when available - Local browser request history Example result summary: ```text SUCCESS Records: 11 Domain: niamonx.io Request Time: 328.03 ms Requested: A, AAAA, MX, NS, TXT Resolved: A, AAAA, MX, NS, TXT ``` --- ## 🧩 What Can Be Checked GlobeLine DNS supports domain and subdomain checks. Valid examples: ```text example.com ``` ```text sub.example.com ``` ```text niamonx.io ``` Unsupported input examples: ```text https://example.com ``` ```text example.com/path ``` ```text https://example.com/login?x=1 ``` ```text 1.1.1.1 ``` The tool is intended for domain names only. IP lookup, ping, geolocation, and service discovery are handled by separate NiamonX modules. --- ## ⚙️ Query Interface The GlobeLine DNS interface includes a domain input field and record type selection controls. ### Domain Name The user enters a domain or subdomain. Example: ```text niamonx.io ``` The interface indicates: ```text Domain only — without protocol and slashes. ``` ### Types of Records Users can select one or more DNS record types. Available primary types: - A - AAAA - MX - NS - TXT Quick controls may include: - All - Take Off - Only A If nothing is selected, type **A** is used automatically. --- ## 📌 Supported Record Types ### A Record An **A** record maps a domain name to an IPv4 address. Example: ```text A 172.67.153.184 ``` A records are commonly used to route a domain to a web server, CDN edge, proxy, or hosting infrastructure. --- ### AAAA Record An **AAAA** record maps a domain name to an IPv6 address. Example: ```text AAAA 2606:4700:3033::6815:ce7 ``` AAAA records are used for IPv6-enabled services. --- ### MX Record An **MX** record identifies mail servers responsible for receiving email for the domain. Example: ```text MX mx.zoho.eu. ``` MX records are important for checking whether email delivery is configured correctly. --- ### NS Record An **NS** record identifies authoritative name servers for the domain. Example: ```text NS abdullah.ns.cloudflare.com. ``` NS records show which DNS provider or authoritative DNS infrastructure controls the domain zone. --- ### TXT Record A **TXT** record stores text-based DNS values. Common uses include: - SPF policies - DKIM records - DMARC records - Site verification - Domain ownership verification - Security and service configuration Example: ```text TXT v=spf1 include:zohomail.eu -all ``` TXT records are especially important for mail security and domain verification. --- ## 📊 Results Summary After a successful query, the tool displays a summary block. Typical fields include:
FieldDescription
StatusQuery result status
RecordsTotal number of returned records
DomainQueried domain
Request TimeTotal DNS query duration
ResolverResolver or source used for the request
RequestedDNS record types requested by the user
ResolvedDNS record types successfully returned
Type countersNumber of records per type
TTL averageAverage TTL per record type when available
Example: ```text SUCCESS Records: 11 Request Time: 328.03 ms Resolver: niamonx.io Requested: A, AAAA, MX, NS, TXT Resolved: A, AAAA, MX, NS, TXT ``` This helps users quickly understand whether DNS resolution succeeded and which record types were returned. --- ## 📋 Results Table DNS records are displayed in a structured table. Typical columns include:
ColumnDescription
TypeDNS record type
Meaning / ParametersReturned DNS value
TTLTime To Live value when available
Example table rows: ```text A 172.67.153.184 AAAA 2606:4700:3033::6815:ce7 MX mx.zoho.eu. NS abdullah.ns.cloudflare.com. TXT v=spf1 include:zohomail.eu -all ``` When available, the tool may also show resolver-side or source-location context for records. Example: ```text loc: Santa Clara, US ``` --- ## ⏱️ TTL Interpretation TTL means **Time To Live**. It tells DNS resolvers how long they may cache a record before checking again. A low TTL may indicate: - Active migration - Dynamic infrastructure - Load balancing changes - Failover preparation - Frequent DNS updates A high TTL may indicate: - Stable DNS configuration - Lower DNS query volume - Longer propagation time after changes If TTL is unavailable, the interface may show: ```text - ``` TTL availability depends on the DNS response and backend resolver behavior. --- ## 📬 Mail Configuration Review MX and TXT records are especially important for email security and delivery. GlobeLine DNS can help review: - Mail servers - SPF records - DKIM records - DMARC records - Domain verification records - Third-party mail provider configuration Example SPF record: ```text v=spf1 include:zohomail.eu -all ``` An SPF record defines which mail servers are authorized to send email for the domain. Security teams can use TXT records to check whether the domain has proper anti-spoofing configuration. --- ## 🛡️ Security-Relevant DNS Checks GlobeLine DNS can support several defensive security checks. ### SPF Review Check TXT records for SPF configuration. Look for records starting with: ```text v=spf1 ``` ### DKIM Review Check for DKIM selector records when querying specific DKIM subdomains. Example format: ```text selector._domainkey.example.com ``` ### DMARC Review Check the DMARC policy by querying: ```text _dmarc.example.com ``` ### Name Server Review Check NS records to confirm which provider controls authoritative DNS. ### Address Review Check A and AAAA records to confirm where the domain resolves. ### Mail Provider Review Check MX records to identify the active mail provider. --- ## 🌍 Resolver and Location Context The results may include resolver or location context. Example: ```text Resolver: niamonx.io loc: Santa Clara, US ``` This helps users understand where the DNS request was resolved from or what infrastructure was used for the lookup. DNS responses can vary by location due to: - GeoDNS - CDN routing - Anycast DNS - Split-horizon DNS - Resolver caching - Regional load balancing - DNS-based failover For global infrastructure, results from one resolver location should be treated as one perspective. --- ## 🕓 Request History GlobeLine DNS stores domain queries and selected record types in the browser. The history may include: - Queried domain - Selected record types - Timestamp - Query status - Record count - Result summary Important behavior: ```text The history of domains and the selection of types is stored in the browser. ``` Local history helps users repeat common DNS checks quickly. On shared or public devices, users should clear browser data when domain lookup history is sensitive. --- ## 🧠 Key Features ### DNS Query Tool Performs DNS queries for selected record types. ### Domain and Subdomain Support Accepts clean domain names and subdomains. ### Multiple Record Types Supports A, AAAA, MX, NS, and TXT. ### Automatic A Fallback If no type is selected, A is used automatically. ### Aggregated Results Groups returned data by DNS record type. ### Requested vs Resolved Types Shows which types were requested and which types returned results. ### Request Timing Displays DNS request duration. ### TTL Display Shows TTL values when available. ### Resolver Context Displays resolver/source information. ### Local History Stores domains and record type selections in the browser. ### Security Review Support Useful for SPF, MX, NS, and TXT-based security checks. --- ## ✅ Recommended Analyst Workflow A practical DNS review workflow should follow these steps. ### 1. Enter a Clean Domain Use only the domain or subdomain without protocol, slashes, or paths. ### 2. Select Record Types Choose A, AAAA, MX, NS, TXT, or use All for a broader check. ### 3. Review Query Status Confirm that the result status is SUCCESS. ### 4. Check Requested and Resolved Types Verify whether the requested record types returned data. ### 5. Review Address Records Check A and AAAA records for web or infrastructure routing. ### 6. Review Mail Records Check MX records for mail server configuration. ### 7. Review TXT Records Look for SPF, DKIM, DMARC, verification, and other security records. ### 8. Review Name Servers Check NS records to identify authoritative DNS providers. ### 9. Consider Resolver Perspective Remember that DNS responses can vary by geography, resolver, and cache state. ### 10. Document Findings Use returned records in reports, migration notes, incident response, or security reviews. --- ## 🔎 Common Use Cases GlobeLine DNS can support many technical workflows. ### Domain Troubleshooting Check whether a domain resolves correctly. ### Mail Delivery Debugging Review MX and SPF-related TXT records. ### DNS Migration Validation Confirm that records have changed after a provider or hosting migration. ### Security Audit Check SPF, DKIM, DMARC, NS, and exposed address records. ### OSINT Enrichment Collect DNS infrastructure indicators for a domain. ### Incident Response Review DNS changes, suspicious TXT records, or unexpected IP addresses. ### Infrastructure Documentation Create a quick snapshot of domain DNS configuration. ### CDN and Hosting Review Identify whether a domain points to CDN, cloud, or hosting infrastructure. --- ## ⚠️ Result Interpretation Notes DNS results should be interpreted carefully. Important points: - DNS records can change quickly. - Resolver cache may affect results. - GeoDNS may return different records from different regions. - CDN-backed domains may resolve to different IPs depending on location. - Missing records do not always mean misconfiguration. - TXT records can contain multiple unrelated service values. - MX records identify mail routing, not necessarily all email security settings. - TTL may be unavailable depending on backend response. - Some security records require querying specific subdomains, such as `_dmarc.example.com`. For critical DNS changes, compare results with authoritative DNS tools and multiple resolvers. --- ## 🛡️ Security, Privacy & Responsible Use GlobeLine DNS is intended for lawful DNS troubleshooting, security analysis, domain administration, OSINT enrichment, and infrastructure review. Acceptable use cases include: - Checking your own domains - Reviewing public DNS records - Validating mail configuration - Investigating suspicious domains - Supporting SOC triage - Documenting DNS infrastructure - Checking SPF, DKIM, DMARC, MX, and NS records - Monitoring domain changes - Troubleshooting DNS propagation Users should follow responsible use principles: - Do not misuse DNS data for phishing or impersonation. - Do not use results to target third-party infrastructure. - Validate suspicious findings with additional sources. - Treat lookup history as potentially sensitive on shared devices. - Use the tool only for lawful and ethical analysis. --- ## ⚙️ Technical Highlights - DNS query tool - Available at `dash.niamonx.io/gl_dns` - Supports domain and subdomain input - Rejects protocols and URL paths - Supports A records - Supports AAAA records - Supports MX records - Supports NS records - Supports TXT records - Uses A automatically when no record type is selected - Supports multi-type queries - Shows requested record types - Shows resolved record types - Aggregates results by type - Shows record counts - Shows request time - Shows resolver information - Shows TTL when available - Stores domain history locally in the browser - Stores selected record types locally in the browser - Suitable for DNS troubleshooting, mail security checks, OSINT, SOC workflows, and infrastructure review --- ## 📌 Usage Hints - Enter only a domain or subdomain. - Do not include `https://`, slashes, paths, or query strings. - Select A for IPv4 address records. - Select AAAA for IPv6 address records. - Select MX to check mail servers. - Select NS to check authoritative name servers. - Select TXT to check SPF, verification, and other text records. - Use All for a complete basic DNS overview. - If nothing is selected, A will be used automatically. - Check requested and resolved types to understand missing results. - Remember that DNS responses may differ by resolver and region. - Query `_dmarc.example.com` separately to check DMARC. - Query DKIM selector subdomains separately when needed. - Local history is stored in the browser. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX GlobeLine DNS** is a DNS query and domain record intelligence tool for checking A, AAAA, MX, NS, and TXT records. It accepts clean domain or subdomain input, performs selected DNS queries, aggregates results by type, shows requested and resolved record groups, displays request time, resolver context, record counts, TTL values when available, and stores query history locally in the browser. The tool is designed for DNS troubleshooting, mail configuration review, SPF and TXT analysis, infrastructure documentation, SOC triage, OSINT enrichment, and domain security workflows. # GeoDNS | Geographic DNS Response Intelligence [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/dKuYnuVzsmOIuWXp-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/dKuYnuVzsmOIuWXp-image.png) The platform available at **[https://dash.niamonx.io/geodns](https://dash.niamonx.io/geodns)** — known as **GeoDNS** — is a multi-location DNS intelligence tool within the NiamonX platform. It allows users to query DNS records for a domain from several geographic locations and compare how responses differ across regions. ## Overview of the Service **GeoDNS** is designed to help users understand how a domain resolves from different parts of the world. Unlike a standard DNS lookup, which checks records from a single resolver or location, GeoDNS performs DNS queries from multiple geographic test points. This makes it possible to detect regional DNS differences, CDN routing behavior, GeoDNS configuration, DNS propagation issues, resolver inconsistencies, and location-based infrastructure allocation. The tool supports common DNS record types, including: - A - AAAA - MX - NS - TXT GeoDNS is useful for system administrators, DevOps teams, SOC analysts, cybersecurity researchers, infrastructure owners, domain administrators, compliance teams, and OSINT analysts who need to verify DNS behavior across multiple regions. --- ## 🔍 How the Tool Works When a user enters a domain name and selects DNS record types, GeoDNS sends DNS queries from multiple geographic locations. Each location performs the selected DNS requests and returns the records visible from that region. The tool then aggregates all responses and displays: - Global query status - Number of test locations - Total number of DNS responses - Total request time - Requested record types - Resolved record types - Unique values by record type - Per-location answers - Geographic source coordinates - Raw JSON with additional technical details If no record type is selected, the tool automatically uses **A** records. Example flow: 1. User enters a domain. 2. User selects one or more DNS record types. 3. GeoDNS queries the domain from several locations. 4. Responses are grouped by geographic source. 5. Unique DNS values are counted by type. 6. The final report shows global and regional DNS behavior. --- ## 🧩 What Can Be Checked GeoDNS accepts clean domain and subdomain names only. Valid examples: ```text example.com ``` ```text sub.example.com ``` ```text niamonx.io ``` Invalid examples: ```text https://example.com ``` ```text example.com/path ``` ```text https://example.com/login ``` ```text 1.1.1.1 ``` The tool is intended for DNS checks of domains and subdomains. It should not be used with URLs, protocols, paths, query strings, IP addresses, or ports. --- ## ⚙️ Query Interface The GeoDNS interface contains a domain input field and DNS record type controls. ### Domain Name The user enters a clean domain or subdomain. Example: ```text niamonx.io ``` The interface expects the domain only, without: - `https://` - `http://` - Slashes - Paths - URL parameters - Ports ### Types of Requests Users can select one or more DNS record types. Supported types: - A - AAAA - MX - NS - TXT Quick controls may include: - All - Remove - Only A If nothing is selected, the system automatically uses type **A**. --- ## 📌 Supported DNS Record Types ### A Records An **A** record maps a domain to an IPv4 address. Example: ```text A 172.67.153.184 ``` A records are commonly used for websites, APIs, CDNs, proxies, and IPv4 infrastructure. --- ### AAAA Records An **AAAA** record maps a domain to an IPv6 address. Example: ```text AAAA 2606:4700:3033::6815:ce7 ``` AAAA records are used for IPv6-enabled services. --- ### MX Records An **MX** record identifies mail servers responsible for receiving email for the domain. Example: ```text MX mx.zoho.eu. ``` MX records are important for mail routing, email delivery, and mail-provider verification. --- ### NS Records An **NS** record identifies authoritative name servers for the domain. Example: ```text NS abdullah.ns.cloudflare.com. ``` NS records show which DNS provider or authoritative DNS infrastructure controls the zone. --- ### TXT Records A **TXT** record stores text-based DNS data. Common TXT record uses include: - SPF - DKIM - DMARC - Domain ownership verification - Google / Microsoft / SaaS verification - Security policies - Service configuration Example: ```text TXT v=spf1 include:zohomail.eu -all ``` TXT records are often important for domain security and compliance checks. --- ## 📊 Summary Section After a successful query, GeoDNS displays a global summary. Typical fields include:
FieldDescription
StatusOverall query result status
LocationsNumber of geographic locations used
ResponsesTotal number of returned DNS answers
DomainQueried domain
TimeTotal request duration
RequestedRecord types requested by the user
ResolvedRecord types successfully returned
Unique ANumber of unique IPv4 answers
Unique AAAANumber of unique IPv6 answers
Unique MXNumber of unique mail server answers
Unique NSNumber of unique name server answers
Unique TXTNumber of unique TXT answers
Example summary: ```text SUCCESS Locations: 5 Responses: 55 Domain: niamonx.io Time: 2297.86 ms Requested: A, AAAA, MX, NS, TXT Resolved: A, AAAA, MX, NS, TXT Unique A: 2 Unique AAAA: 2 Unique MX: 3 Unique NS: 2 Unique TXT: 2 ``` This summary helps users quickly understand whether DNS records are consistent globally and how many unique values were observed. --- ## 🌍 Per-Location Results GeoDNS displays DNS answers separately for each test location. Each location block may include: - Location number - Coordinates - City and country - Returned DNS answers - Record types returned from that location Example location block: ```text #1 Location: Clifton, US Coordinates: 40.8584, -74.1638 Answers: A 172.67.153.184 A 104.21.12.231 AAAA 2606:4700:3030::ac43:99b8 MX mx.zoho.eu. NS abdullah.ns.cloudflare.com. TXT v=spf1 include:zohomail.eu -all ``` Per-location results are the core value of GeoDNS. They allow analysts to compare regional DNS behavior instead of relying on a single resolver response. --- ## 🗺️ Geographic Test Locations GeoDNS uses multiple geographic sources for DNS resolution. Example locations may include: - Clifton, US - London, GB - Amsterdam, NL - Frankfurt am Main, DE - Singapore, SG Each location can return the same or different DNS answers depending on the domain’s DNS configuration, CDN provider, resolver behavior, cache state, or regional routing policy. Geographic DNS results are especially useful for domains using: - CDN providers - Anycast DNS - GeoDNS - Regional load balancing - Multi-region infrastructure - Split traffic routing - Regional failover - DNS-based traffic steering --- ## 🔁 Requested vs Resolved Types GeoDNS clearly shows which record types were requested and which were actually resolved. Example: ```text Requested: A, AAAA, MX, NS, TXT Resolved: A, AAAA, MX, NS, TXT ``` If some requested types do not return answers, the status may be partial. Example: ```text Requested: A, AAAA, MX, NS, TXT Resolved: A, NS, TXT Status: partial ``` This helps analysts quickly identify missing or unavailable DNS records. --- ## ⚠️ Partial Status If some selected record types do not match or do not return from all locations, the query may be marked as partial. A partial result may indicate: - The domain does not have that record type. - Some resolvers did not return the record. - DNS propagation is incomplete. - A regional resolver returned different results. - A record type is blocked or filtered. - The backend source returned incomplete data. - The domain configuration is inconsistent. A partial status is not always an error. It means the user should review the per-location answers and resolved types carefully. --- ## 🧮 Unique Values by Type GeoDNS calculates unique DNS answers by record type. Example: ```text Unique A: 2 Unique AAAA: 2 Unique MX: 3 Unique NS: 2 Unique TXT: 2 ``` This is useful for identifying whether all locations returned the same values or whether responses vary geographically. ### Low Unique Count A low unique count usually means the DNS response is consistent globally. ### High Unique Count A high unique count may indicate: - GeoDNS routing - CDN edge allocation - Regional load balancing - DNS failover - Multi-cloud infrastructure - Inconsistent DNS propagation - Resolver differences --- ## 🌐 GeoDNS and CDN Behavior Many modern domains use CDNs or geographically distributed DNS infrastructure. GeoDNS helps detect this behavior. Possible patterns: ### Same Records Everywhere If all locations return the same A and AAAA values, the domain likely has globally consistent DNS responses. ### Different A / AAAA Records by Region If locations return different IPs, the domain may use GeoDNS, CDN edge routing, regional load balancing, or DNS steering. ### Same MX / NS Everywhere Mail and authoritative DNS records are often globally consistent. ### TXT Differences TXT records are usually consistent, but differences may indicate propagation delay, configuration drift, or resolver cache differences. --- ## 📬 Mail and Security Record Review GeoDNS can be used to check whether mail and security-related DNS records are globally visible. Important record types: - MX - TXT - NS Common TXT checks: - SPF - DKIM - DMARC - Domain verification - SaaS verification Example SPF record: ```text v=spf1 include:zohomail.eu -all ``` To check DMARC, users should query: ```text _dmarc.example.com ``` To check DKIM, users should query the specific selector subdomain, such as: ```text selector._domainkey.example.com ``` --- ## 📦 Raw JSON The tool can show Raw JSON with additional technical details. Raw JSON may include: - Location metadata - Resolver details - Record values - Record types - Response timing - Internal status fields - Backend diagnostics - Full per-location response objects Raw JSON is useful for: - Advanced troubleshooting - Developer analysis - SOC workflows - API-style evidence capture - Comparing normalized and raw results - Creating internal reports - Debugging inconsistent DNS behavior Raw output should be handled carefully when it contains internal investigation details. --- ## 🕓 Request History GeoDNS stores domain query history and selected record types locally in the browser. The history may include: - Queried domain - Selected record types - Timestamp - Status - Response count - Location count Local history helps users repeat previous checks quickly. Because it is browser-local, it may be cleared when browser data is deleted or when another browser profile is used. On shared devices, users should clear local history if domain checks are sensitive. --- ## 🧠 Key Features ### Multi-Location DNS Queries Runs DNS checks from several geographic locations. ### Domain and Subdomain Support Accepts clean domain and subdomain names. ### Common DNS Record Types Supports A, AAAA, MX, NS, and TXT. ### Automatic A Fallback If no type is selected, A is used automatically. ### Regional Response Comparison Displays DNS answers separately by location. ### Unique Value Aggregation Counts unique DNS responses per record type. ### Requested and Resolved Summary Shows what was requested and what was returned. ### Partial Status Detection Highlights cases where not all requested types were resolved. ### Raw JSON View Allows technical review of additional response details. ### Local History Stores query history and selected types locally in the browser. --- ## ✅ Recommended Analyst Workflow A practical GeoDNS workflow should follow these steps. ### 1. Enter a Clean Domain Use only a domain or subdomain. Do not include protocol, path, or URL parameters. ### 2. Select Record Types Choose A, AAAA, MX, NS, TXT, or use All for a broad overview. ### 3. Review the Summary Check status, locations, responses, requested types, resolved types, and unique counts. ### 4. Compare Locations Look for differences between Clifton, London, Amsterdam, Frankfurt, Singapore, or other returned locations. ### 5. Review Unique Values Check whether unique A / AAAA values differ across regions. ### 6. Validate Mail Records Review MX and TXT records for mail and verification consistency. ### 7. Investigate Partial Results If status is partial, check which locations or record types did not return expected results. ### 8. Use Raw JSON When Needed Open Raw JSON for deeper diagnostics. ### 9. Repeat After DNS Changes Run another check after DNS updates, migrations, or propagation windows. ### 10. Confirm Critical Issues Use authoritative DNS tools and multiple resolvers before making production decisions. --- ## 🔎 Common Use Cases GeoDNS supports many technical workflows. ### DNS Propagation Check Verify whether DNS updates are visible from multiple locations. ### CDN Validation Check whether a CDN returns different IPs by region. ### GeoDNS Testing Confirm location-based DNS allocation. ### Mail Configuration Review Check MX and TXT record consistency globally. ### Domain Migration Validation Verify that records changed correctly after moving DNS providers or hosting. ### Incident Response Investigate DNS hijacking, unexpected records, or inconsistent resolver behavior. ### SOC and OSINT Enrichment Collect regional DNS evidence for suspicious domains. ### Infrastructure Monitoring Track whether critical DNS records remain stable across locations. --- ## ⚠️ Result Interpretation Notes GeoDNS results should be interpreted carefully. Important points: - DNS responses may vary by location. - Different answers are not always suspicious. - CDN and GeoDNS providers intentionally return regional answers. - Resolver cache may affect results. - DNS propagation can take time. - TXT record order may vary between responses. - MX record order may vary while representing the same configuration. - Partial status may mean records are missing, filtered, delayed, or simply not configured. - One test is a snapshot, not continuous monitoring. For production DNS decisions, compare GeoDNS results with authoritative DNS checks and monitoring tools. --- ## 🛡️ Security, Privacy & Responsible Use GeoDNS is intended for lawful DNS troubleshooting, infrastructure analysis, security review, OSINT enrichment, and domain administration. Acceptable use cases include: - Checking your own domains - Validating DNS propagation - Reviewing CDN behavior - Investigating suspicious domains - Checking mail configuration - Reviewing SPF, DKIM, DMARC, MX, and NS visibility - Supporting SOC triage - Documenting DNS infrastructure - Monitoring regional DNS behavior Users should follow responsible use principles: - Do not use DNS intelligence for phishing or impersonation. - Do not target third-party infrastructure based only on DNS results. - Validate suspicious findings with additional sources. - Treat lookup history as potentially sensitive on shared devices. - Use Raw JSON responsibly. - Use the tool only for lawful and ethical analysis. --- ## ⚙️ Technical Highlights - GeoDNS intelligence module - Available at `dash.niamonx.io/geodns` - Performs DNS queries from multiple geographic locations - Supports domain and subdomain input - Rejects protocols, paths, and full URLs - Supports A records - Supports AAAA records - Supports MX records - Supports NS records - Supports TXT records - Uses A automatically when no type is selected - Shows global query status - Shows number of locations - Shows total response count - Shows total request time - Shows requested record types - Shows resolved record types - Counts unique records by type - Displays answers per location - Shows location coordinates - Supports Raw JSON details - Stores query history locally - Stores selected record types locally - Suitable for DNS propagation checks, CDN validation, SOC workflows, OSINT, and infrastructure monitoring --- ## 📌 Usage Hints - Enter only a domain or subdomain. - Do not include `https://`, paths, query strings, or slashes. - Select A for IPv4 address records. - Select AAAA for IPv6 address records. - Select MX for mail routing. - Select NS for authoritative name servers. - Select TXT for SPF, verification, and security records. - Use All for a complete basic DNS overview. - If nothing is selected, A will be used automatically. - Compare answers by location to detect GeoDNS behavior. - Check unique values to understand regional differences. - Use Raw JSON for deeper diagnostics. - Query `_dmarc.example.com` separately for DMARC. - Query DKIM selector subdomains separately for DKIM. - Remember that DNS results can differ because of cache, CDN, resolver, or propagation behavior. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX GeoDNS** is a multi-location DNS intelligence tool that checks DNS records from several geographic locations and shows how domain responses are distributed globally. It supports A, AAAA, MX, NS, and TXT queries, displays requested and resolved record types, counts unique values by type, groups answers by location, provides Raw JSON for deeper analysis, and stores query history locally in the browser. The tool is designed for DNS propagation checks, GeoDNS validation, CDN behavior analysis, mail configuration review, SOC triage, OSINT enrichment, domain migration validation, and infrastructure monitoring. # DNS Resolver / Reverse | Forward and Reverse DNS Resolution [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/GoajRmd4HHxpityY-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/GoajRmd4HHxpityY-image.png) The platform available at **[https://dash.niamonx.io/dns\_rrsv](https://dash.niamonx.io/dns_rrsv)** — known as **DNS Resolver / Reverse** — is a DNS resolution utility within the NiamonX platform. It allows users to perform forward DNS resolution from a domain name to IP address and reverse DNS resolution from an IP address to PTR hostname. ## Overview of the Service **DNS Resolver / Reverse** is designed for fast, simple, and structured DNS resolution checks. The tool supports two core workflows: - **Resolve** — domain name to IPv4 / IPv6 address - **Reverse** — IP address to PTR / reverse hostname It is useful for system administrators, SOC analysts, cybersecurity researchers, developers, DevOps engineers, infrastructure owners, incident responders, and OSINT analysts who need to quickly verify how a domain resolves or which reverse DNS name is associated with an IP address. The tool provides both a human-readable result table and a JSON output, making it suitable for manual analysis, documentation, troubleshooting, and lightweight technical workflows. --- ## 🔍 How the Tool Works The user selects a mode and enters the appropriate value. In **Resolve** mode, the user enters a domain or hostname. The tool returns one or more IPv4 / IPv6 addresses associated with that name. Example: ```text google.com → 172.253.63.138 ``` In **Reverse** mode, the user enters an IPv4 or IPv6 address. The tool performs a reverse DNS lookup and returns the PTR hostname when available. Example: ```text 8.8.8.8 → dns.google ``` The output is displayed in a compact result block, a request / answer table, and raw JSON format. The history of lookups is stored locally in the browser through LocalStorage and is not sent to the server. --- ## 🧩 Supported Modes DNS Resolver / Reverse supports two main modes. ### Resolve Mode Resolve mode performs forward DNS resolution. Direction: ```text Domain → IP ``` This mode accepts a clean domain or hostname. Examples: ```text example.com ``` ```text api.example.com ``` ```text google.com ``` Resolve mode may return: - One IPv4 address - Multiple IPv4 addresses - One IPv6 address - Multiple IPv6 addresses - Mixed A / AAAA-style responses, depending on backend resolution behavior --- ### Reverse Mode Reverse mode performs reverse DNS resolution. Direction: ```text IP → PTR ``` This mode accepts IPv4 or IPv6 addresses. Examples: ```text 8.8.8.8 ``` ```text 1.1.1.1 ``` ```text 2606:4700:4700::1111 ``` Reverse mode may return a PTR hostname if one exists. Not every IP address has reverse DNS configured. If no PTR record exists, the tool may return an empty result, error state, or no answer depending on backend behavior. --- ## 🚫 Input Rules The tool validates input depending on the selected mode. ### Resolve Mode Input Allowed: - Domain names - Subdomains - Hostnames Examples: ```text example.com ``` ```text api.example.com ``` Not allowed: ```text https://example.com ``` ```text example.com/path ``` ```text example.com:443 ``` ```text http://api.example.com/v1 ``` Protocols and paths are discarded or rejected depending on validation behavior. For best results, users should enter only the clean domain or hostname. --- ### Reverse Mode Input Allowed: - IPv4 addresses - IPv6 addresses Examples: ```text 1.1.1.1 ``` ```text 2001:4860:4860::8888 ``` Not allowed: ```text example.com ``` ```text https://1.1.1.1 ``` ```text 1.1.1.1:443 ``` Reverse mode expects only a clean IP address. --- ## ⚙️ Interface Structure The DNS Resolver / Reverse interface contains the following main elements. ### Mode The user selects the lookup mode. Available modes: - Resolve - Reverse Example: ```text Mode: Resolve (Domain → IP) ``` ### Domain / Hostname In Resolve mode, the user enters a domain or hostname. Example: ```text google.com ``` ### IP Address In Reverse mode, the user enters an IPv4 or IPv6 address. Example: ```text 8.8.8.8 ``` ### Request History The interface includes local request history with mode filtering. Users can filter history by: - All - Resolve - Reverse This helps quickly review previous DNS checks. --- ## 📊 Result Summary After a lookup is completed, the tool displays a result summary. Example: ```text RESOLVE Answers: 1 Request: google.com Line: 1 Total Responses: 1 ``` The summary helps users quickly understand: - Which mode was used - Whether the lookup returned answers - How many responses were returned - What value was requested --- ## 📋 Request / Answer Table The result table displays the original request and the returned answer or answers. Example:
RequestAnswer(s)
`google.com``172.253.63.138`
For domains with multiple results, the answer field may contain several IP addresses. Example:
RequestAnswer(s)
`example.com``93.184.216.34`, `2606:2800:220:1:248:1893:25c8:1946`
For reverse lookups, the table may show:
RequestAnswer(s)
`8.8.8.8``dns.google`
This format is designed for quick copying into tickets, reports, notes, or troubleshooting documentation. --- ## 🧾 JSON Output The tool also provides a raw JSON-style result. Example: ```json { "result": { "google.com": "172.253.63.138" } } ``` JSON output is useful for: - Technical documentation - Automation workflows - Internal tools - Evidence capture - Debugging - SOC case notes - Copying structured results into reports When multiple answers are returned, the JSON may include arrays or multiple values depending on backend output. --- ## 🔁 Forward Resolution Forward DNS resolution maps a domain name to one or more IP addresses. Common use cases: - Checking where a domain points - Validating DNS configuration - Troubleshooting domain access - Confirming CDN or hosting resolution - Checking if a hostname resolves - Reviewing infrastructure during migration - Enriching indicators during SOC triage Example: ```text api.example.com → 203.0.113.10 ``` Forward resolution may return IPv4, IPv6, or both depending on the records available. --- ## 🔄 Reverse Resolution Reverse DNS resolution maps an IP address to a hostname using PTR records. Common use cases: - Identifying server naming - Reviewing mail server configuration - Investigating suspicious IPs - Enriching security logs - Checking hosting infrastructure - Validating reverse DNS for outbound mail systems - Mapping infrastructure ownership clues Example: ```text 1.1.1.1 → one.one.one.one ``` Reverse DNS is optional. Many IP addresses do not have PTR records, and some PTR records may be generic or outdated. --- ## 🧠 Key Features ### Forward DNS Resolution Resolves a domain or hostname to IP address data. ### Reverse DNS Resolution Resolves an IP address to PTR hostname when available. ### IPv4 and IPv6 Support Reverse mode supports both IPv4 and IPv6. ### Multiple Responses The tool supports multiple returned responses, including A / AAAA-style arrays. ### Human-Readable Summary Results are displayed in a clean request / answer format. ### JSON Output Structured JSON output is available for technical workflows. ### Mode-Based History Query history can be filtered by lookup mode. ### LocalStorage Privacy History is stored locally in the browser and is not sent to the server. ### Input Validation Resolve mode validates domain input, while reverse mode validates IPv4 / IPv6 input. --- ## 🕓 Request History The request history stores previous lookups locally in the browser. Important behavior: ```text The history is stored in LocalStorage and is not sent to the server. ``` History may include: - Lookup mode - Requested value - Result summary - Timestamp - Number of answers History is useful for repeating checks and reviewing recent troubleshooting activity. Because it is browser-local, it may be cleared if the user clears browser data, switches devices, or uses a different browser profile. On shared devices, users should clear local history when lookup targets are sensitive. --- ## 🔎 Common Use Cases DNS Resolver / Reverse can support many technical workflows. ### Domain Troubleshooting Check whether a domain or subdomain resolves to an IP address. ### Reverse DNS Verification Check whether an IP address has a PTR hostname. ### Mail Server Review Verify reverse DNS for mail infrastructure. ### SOC Triage Enrich suspicious domains or IPs during alert analysis. ### Incident Response Quickly map domains to IPs or IPs to hostnames. ### Infrastructure Migration Validate whether DNS changes resolve as expected. ### OSINT Enrichment Collect basic resolution data for public indicators. ### Developer Debugging Confirm whether an application hostname resolves correctly. --- ## 📬 Mail and Reverse DNS Reverse DNS is especially important for email infrastructure. Mail servers often require properly configured PTR records to improve deliverability and reduce spam classification risk. Example checks: ```text mail.example.com → 203.0.113.25 203.0.113.25 → mail.example.com ``` A clean forward-confirmed reverse DNS setup can help validate that the hostname and IP align. However, this tool performs direct resolve and reverse checks only. Full mail authentication review should also include MX, SPF, DKIM, DMARC, and SMTP banner validation. --- ## ⚠️ Result Interpretation Notes DNS resolution results should be interpreted carefully. Important points: - DNS answers may change over time. - CDN-backed domains may return different IPs from different resolvers. - Some domains return multiple A or AAAA records. - Reverse DNS may not exist for every IP. - PTR records can be outdated or generic. - A resolved IP does not prove exclusive ownership. - A reverse hostname does not always identify the real service. - DNS caching can affect repeated results. - Forward and reverse DNS may not match perfectly. - A single lookup is a snapshot, not continuous monitoring. For critical infrastructure decisions, users should compare results with authoritative DNS data and multiple resolvers. --- ## ✅ Recommended Workflow A practical DNS resolution workflow should follow these steps. ### 1. Choose the Correct Mode Use Resolve for domain-to-IP checks and Reverse for IP-to-hostname checks. ### 2. Enter a Clean Value Use only a domain in Resolve mode or only an IP in Reverse mode. ### 3. Review the Summary Check mode, answer count, request value, and total responses. ### 4. Review the Table Copy the request / answer pair if needed. ### 5. Check JSON Output Use JSON for structured documentation or technical workflows. ### 6. Compare With Other DNS Tools For critical results, verify using authoritative DNS or multi-location DNS tools. ### 7. Review Local History Use the mode filter to find previous checks. ### 8. Clear History on Shared Devices Remove LocalStorage history if the lookup values are sensitive. --- ## 🛡️ Security, Privacy & Responsible Use DNS Resolver / Reverse is intended for lawful DNS troubleshooting, system administration, cybersecurity analysis, OSINT enrichment, and infrastructure review. Acceptable use cases include: - Checking your own domains - Resolving public hostnames - Reviewing PTR records - Investigating suspicious IPs - Supporting SOC workflows - Debugging network applications - Validating infrastructure changes - Creating technical documentation Users should follow responsible use principles: - Do not use DNS data for phishing, impersonation, or targeting. - Do not assume ownership from a single DNS answer. - Do not treat missing reverse DNS as proof of malicious activity. - Validate important conclusions with additional sources. - Treat local lookup history as potentially sensitive on shared devices. - Use the tool only for lawful and ethical analysis. --- ## ⚙️ Technical Highlights - Forward and reverse DNS resolution tool - Available at `dash.niamonx.io/dns_rrsv` - Resolve mode: domain name to IPv4 / IPv6 address - Reverse mode: IP address to PTR hostname - Supports multiple responses - Supports A / AAAA-style arrays - Human-readable result table - JSON result output - Summary copying support - JSON copying support - Query history with mode filter - Resolve validation: domain only - Reverse validation: IPv4 / IPv6 only - Protocols and paths are discarded or rejected - History stored locally in browser LocalStorage - History is not sent to the server - Suitable for DNS troubleshooting, SOC triage, OSINT enrichment, infrastructure review, and DevOps workflows --- ## 📌 Usage Hints - Use Resolve mode for domain-to-IP checks. - Use Reverse mode for IP-to-PTR checks. - Enter domains without `https://`, paths, or slashes. - Enter only IPv4 or IPv6 in Reverse mode. - Review multiple answers when returned. - Use JSON output for technical documentation. - Use request history mode filters to find previous checks. - Remember that reverse DNS is optional and may be missing. - DNS answers may differ by resolver, geography, and cache. - Use GeoDNS for multi-location DNS comparison. - Use GlobeLine DNS for record-type-specific DNS checks. - Clear local history on shared devices. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX DNS Resolver / Reverse** is a lightweight DNS utility for forward and reverse resolution. It resolves domains and hostnames to IPv4 / IPv6 addresses, resolves IP addresses to PTR hostnames, supports multiple responses, displays results in both human-readable and JSON formats, and stores lookup history locally in the browser. The tool is designed for DNS troubleshooting, infrastructure validation, SOC triage, OSINT enrichment, mail server review, DevOps workflows, and technical documentation. # Reverse IP Lookup | Passive Reverse IP Domain Intelligence [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/tOzHn3syzU4IZSo0-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/tOzHn3syzU4IZSo0-image.png) The platform available at **[https://dash.niamonx.io/ripip](https://dash.niamonx.io/ripip)** — known as **Reverse IP Lookup** — is a passive reverse IP intelligence tool within the NiamonX platform. It allows users to search for domain names associated with a specific IPv4 or IPv6 address using passive DNS and reverse DNS-style intelligence sources. ## Overview of the Service **Reverse IP Lookup** is designed to help analysts identify which domains have been observed resolving to the same IP address. The tool is useful for cybersecurity analysts, SOC teams, OSINT researchers, infrastructure owners, incident responders, fraud investigators, domain researchers, and compliance teams who need to understand the domain footprint connected to a specific IP. A single IP address can host one domain, many unrelated domains, parked domains, generated domains, CDN-backed assets, customer websites, phishing infrastructure, malware infrastructure, or shared hosting environments. Reverse IP Lookup helps expose these relationships in a clean and structured format. The tool performs **Passive Reverse IP** analysis, meaning it collects known or observed domain associations for the IP rather than actively scanning the server. --- ## 🔍 How the Tool Works When a user enters an IP address, Reverse IP Lookup searches passive DNS / reverse intelligence data for domains that have been observed resolving to that IP. The result contains a summary and a domain table. The system may return: - Total number of domains - Number of unique TLDs - Maximum domain length - Average domain length - Top TLD distribution - Domain list - TLD filter - Search filter - Pagination - Export options - Raw JSON - Local browser request history Example input: ```text 95.130.254.22 ``` Example result summary: ```text IP: 95.130.254.22 Domains: 1 Unique TLD: 1 MaxLen: 19 Average Length: 19.0 Top TLD: com(1) ``` This gives users a quick view of how many domains are connected to the IP and what kind of domain distribution was observed. --- ## 🧩 What Can Be Searched Reverse IP Lookup supports IP-based lookup. Supported input types: - IPv4 address - IPv6 address Valid examples: ```text 95.130.254.22 ``` ```text 1.1.1.1 ``` ```text 2001:4860:4860::8888 ``` Unsupported input examples: ```text example.com ``` ```text https://example.com ``` ```text 95.130.254.22:443 ``` ```text example.com/path ``` The tool expects only a clean IPv4 or IPv6 address. Domain-to-IP resolution should be performed in a separate DNS or IP / Domain Explorer module before using Reverse IP Lookup. --- ## 📌 What Passive Reverse IP Means **Passive Reverse IP** means that the tool uses collected or observed DNS intelligence to identify domains linked to an IP address. It is different from: - Active port scanning - Web crawling - Directory brute-forcing - Service exploitation - Live server enumeration Passive Reverse IP focuses on known domain-to-IP associations. This approach is useful because it allows analysts to understand the visible domain footprint of an IP without directly interacting with hosted websites or services. --- ## ⚙️ Interface Structure The Reverse IP Lookup interface contains several key areas. ### IP Address Input The main field where the user enters an IPv4 or IPv6 address. Example: ```text 95.130.254.22 ``` The interface supports IPv4 and IPv6. ### Request History Displays previous IP lookups stored locally in the browser. ### Summary Shows total domain statistics for the queried IP. ### Domains Table Displays the domain names associated with the IP. ### TLD Filter Allows users to filter domains by top-level domain. ### Search Filter Allows users to search within the returned domain list. ### Raw JSON Provides structured technical output for advanced analysis. --- ## 📊 Summary Section The summary section provides a quick statistical overview of the IP’s domain footprint. Typical fields include:
FieldDescription
IPQueried IPv4 or IPv6 address
DomainsTotal number of returned domain names
Domain NamesCount of domain records
Unique TLDNumber of unique top-level domains
Maximum LengthsLongest domain length in the result set
Average LengthsAverage domain length
TOP TLDMost frequent TLDs and their counts
TimestampTime when the lookup was performed
Example: ```text IP: 95.130.254.22 Domain Names: 1 Unique TLD: 1 Maximum Lengths: 19 Average Lengths: 19.0 TOP TLD: com(1) ``` This helps users quickly determine whether the IP is associated with a small, focused set of domains or a large, diverse hosting footprint. --- ## 🌐 Domains Table The **Domains** table displays the domains associated with the queried IP. Typical columns include:
ColumnDescription
\#Row number
DomainDomain name observed on the IP
TLDTop-level domain
LengthDomain length
Example safe table format:
\#DomainTLDLength
1example-host.example.comcom24
The table is designed for filtering, review, pagination, and export. --- ## 🏷️ TLD Statistics Reverse IP Lookup calculates TLD distribution from returned domains. Example: ```text TOP TLD: com(1) ``` The TLD is calculated based on the last segment of the domain. Examples:
DomainCalculated TLD
`example.com``com`
`test.org``org`
`site.co.uk``uk`
`portal.net``net`
TLD distribution helps analysts quickly understand the profile of domains on an IP. For example: - Many `.com` domains may indicate commercial hosting. - Many country-code TLDs may indicate regional infrastructure. - Many unusual TLDs may require closer review. - Mixed TLDs may indicate shared hosting, parking, CDN usage, or multi-customer infrastructure. --- ## 📏 Domain Length Metrics The tool calculates maximum and average domain length. Fields: - Maximum Lengths - Average Lengths Long domains may be useful signals during investigation. Possible interpretations of unusually long domains: - Generated domains - Tracking domains - Parked domains - Temporary infrastructure - Phishing kits - Campaign-specific infrastructure - Randomized hostnames - Bulk-created domains Important: long domain length alone does not prove malicious activity. It is a triage signal that should be reviewed with additional context. --- ## 🔎 Filtering and Search The interface includes filtering tools to make large result sets easier to analyze. Users can filter by: - Domain text - TLD - Visible table rows - Page size Example use cases: - Show only `.com` domains - Search for a brand name - Search for a specific keyword - Review only suspicious-looking domains - Separate regional TLDs - Find domains with shared naming patterns Filtering is especially useful when an IP has many associated domains. --- ## 📄 Pagination Reverse IP Lookup supports pagination for large result sets. The user can control how many rows are shown per page. Example: ```text 25 ``` Pagination helps keep the interface fast and readable when many domains are returned. For very large responses, the number of domains may be truncated during the audit. Users should use TLD filtering and export options for deeper analysis. --- ## 📤 Export The tool supports export for further analysis. Export is useful for: - Bulk verification - Domain reputation checks - Threat intelligence enrichment - Spreadsheet analysis - SOC case documentation - Incident response reports - Passive DNS comparison - Brand abuse monitoring - Infrastructure mapping Exported data may include: - Domain - TLD - Length - IP - Summary metadata Exported results should be stored securely when they are used in investigations. --- ## 🧾 Raw JSON Reverse IP Lookup can expose raw JSON output. Raw JSON may include: - Queried IP - Domain list - TLD statistics - Counts - Length metrics - Backend metadata - Response status - Timestamp Raw JSON is useful for: - Technical diagnostics - API-style workflows - Evidence preservation - SOC automation - Case management - Comparing normalized and raw output - Internal reporting Raw JSON should be handled carefully when it contains sensitive investigation context. --- ## 🕓 Request History The tool stores IP lookup history locally in the user’s browser. Important behavior: ```text History is stored in the user's browser. ``` History may include: - Queried IP - Timestamp - Result count - Summary data - Search mode Local history is useful for repeating checks and reviewing previous analysis. Because it is stored locally, it may be cleared when the user deletes browser data, switches devices, or uses another browser profile. On shared devices, users should clear local history when IP investigations are sensitive. --- ## 🧠 Key Features ### Passive Reverse IP Lookup Finds domains observed resolving to the same IP address. ### IPv4 and IPv6 Support Supports both IPv4 and IPv6 inputs. ### Domain List Displays associated domains in a structured table. ### TLD Statistics Calculates unique TLD count and top TLD distribution. ### Domain Length Metrics Shows maximum and average domain length. ### Filtering and Search Allows filtering by domain text and TLD. ### Pagination Supports large result sets through paginated display. ### Export Allows results to be exported for further analysis. ### Raw JSON Provides structured technical output for advanced users. ### Local History Stores IP lookup history locally in the browser. --- ## 🔍 Common Use Cases Reverse IP Lookup supports many cybersecurity and OSINT workflows. ### Shared Hosting Analysis Identify domains hosted on the same IP address. ### Threat Intelligence Find related domains connected to suspicious infrastructure. ### Incident Response Check whether a malicious IP hosts other domains that may be part of the same campaign. ### Brand Protection Search for domains on suspicious hosting infrastructure that may imitate a brand. ### Phishing Investigation Identify clusters of domains hosted on the same IP. ### Infrastructure Mapping Understand which domains are connected to an owned or third-party IP. ### Asset Discovery Find forgotten or related domains pointing to company infrastructure. ### Fraud Investigation Identify domains linked to suspicious hosting or repeated abuse patterns. ### Malware Infrastructure Review Check whether C2, landing, or payload domains share the same IP. ### Compliance and Audit Document domain exposure associated with organizational IPs. --- ## 🧠 Result Interpretation Reverse IP data should be interpreted carefully. Important notes: - Domain associations may be historical. - A domain resolving to an IP does not prove ownership of that IP. - Shared hosting can contain many unrelated domains. - CDN and proxy infrastructure may show domains from many customers. - Passive DNS records may be outdated. - Some domains may no longer resolve to the IP. - A small result set does not mean the IP hosts only those domains. - A large result set does not automatically mean malicious activity. - TLD distribution is a profile signal, not a verdict. - Long domains are often worth reviewing but are not proof of abuse. Reverse IP Lookup should be used as an intelligence enrichment tool and correlated with DNS, WHOIS, TLS, HTTP, crawler, and reputation data. --- ## 🚨 Server Errors and Truncated Data The tool notes that the number of domains may be truncated during the audit. This means returned results may represent only part of the full available dataset. If a server error occurs, such as a `500` response, users should repeat the request. Recommended handling: - Retry after a short delay. - Use TLD filters to reduce result size. - Export visible results for offline analysis. - Compare with other NiamonX tools. - Do not assume a failed response means no domains exist. --- ## ✅ Recommended Analyst Workflow A practical reverse IP investigation should follow these steps. ### 1. Enter a Clean IP Address Use only an IPv4 or IPv6 address. ### 2. Review the Summary Check total domains, unique TLDs, maximum length, average length, and top TLDs. ### 3. Inspect the Domain Table Review domain names and look for obvious patterns. ### 4. Use Search and TLD Filters Filter by suspicious terms, brand names, TLDs, or naming structures. ### 5. Review Long Domains Long or unusual domains may indicate generated, parked, or campaign-style infrastructure. ### 6. Export Results Use export for bulk verification or deeper investigation. ### 7. Correlate With Other Tools Check interesting domains with DNS, GeoDNS, WHOIS, TLS, IP intelligence, web fingerprinting, or reputation tools. ### 8. Validate Current Resolution Confirm whether selected domains still resolve to the IP. ### 9. Preserve Evidence Save relevant records and timestamps for reports or incident cases. ### 10. Avoid Overclaiming Treat associations as leads until confirmed by additional evidence. --- ## 🛡️ Security, Privacy & Responsible Use Reverse IP Lookup is intended for lawful cybersecurity, OSINT, infrastructure analysis, incident response, and defensive research. Acceptable use cases include: - Checking your own IP infrastructure - Investigating suspicious IPs - Mapping domains on shared infrastructure - Enriching threat intelligence - Supporting SOC triage - Reviewing phishing or malware infrastructure - Discovering exposed company assets - Brand protection - Compliance documentation - Research and reporting Users should follow responsible use rules: - Do not use results to attack hosted domains. - Do not harass domain owners or hosting providers. - Do not assume all domains on an IP are related. - Do not treat passive DNS as current truth without validation. - Do not use the tool for unauthorized access, abuse, phishing, or exploitation. - Validate findings before operational, legal, or public reporting. - Treat exported results as sensitive investigation data. --- ## ⚙️ Technical Highlights - Passive Reverse IP lookup tool - Available at `dash.niamonx.io/ripip` - Searches for domains associated with an IP address - Supports IPv4 - Supports IPv6 - Uses reverse DNS / passive intelligence sources - Summary with domain count - Unique TLD count - Top TLD distribution - Maximum domain length - Average domain length - Domain table - TLD filter - Text search - Pagination - Export support - Raw JSON support - LocalStorage IP history - Handles potentially truncated responses - Retry recommended on server-side 500 errors - Suitable for SOC, OSINT, threat intelligence, incident response, fraud analysis, and infrastructure mapping --- ## 📌 Usage Hints - Enter only an IPv4 or IPv6 address. - Use the TLD filter for large result sets. - Use search to find brand names, suspicious keywords, or patterns. - Long domains are often generated, parked, or campaign-related, but require validation. - TLD distribution helps quickly understand the domain profile. - Export results for later mass verification. - Validate whether domains currently resolve to the IP. - Use Raw JSON for technical workflows. - Retry the request if a server-side 500 error occurs. - Remember that passive data can be historical or incomplete. - History is stored locally in the browser. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX Reverse IP Lookup** is a passive reverse IP intelligence tool that identifies domains observed resolving to the same IPv4 or IPv6 address. It provides domain counts, unique TLD statistics, top TLD distribution, domain length metrics, filtering, search, pagination, export, Raw JSON, and local browser history. The tool is designed for lawful OSINT, SOC triage, threat intelligence enrichment, phishing investigation, malware infrastructure analysis, asset discovery, brand protection, and infrastructure mapping. Results should be treated as passive intelligence leads and validated before conclusions or action. # ASN Information | Autonomous System Intelligence [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/oQPK72BqkmtsV1b5-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/oQPK72BqkmtsV1b5-image.png) The platform available at **[https://dash.niamonx.io/asnchecked](https://dash.niamonx.io/asnchecked)** — known as **ASN Information** — is an autonomous system intelligence tool within the NiamonX platform. It allows users to check detailed public information about an Autonomous System Number, including organization profile, country, routing scope, traffic category, IPv4 and IPv6 prefix counts, contact information, abuse contacts, RIR status, owner address, policies, website, and raw ASN metadata. ## Overview of the Service **ASN Information** is designed to help analysts, network engineers, SOC teams, infrastructure owners, cybersecurity researchers, and OSINT specialists quickly understand the public profile of an Autonomous System. An Autonomous System, or AS, is a network or group of networks operated under a single routing policy on the Internet. Each AS is identified by an ASN, such as: ```text AS13335 ``` or: ```text 47215 ``` The tool accepts ASN values with or without the `AS` prefix and returns a structured report containing routing, ownership, policy, contact, traffic, and organization information. ASN Information is useful for network attribution, abuse reporting, infrastructure mapping, threat intelligence enrichment, routing analysis, vendor review, hosting-provider identification, and incident response. --- ## 🔍 How the Tool Works When a user enters an ASN, the tool queries public and internal intelligence sources and returns the available ASN profile. The result may include: - ASN number - Organization name - Country code - Traffic ratio - Traffic volume category - Network type - IPv4 prefix count - IPv6 prefix count - Routing scope - RIR status - Last updated date - Abuse contacts - General email contacts - Website - Owner address - Peering policy - IRR AS-SET - Route server information - Looking glass information - Social media or website links - Associated prefixes - Raw JSON Data may be aggregated from public routing, RIR, IANA, peering, WHOIS, and organization sources. Because ASN data can come from multiple public datasets, it should be treated as intelligence context and validated before critical decisions. --- ## 🧩 What Can Be Checked ASN Information accepts Autonomous System Numbers. Supported input examples: ```text AS47215 ``` ```text 47215 ``` The `AS` prefix is optional. Unsupported input examples: ```text example.com ``` ```text 1.1.1.1 ``` ```text https://example.com ``` ```text AS47215/example ``` For IP addresses, domains, ports, or service-level intelligence, users should use the relevant NiamonX IP or DNS modules. --- ## ⚙️ Interface Structure The ASN Information interface contains several main areas. ### ASN Input The user enters an Autonomous System Number. Example: ```text AS47215 ``` The tool normalizes the value and performs the lookup. ### History ASN The interface includes ASN history stored locally in the browser. This allows users to quickly repeat previous ASN checks. ### Summary The summary card shows the most important ASN profile fields. ### ASN Info The ASN Info section displays technical routing, policy, and network metadata. ### Organization The Organization section displays owner-related information such as name, address, country, website, and public organization metadata. ### Prefixes The Prefixes section lists IPv4 and IPv6 ranges associated with the ASN when available. ### Raw JSON Raw JSON provides the structured technical response for advanced analysis and integrations. --- ## 📊 Summary Section The summary section gives a fast overview of the ASN. Typical fields include:
FieldDescription
ASNAutonomous System Number
NameOrganization or network name
CountryCountry code associated with the ASN
Traffic ratioEstimated traffic direction profile
Abuse contactsNumber of abuse contact emails
Email contactsNumber of general public email contacts
Owner address linesNumber of owner address lines available
UpdatedLast profile update timestamp
WebsiteOfficial website, if available
DescriptionShort organization or ASN description
Example summary format: ```text ASN: AS47215 Name: Example Network GmbH Country: DE Traffic ratio: Mostly Outbound Abuse contacts: 0 Email contacts: 0 Updated: 2024-06-26 04:47:55 Website: https://example.com/ ``` This section is useful for quick triage before reviewing the full technical profile. --- ## 🏢 Organization Information The Organization section displays the entity associated with the ASN. Possible fields include:
FieldDescription
NameOrganization name
Name longExtended organization name, if available
AKAAlternative names
AddressOwner address lines
CityOrganization city
StateState or region
ZipcodePostal code
CountryCountry code
WebsiteOrganization website
Social mediaPublic organization links
NotesAdditional public notes
StatusOrganization status
The owner address can help analysts understand the legal or operational entity behind the ASN. However, organization address data may be incomplete, outdated, or formatted differently depending on the source. --- ## 🌐 ASN Info Section The ASN Info section contains technical and routing-related metadata. Possible fields include:
FieldDescription
`info_ipv6`Whether IPv6 information is available
`info_multicast`Whether multicast is indicated
`info_unicast`Whether unicast routing is indicated
`info_prefixes4`Number of IPv4 prefixes
`info_prefixes6`Number of IPv6 prefixes
`info_ratio`Traffic direction category
`info_scope`Geographic or routing scope
`info_traffic`Approximate traffic category
`info_types`Network type labels
`irr_as_set`IRR AS-SET value
`policy_general`General peering policy
`policy_locations`Peering location requirement
`policy_contracts`Contract requirement
`policy_ratio`Ratio policy indicator
`policy_url`Policy URL, if available
`rir_status`RIR status
`rir_status_updated`Last RIR status update
`route_server`Route server information
`looking_glass`Looking glass URL, if available
`website`Website URL
This information helps users understand how the ASN participates in Internet routing, peering, traffic exchange, and prefix advertisement. --- ## 🛣️ Prefixes The Prefixes section lists network ranges associated with the ASN. Example format: ```text 109.75.176.0/20 141.101.32.0/21 185.13.210.0/23 185.134.240.0/24 ``` Prefixes are useful for: - Network attribution - Firewall rules - Threat intelligence enrichment - Asset mapping - Provider analysis - Routing review - Incident response - Abuse reporting - Infrastructure monitoring Important: prefix lists can change over time. Always validate current route announcements with routing tools, RIR data, or BGP sources when making operational decisions. --- ## 📡 IPv4 and IPv6 Support Indicators ASN Information may show whether IPv4 and IPv6 routing data is available. Example fields: ```text info_prefixes4: 30 info_prefixes6: 5 info_ipv6: true ``` ### IPv4 Prefix Count Shows how many IPv4 prefixes are associated with the ASN in the returned profile. ### IPv6 Prefix Count Shows how many IPv6 prefixes are associated with the ASN in the returned profile. ### IPv6 Indicator Shows whether the ASN has IPv6-related information or support in the returned dataset. These fields are useful for understanding the network’s routing footprint and protocol support. --- ## 📈 Traffic Ratio The `traffic_ratio` or `info_ratio` field describes the estimated direction of network traffic. Example: ```text Mostly Outbound ``` Possible categories may include: - Mostly Outbound - Mostly Inbound - Balanced - Heavy Outbound - Heavy Inbound - Unknown This value is an assessment and should be treated as a routing or peering profile indicator, not as a precise measurement. ### Interpretation A **Mostly Outbound** network may primarily send more traffic than it receives. This can be common for hosting providers, content providers, certain infrastructure operators, or networks serving outbound-heavy workloads. A **Mostly Inbound** network may receive more traffic, which can be common for access networks, eyeball networks, or consumer ISPs. --- ## 🌍 Scope and Traffic Category The tool may show routing scope and traffic volume category. Example fields: ```text info_scope: Europe info_traffic: 1-5Gbps ``` ### Scope Indicates the likely geographic or operational scope of the network. Examples: - Europe - North America - Global - Regional - Unknown ### Traffic Category Shows approximate traffic volume category. Examples: - 100Mbps-1Gbps - 1-5Gbps - 5-10Gbps - 10-20Gbps - 20Gbps+ - Unknown These fields are estimates and should not be interpreted as guaranteed real-time bandwidth measurements. --- ## 🧾 Contacts ASN Information may display contact counts and contact-related fields. Important contact types:
Contact TypeDescription
Abuse contactsEmail addresses for abuse reporting
Email contactsGeneral public contact emails
Contact exportExportable contact information when available
### Abuse Contacts `abuse_contacts` are used to report abuse such as spam, phishing, malware, scanning, botnet traffic, or other malicious activity. Example use cases: - Reporting malicious traffic - Submitting phishing complaints - Notifying a network operator about compromised systems - Escalating security incidents - Abuse desk routing ### Email Contacts `email_contacts` may include additional public email addresses for administrative or technical communication. Contact data may be incomplete or missing depending on the source. --- ## 🏛️ IANA and RIR Data The tool may include IANA and RIR-related fields. Possible data includes: - RIR status - RIR status update date - IANA assignment status - WHOIS-related source fields - `whois_server` when available ### RIR Status The RIR status indicates whether the ASN profile appears valid or active in the returned registry data. Example: ```text rir_status: ok rir_status_updated: 2024-06-26 04:47:55 ``` Regional Internet Registries include organizations such as RIPE NCC, ARIN, APNIC, LACNIC, and AFRINIC. This data is important for attribution, validation, and abuse-reporting workflows. --- ## 🤝 Peering and Routing Policy The ASN profile may include policy-related fields. Possible fields:
FieldDescription
`policy_general`General peering policy
`policy_locations`Peering location requirements
`policy_contracts`Contract requirements
`policy_ratio`Whether traffic ratio is considered in policy
`policy_url`URL to public peering policy
`irr_as_set`IRR AS-SET for routing policy
`route_server`Route server participation
`looking_glass`Looking glass system, if available
Example: ```text policy_general: Open policy_contracts: Not Required irr_as_set: AS-FILOO ``` These fields are useful for peering research, network operations, IX participation analysis, and BGP routing review. --- ## 🔎 IRR AS-SET An **IRR AS-SET** is a routing registry object that groups ASNs or routes for routing policy purposes. Example: ```text AS-FILOO ``` IRR AS-SET values are useful for: - Route filtering - Peering configuration - BGP policy review - Network operations - Prefix validation - Transit and peering analysis IRR data should be validated because registry objects can become outdated. --- ## 🔭 Looking Glass A looking glass is a public network diagnostic tool offered by some network operators. It may allow users to check: - BGP routes - Ping results - Traceroute results - Route server visibility - Peering paths If a looking glass URL is available, the ASN Information tool may show it in the profile. If it is not available, the field may show: ```text — ``` --- ## 🧬 Raw JSON The tool provides Raw JSON for advanced analysis. Raw JSON may include: - ASN profile - Organization data - Prefix list - Contact data - Policy fields - Peering metadata - RIR status - Website and social links - Routing scope - Traffic category - Internal status fields Raw JSON is useful for: - SOC workflows - API-style integrations - Case management - Evidence preservation - Automated enrichment - Network inventory systems - BGP research - Compliance reporting Raw data should be handled carefully when used in investigations or internal reports. --- ## 🕓 ASN History The tool stores ASN lookup history locally in the browser. History entries may include: - ASN value - Organization name - Country - Lookup timestamp - Summary fields Local history helps users repeat previous ASN checks and compare recent lookups. Because it is stored locally, it may be cleared when the user clears browser data, switches devices, or uses a different browser profile. On shared devices, users should clear local history if ASN investigations are sensitive. --- ## 🧠 Key Features ### ASN Lookup Checks Autonomous System information by ASN. ### Optional AS Prefix Accepts ASN values with or without the `AS` prefix. ### Organization Profile Displays organization name, website, address, country, and related fields. ### Country and Scope Shows country code and routing scope. ### Traffic Ratio Displays estimated traffic direction, such as Mostly Outbound. ### Prefix Overview Shows IPv4 and IPv6 prefix counts and prefix lists. ### Contact Parsing Displays abuse contact counts and public email contact counts when available. ### IANA / RIR Data Includes registry status and update timestamps. ### Policy Metadata Shows peering and routing policy fields where available. ### IRR AS-SET Displays routing registry AS-SET information. ### Contact Export Supports contact export when contact data is available. ### Raw JSON Provides structured technical output for advanced workflows. ### ASN History Stores recent ASN checks locally in the browser. --- ## 🔍 Common Use Cases ASN Information can support many technical and security workflows. ### Network Attribution Identify which organization operates an ASN. ### Abuse Reporting Find abuse contacts or organization information for reporting malicious traffic. ### Threat Intelligence Enrich suspicious IPs by mapping them to ASN ownership and prefix ranges. ### SOC Triage Quickly understand whether an alert involves hosting, access, cloud, or network service provider infrastructure. ### BGP and Routing Research Review prefixes, AS-SET, scope, policy, and traffic ratio. ### Vendor and Provider Review Understand network providers, hosting companies, and traffic profiles. ### Infrastructure Mapping Identify IP ranges associated with an organization. ### Compliance and Risk Review Document ASN ownership and routing metadata for audit workflows. ### Incident Response Determine who to contact and which prefixes may be related to an incident. --- ## ⚠️ Result Interpretation Notes ASN data should be interpreted carefully. Important points: - Public ASN data may be incomplete. - Contact fields may be missing or outdated. - Prefix lists may change over time. - Traffic categories are estimates. - RIR status does not guarantee current operational behavior. - WHOIS and registry data may differ from real-world operations. - ASNs can be used by hosting providers, enterprises, ISPs, CDNs, or transit networks. - A malicious IP inside an ASN does not mean the ASN owner is malicious. - Abuse contacts may be absent even for active networks. - Always validate important findings with live BGP, WHOIS, RIR, and provider sources. If a server-side `500` error occurs during lookup, repeat the request. --- ## ✅ Recommended Analyst Workflow A practical ASN investigation should follow these steps. ### 1. Enter the ASN Use either `AS47215` or `47215`. ### 2. Review the Summary Check organization name, country, traffic ratio, contacts, update date, and website. ### 3. Check Contact Data Look for abuse contacts and public email contacts. ### 4. Review Organization Details Check address, country, website, and status. ### 5. Review ASN Info Inspect IPv4 / IPv6 support, prefix counts, traffic category, routing scope, network type, and policy fields. ### 6. Review Prefixes Use prefix lists for mapping, filtering, or threat intelligence enrichment. ### 7. Check RIR Status Review registry status and update timestamp. ### 8. Use Raw JSON Open Raw JSON for deeper technical workflows or export. ### 9. Correlate With Other Tools Use IP lookup, reverse IP, DNS, BGP, WHOIS, and vulnerability tools for deeper analysis. ### 10. Validate Before Action Confirm important conclusions before contacting providers, blocking ranges, or publishing reports. --- ## 🛡️ Security, Privacy & Responsible Use ASN Information is intended for lawful network intelligence, security analysis, routing research, abuse reporting, and infrastructure review. Acceptable use cases include: - Checking public ASN information - Identifying network ownership - Enriching IP intelligence - Finding abuse contacts - Reviewing prefixes - Supporting SOC triage - Investigating suspicious infrastructure - Researching routing policies - Documenting provider information - Supporting compliance and incident response Users should follow responsible use principles: - Do not harass network operators. - Do not assume an ASN owner is responsible for every hosted customer action. - Do not block large ASN ranges without careful validation. - Do not publish inaccurate attribution based on incomplete data. - Validate abuse contacts before escalation. - Treat exported data as investigation material. - Use the tool only for lawful and ethical analysis. --- ## ⚙️ Technical Highlights - ASN lookup tool - Available at `dash.niamonx.io/asnchecked` - Accepts ASN with or without `AS` prefix - Displays organization profile - Shows country code - Shows traffic ratio - Shows traffic category - Shows network scope - Shows network type labels - Displays IPv4 prefix count - Displays IPv6 prefix count - Lists associated prefixes - Parses abuse contacts - Parses public email contacts - Includes IANA / RIR data - Shows RIR status and update date - Displays owner address - Shows website and social links - Shows peering policy fields - Shows IRR AS-SET - Shows route server and looking glass fields when available - Supports contact export - Supports Raw JSON - Stores ASN history locally - Suitable for SOC, OSINT, routing research, abuse reporting, threat intelligence, and infrastructure mapping --- ## 📌 Usage Hints - The `AS` prefix is optional. - Use ASN lookup after identifying an IP’s ASN in IP intelligence tools. - Check `traffic_ratio` to understand traffic direction profile. - Use `abuse_contacts` for abuse reports when available. - Use `email_contacts` for additional public contacts. - Check `date_updated` or RIR update fields to understand profile freshness. - Use `whois_server` when available for updated WHOIS queries. - Review prefixes before creating firewall or monitoring rules. - Validate prefix lists with live BGP when accuracy is critical. - Use Raw JSON for deeper analysis and integrations. - If a server-side `500` error occurs, repeat the request. - Remember that public ASN data may be incomplete. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX ASN Information** is an autonomous system intelligence tool for checking public ASN profile data, organization information, routing scope, traffic ratio, prefix lists, abuse contacts, RIR status, peering policy, website, owner address, and Raw JSON. It is designed for lawful network intelligence, SOC triage, OSINT enrichment, abuse reporting, routing research, infrastructure mapping, compliance, and incident response. Data may be aggregated from public sources and should be validated before critical operational or legal decisions. # Website and Host Analysis Website and Host Analysis # Phishing Check | URL Threat Inspection [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/KbqScEr3FtckWSKm-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/KbqScEr3FtckWSKm-image.png) The platform available at **[https://dash.niamonx.io/phishing\_check](https://dash.niamonx.io/phishing_check)** — known as **Phishing Check** — is a URL threat inspection tool within the NiamonX platform. It checks submitted URLs against known phishing, malware, unwanted software, and social engineering indicators using NiamonX threat intelligence data and Google Safe Browsing signals. ## Overview of the Service **Phishing Check** helps users quickly evaluate whether a URL appears in known threat datasets. The tool is designed for cybersecurity analysts, SOC teams, incident responders, fraud investigators, compliance teams, brand protection specialists, and general users who need to inspect suspicious links before opening, sharing, or escalating them. Phishing Check returns a structured result that includes: - Safety status - Risk score - Risk level - Threat type matches - Platform matches - Match count - Threat URL - Cache information - Metadata availability - Source information - Local browser request history - Raw JSON when needed The tool is informational. A **SAFE** result does not guarantee that the resource is harmless, and an **UNSAFE** result should be validated with additional sources before high-impact decisions. --- ## 🔍 How the Tool Works The user enters a full URL, including protocol. Example: ```text https://example.com/ ``` or: ```text http://testsafebrowsing.appspot.com/apiv4/ANY_PLATFORM/MALWARE/URL/ ``` The tool checks the URL against threat intelligence sources, including: - NiamonX Database - Google Safe Browsing signals The system then returns a result such as: - SAFE - UNSAFE - Unknown / no matches - Error or unavailable, depending on backend response If matches are found, the tool displays threat type, affected platform, match details, risk score, and cache information. --- ## 🧩 What Can Be Checked Phishing Check accepts full URLs. Supported input format: ```text http://example.com/path ``` ```text https://sub.example.com/login ``` The URL must include: - `http://` - or `https://` Subdomains are taken into account during inspection. Unsupported or invalid inputs: ```text example.com ``` ```text sub.example.com/login ``` ```text 1.1.1.1 ``` ```text just-text ``` For accurate inspection, users should paste the complete URL exactly as received. --- ## ⚙️ Interface Structure The Phishing Check interface contains several main areas. ### URL for Inspection The input field where the user enters the full URL. Example: ```text https://example.com/ ``` The interface reminds users to enter the full URL with `http://` or `https://`. ### Examples of Queries The interface may provide example URLs for testing safe browsing behavior or known test patterns. ### Result Panel The result panel displays: - Safety status - Risk score - Risk level - Match count - Timestamp - Threat types - Platforms - Metadata keys - Detailed coincidences - Cache duration - Source ### Request History The request history stores previous URL checks locally in the browser. --- ## 📊 Result Status The main result status indicates whether the submitted URL matched known threat intelligence data. Common statuses:
StatusMeaning
SAFENo known threat match was found
UNSAFEOne or more threat matches were found
UNKNOWNThe result could not be clearly determined
ERRORThe check failed or backend response was unavailable
Example unsafe result: ```text UNSAFE Risk 40 Elevated Coincidences: 1 ``` Example safe result: ```text SAFE Risk 0 None ``` A safe result should not be interpreted as a guarantee of security. It means the URL did not match the known threat sources used for that check. --- ## 🚦 Risk Score The tool calculates a heuristic risk score based on detected threats. Example: ```text Risk 40 (Elevated) ``` Risk score may consider: - Threat type - Number of matches - Source confidence - Platform type - Metadata indicators - Threat weight - Known malicious classification Example interpretation:
Risk LevelMeaning
NoneNo known threat match
LowWeak or limited indicators
ElevatedKnown threat match or moderate risk
HighStrong threat evidence
CriticalSevere or multiple high-confidence indicators
The exact score is calculated by the platform’s internal heuristic logic. --- ## 🧬 Threat Types The **Types of Threats** section lists the threat categories found for the URL. Possible threat types may include: - MALWARE - SOCIAL\_ENGINEERING - PHISHING - UNWANTED\_SOFTWARE - POTENTIALLY\_HARMFUL\_APPLICATION - SUSPICIOUS - Other backend-supported categories Example: ```text Types of Threats MALWARE ``` Threat type helps analysts understand the nature of the risk. ### Malware The URL may be associated with malware delivery, payload hosting, infection chains, or malicious downloads. ### Social Engineering / Phishing The URL may be associated with credential theft, impersonation, fake login pages, payment fraud, or deceptive content. ### Potentially Harmful Application The URL may be associated with harmful applications or mobile threats. --- ## 🖥️ Platform Types The **Platforms** section shows which platform category the threat applies to. Example: ```text ANY_PLATFORM ``` Possible platform values may include: - ANY\_PLATFORM - WINDOWS - LINUX - OSX - ANDROID - IOS - CHROME - Other backend-supported platform categories `ANY_PLATFORM` means the threat is not limited to a specific operating system or device type. --- ## 🎯 Coincidences / Matches The **Coincidences** section displays detailed matches returned by the threat intelligence check. A match may include:
FieldDescription
Threat typeMalware, phishing, social engineering, or other category
PlatformAffected platform category
Entry typeURL or other supported indicator type
Threat URLURL that matched threat intelligence
MetadataAdditional threat details, if available
CacheCache duration, when returned
Example match: ```text Threat Type: Malware Platform: ANY_PLATFORM Entry Type: URL Threat URL: http://example.test/malware/ ``` The match details help analysts understand exactly what triggered the unsafe classification. --- ## 🧾 Metadata The metadata section indicates whether additional metadata was returned. Example: ```text Metadata: No ``` When metadata is available, it may contain additional context such as: - Threat labels - Provider-specific attributes - Match properties - Threat confidence - Campaign indicators - Source-specific fields Metadata availability depends on the backend source and threat type. --- ## 🕒 Cache The tool may show cache duration for the result. Example: ```text Cache: 300s ``` Cache duration means the result may be reused for a short period to reduce repeated lookups and improve performance. Important notes: - Cached results may not reflect the very latest reputation state. - A URL’s reputation can change quickly. - Repeat checks may use cached data until the cache expires. - Cache duration may be absent in some responses. --- ## 🧾 Raw JSON The tool can provide Raw JSON when needed. Raw JSON may include: - Result status - Risk score - Risk level - Threat matches - Threat type - Platform type - Metadata fields - Cache duration - Source indicators - Backend response details Raw JSON is useful for: - SOC workflows - Case management - Automation - Evidence preservation - Incident response - Threat intelligence pipelines - Internal reporting Raw output should be handled carefully when it contains suspicious URLs, investigation notes, or threat indicators. --- ## 🕓 Request History Phishing Check stores URL check history locally in the browser. History entries may include: - URL - Safety status - Risk score - Risk level - Timestamp Example history item: ```text https://example.com/ SAFE Risk 0 None ``` Important privacy behavior: ```text History does not go to the server. ``` Local history is useful for repeating checks and reviewing past inspections. Because the history is browser-local, it may be cleared when users delete browser data or switch devices. On shared devices, users should clear local history when checked URLs are sensitive. --- ## 🧠 Key Features ### URL Threat Check Checks full URLs against known threat indicators. ### NiamonX Database Uses NiamonX threat intelligence data. ### Google Safe Browsing Signals Uses Google Safe Browsing-style threat classifications. ### Status and Risk Shows SAFE / UNSAFE status, risk score, and risk level. ### Detailed Matches Displays threat type, platform type, entry type, and matched threat URL. ### Aggregations Shows threat type and platform aggregations. ### Cache Awareness Displays cache duration when available. ### Metadata Support Shows metadata when returned by the backend. ### Local History Stores previous URL checks locally in the browser. ### Raw JSON Provides structured technical data for advanced review. ### Summary Copy Allows copying a brief report for sharing or documentation. --- ## 🔎 Common Use Cases Phishing Check can support many defensive workflows. ### Suspicious Link Review Check a URL before opening it. ### SOC Triage Inspect URLs from alerts, emails, chat messages, endpoint logs, or proxy logs. ### Phishing Investigation Confirm whether a URL is associated with social engineering or credential theft. ### Malware URL Review Check whether a link is associated with malware delivery. ### User Report Validation Analyze URLs reported by employees or customers. ### Brand Protection Check suspicious domains or URLs impersonating a company. ### Incident Response Document known malicious URLs during security incidents. ### Email Security Review Inspect links extracted from suspicious messages. ### Threat Intelligence Enrichment Add URL reputation information to internal cases or watchlists. --- ## ⚠️ Result Interpretation Phishing Check results should be interpreted carefully. Important points: - Absence of matches does not guarantee that a URL is safe. - New phishing pages may not yet appear in threat databases. - A safe result may become unsafe later. - An unsafe result should be validated if it will be used for legal, HR, or customer-facing action. - URL reputation can vary by path, subdomain, and query string. - Subdomains are taken into account. - Shortened links should be expanded and checked carefully. - Cache may temporarily return a previous result. - Some malicious pages show different content by region, device, browser, or time. - A URL may redirect after inspection. For high-risk cases, combine Phishing Check with sandbox analysis, DNS review, WHOIS, certificate inspection, HTTP header review, screenshot analysis, and endpoint telemetry. --- ## ✅ Recommended Analyst Workflow A practical phishing review workflow should follow these steps. ### 1. Copy the Full URL Include the full `http://` or `https://` URL exactly as received. ### 2. Run the Check Submit the URL for inspection. ### 3. Review Status Check whether the result is SAFE or UNSAFE. ### 4. Review Risk Score Use risk score and level for triage. ### 5. Check Threat Types Identify whether the match is malware, phishing, social engineering, or another category. ### 6. Review Platform Types Check whether the threat is platform-specific or applies to any platform. ### 7. Inspect Coincidences Review detailed match objects and threat URL. ### 8. Copy Summary Use the summary copy function for tickets or incident reports. ### 9. Use Raw JSON When Needed Open Raw JSON for automation, evidence, or deeper analysis. ### 10. Validate With Additional Sources Use multiple security sources before making final decisions. --- ## 🛡️ Security, Privacy & Responsible Use Phishing Check is intended for lawful cybersecurity, fraud prevention, incident response, and URL safety analysis. Acceptable use cases include: - Checking suspicious URLs - Investigating phishing reports - SOC alert triage - Malware link review - Email security analysis - Brand protection - Threat intelligence enrichment - Incident documentation - User safety checks Users should follow responsible use rules: - Do not open suspicious URLs directly in a normal browser. - Do not submit private tokens, session URLs, or sensitive internal links unless authorized. - Do not use results as the only source for high-impact decisions. - Do not weaponize threat data for phishing, malware distribution, or social engineering. - Validate malicious classifications before public reporting. - Treat URL history as potentially sensitive on shared devices. - Use safe environments when investigating live malicious content. --- ## ⚙️ Technical Highlights - URL threat inspection tool - Available at `dash.niamonx.io/phishing_check` - Requires full URL with `http://` or `https://` - Subdomains are taken into account - Uses NiamonX Database - Uses Google Safe Browsing signals - Detects known threats such as phishing, malware, social engineering, and PHA - Displays SAFE / UNSAFE status - Calculates heuristic risk score - Displays risk level - Shows threat type aggregation - Shows platform aggregation - Shows detailed match objects - Shows matched threat URL - Shows cache duration when available - Shows metadata when available - Supports Raw JSON - Supports brief summary copying - Stores request history locally in browser - History is not sent to server - Suitable for SOC triage, phishing investigation, malware URL review, and threat intelligence workflows --- ## 📌 Usage Hints - Enter the full URL with `http://` or `https://`. - Include the exact suspicious path when possible. - Subdomains are included in the inspection. - Risk is calculated heuristically based on threats. - `matches` may include `threatType`, `platformType`, and metadata. - `CacheDuration` may be absent. - A SAFE result does not guarantee that the resource is safe. - Use additional sources for final decisions. - Use summary copy for quick reports. - Use Raw JSON for technical workflows. - Local history stays in the browser and is not sent to the server. - Avoid opening suspicious URLs outside a safe environment. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX Phishing Check** is a URL threat inspection tool that checks full URLs against NiamonX Database and Google Safe Browsing signals. It returns SAFE / UNSAFE status, heuristic risk score, risk level, threat types, platform types, detailed matches, cache information, metadata, local history, summary copy, and Raw JSON. The tool is designed for phishing investigation, malware URL review, SOC triage, brand protection, incident response, email security analysis, and threat intelligence enrichment. Results are informational and should be validated with additional sources before final decisions. # Host Diagnostics | Multi-Protocol Network Diagnostic Tool [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/POxH3BMemDiioI7a-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/POxH3BMemDiioI7a-image.png) The platform available at **[https://dash.niamonx.io/host\_diagnostics](https://dash.niamonx.io/host_diagnostics)** — known as **Host Diagnostics** — is a combined network diagnostic tool within the NiamonX platform. It allows users to check a host, IP address, or domain across multiple network layers using Ping, HTTP, TCP, DNS, and UDP diagnostics from distributed public nodes. ## Overview of the Service **Host Diagnostics** is designed to provide a structured, multi-protocol view of host availability and network behavior. Unlike a single ping or DNS lookup, this tool performs several types of checks in one workflow. It can verify whether a target responds to ICMP-style ping checks, whether HTTP is reachable, whether TCP connectivity works, whether DNS resolution is available, and whether UDP responses are received from selected diagnostic nodes. The tool is useful for: - Network troubleshooting - Website availability checks - Infrastructure diagnostics - SOC and incident response workflows - DevOps and uptime analysis - DNS and routing validation - Regional connectivity review - Firewall and filtering checks - Basic service reachability testing - External monitoring from multiple nodes The data depends on public diagnostic nodes used by the service. Results should be treated as network diagnostics and validated with additional tools for critical infrastructure decisions. --- ## 🔍 How the Tool Works The user enters a target host, IP address, or domain and selects one or more diagnostic check types. Supported target types: - IPv4 address - IPv6 address - Domain name - Hostname Supported check types: - Ping - HTTP - TCP - DNS - UDP At least one check type must be enabled. The user can also define how many diagnostic nodes should be used and optionally specify node names manually. After the request is submitted, the backend starts one or more diagnostic jobs. Each selected check type receives its own request ID and progresses independently until it reaches a final state such as complete, partial, failed, or timeout. The final result is displayed as a combined diagnostic report with aggregated metrics and detailed node tables. --- ## 🧩 What Can Be Checked Host Diagnostics supports three main categories of targets. ### IPv4 Address Example: ```text 1.1.1.1 ``` ### IPv6 Address Example: ```text 2606:4700:4700::1111 ``` ### Domain or Hostname Example: ```text niamonx.io ``` ```text api.example.com ``` The tool should not be used with full URLs, paths, or query strings unless a specific check type supports that behavior. For best results, users should enter only the clean host, IP, or domain. --- ## ⚙️ Diagnostic Interface The interface includes several key controls. ### Host / IP The main input field where the user enters the target. Example: ```text 1.1.1.1 ``` Supported formats: - IPv4 - IPv6 - Domain - Hostname ### Types of Checks Users can enable or disable diagnostic types by clicking the corresponding buttons. Available checks: - Ping - HTTP - TCP - DNS - UDP At least one type must remain selected. ### Max Nodes Controls how many nodes should be used for each check. Example: ```text Max nodes: 3 ``` Using more nodes provides broader geographic visibility but may increase processing time. ### Nodes Optional Users can optionally specify node names manually. Example format: ```text ua1.node,us1.node ``` Up to 20 node names may be entered as a comma-separated list, depending on backend limits. If the field is empty, the system selects nodes automatically. ### Initial Survey Cycles Controls whether the request should return immediately with a request ID or wait briefly for partial or full readiness. Example: ```text Initial survey cycles: 1 ``` Interpretation:
ValueMeaning
0Return request ID immediately
1–8Wait for polling until partial or full readiness
This option can make the first response more useful by allowing the backend to collect initial data before returning results. --- ## 📊 Combined Diagnostics Status The main diagnostics panel displays the global status of the selected checks. Example: ```text Diagnostics COMPLETE Updated: 22:25:28 ``` Possible status values may include:
StatusMeaning
COMPLETEAll selected checks reached a final completed state
PARTIALSome checks or nodes returned results, while others did not
RUNNINGChecks are still in progress
FAILEDThe diagnostic job failed
TIMEOUTThe check did not complete within the expected time
ERRORBackend or parsing error occurred
A complete status means the requested checks finished, not necessarily that every service responded successfully. --- ## 🛰️ Node-Based Diagnostics Host Diagnostics uses external nodes to test the target from different network locations. Each node may return different results because of: - Geographic routing - Firewall rules - DNS differences - CDN behavior - Anycast behavior - Regional filtering - Network congestion - Provider outages - IPv4 / IPv6 availability - Target-side rate limiting Node-based diagnostics are especially useful when a host works from one region but fails from another. --- ## 📡 Ping Check The **Ping** check measures basic network reachability and latency. Example summary: ```text PING: nodes=3 avg/min/max=252.56/1.60/3000.34 ms samples=12 ``` The Ping section may include: - Request ID - Number of nodes - Average RTT - Minimum RTT - Maximum RTT - Number of samples - Per-node average latency Example table:
NodeSamplesAvg ms
br1.node.check-host.net4751.31
hk1.node.check-host.net42.45
nl2.node.check-host.net43.93
### Ping Interpretation Ping is useful for checking: - Basic availability - Network latency - Packet-level reachability - Regional routing differences - Possible filtering or packet loss High ping values may indicate long-distance routing, congestion, packet loss, or regional network problems. A failed ping does not always mean the host is down. Some hosts block ICMP-style traffic while still serving HTTP, TCP, or DNS normally. --- ## 🌐 HTTP Check The **HTTP** check verifies whether the target responds over HTTP or HTTPS-style web checks, depending on backend behavior. Example summary: ```text HTTP: nodes=3 codes=301 t(avg/min/max)=0.124/0.040/0.170s ``` The HTTP section may include: - Request ID - HTTP status codes - Average response time - Minimum response time - Maximum response time - Node-level status - Resolved IP used by the node Example table:
NodeCodeStatusTime sIP
ir5.node.check-host.net301Moved Permanently0.1641.1.1.1
ir7.node.check-host.net301Moved Permanently0.1701.1.1.1
si1.node.check-host.net301Moved Permanently0.0401.1.1.1
### HTTP Interpretation HTTP diagnostics are useful for checking: - Web availability - HTTP status codes - Redirect behavior - Response time - Regional web reachability - Basic CDN or proxy behavior Common HTTP codes:
CodeMeaning
200OK
301Moved Permanently
302Found / temporary redirect
403Forbidden
404Not Found
500Server error
502 / 503 / 504Gateway or service availability problem
A successful HTTP response does not always mean the application is healthy. It only confirms that an HTTP-level response was returned. --- ## 🔌 TCP Check The **TCP** check tests whether a TCP connection can be established. Example summary: ```text TCP: success=3/3 t=0.004/0.001/0.010s ``` The TCP section may include: - Request ID - Number of successful nodes - Total nodes - Average / minimum / maximum connection time - Per-node result - Per-node response time Example table:
NodeStatusTime s
ae1.node.check-host.netOK0.010
es1.node.check-host.netOK0.002
in3.node.check-host.netOK0.001
### TCP Interpretation TCP checks are useful for verifying: - Port-level reachability - Firewall behavior - Regional blocking - Service availability - Connection establishment time - Basic network path health A successful TCP check means the node could establish a connection. It does not necessarily validate the full application protocol. --- ## 🧭 DNS Check The **DNS** check verifies DNS resolution from selected diagnostic nodes. Example summary: ```text DNS: nodes=3 A=0 AAAA=0 TTL(min/max)=1001/1523 ``` The DNS section may include: - Request ID - Number of nodes - A records - AAAA records - TTL values - Per-node DNS results Example table:
NodeAAAAATTL
nl1.node.check-host.net--1523
nl2.node.check-host.net--1509
rs1.node.check-host.net--1001
### DNS Interpretation DNS diagnostics are useful for: - Checking whether a domain resolves globally - Comparing A / AAAA responses by node - Identifying TTL differences - Diagnosing DNS propagation - Detecting resolver-specific failures - Validating CDN or GeoDNS behavior If the target is an IP address rather than a domain, DNS results may be limited or empty depending on backend behavior. --- ## 📦 UDP Check The **UDP** check attempts UDP-level diagnostics from selected nodes. Example summary: ```text UDP: answers=0/3 0.0% timeouts=3 ``` The UDP section may include: - Request ID - Number of answers - Total nodes - Answer percentage - Timeout count - Per-node result Example table:
NodeResult
bg1.node.check-host.netTimeout
pt1.node.check-host.netTimeout
rs1.node.check-host.netTimeout
### UDP Interpretation UDP diagnostics are useful for checking: - UDP responsiveness - Firewall behavior - Timeout patterns - Regional UDP filtering - Service exposure - DNS, VPN, VoIP, gaming, or other UDP-based behavior UDP is connectionless, so timeouts are common and may not always indicate failure. Many services do not respond to generic UDP probes. --- ## 📋 Aggregated Metrics Host Diagnostics provides summaries for each check type. Examples: ```text PING: avg/min/max HTTP: status codes and response time TCP: success rate and connection time DNS: A/AAAA and TTL UDP: answers and timeouts ``` Aggregated metrics help analysts quickly identify which layer is failing. For example: - Ping fails but HTTP works: ICMP may be blocked. - DNS fails but TCP works by IP: DNS problem likely. - HTTP fails but TCP works: application or web-layer issue. - TCP fails from some nodes only: regional filtering or routing issue. - UDP times out everywhere: UDP service may be closed, filtered, or non-responsive. --- ## 🧾 Request IDs Each check type may receive its own request ID. Example: ```text Req: 42298127k877 ``` Request IDs help track individual diagnostic jobs and are useful when polling, debugging, or comparing results. --- ## 🧪 Initial Survey Cycles The **Initial survey cycles** setting controls how quickly the initial response is returned. ### 0 Cycles The tool returns the request ID immediately. This is useful for asynchronous workflows where the user or interface will poll later. ### 1–8 Cycles The tool waits briefly for partial or complete readiness before returning the result. This can speed up the user experience because initial data may already be available when the result appears. --- ## 🧠 Key Features ### Combined Network Diagnostics Runs Ping, HTTP, TCP, DNS, and UDP checks from one interface. ### Flexible Type Selection Users can enable or disable check types as needed. ### Multi-Node Testing Checks can run from several public diagnostic nodes. ### Automatic Node Selection If no nodes are specified, the system selects nodes automatically. ### Manual Node Selection Advanced users can specify node names manually. ### Aggregated Metrics Each check type includes summarized performance and availability data. ### Detailed Node Tables Per-node results show regional differences and diagnostic details. ### Summary Copy The tool can provide a copyable summary for reports or tickets. ### Export Support Diagnostic results can be copied or exported for documentation. ### Local History Previous checks are stored locally in the browser. ### Raw Output Raw data can be used for format debugging and deeper troubleshooting. --- ## 🕓 Request History The **Request History** section stores previous diagnostic checks locally in the browser. History entries may include: - Target host or IP - Selected check types - Result status - Timestamp Example history item: ```text 1.1.1.1 dns,http,ping,tcp,udp OK 17.06.2026, 22:25:28 ``` Possible history statuses:
StatusMeaning
OKDiagnostic completed successfully
PARTPartial result
FAILFailed result
ERRORError occurred
Local history helps repeat previous diagnostics and compare results over time. Because it is stored in the browser, it may be cleared when users delete browser data or switch devices. --- ## 🔧 Raw Output The tool may provide raw output for format debugging. Raw data can help developers and analysts understand: - Backend response structure - Node-level payloads - Timing fields - Status fields - Partial responses - Formatting issues - Parsing behavior Raw output is useful for technical troubleshooting but should not be necessary for normal users. --- ## ✅ Recommended Diagnostic Workflow A practical host diagnostic workflow should follow these steps. ### 1. Enter the Target Use an IPv4 address, IPv6 address, domain, or hostname. ### 2. Select Check Types Enable Ping, HTTP, TCP, DNS, UDP, or only the checks relevant to the issue. ### 3. Set Max Nodes Use 3 nodes for quick checks or more nodes for broader regional diagnostics. ### 4. Specify Nodes If Needed Enter node names manually when testing from specific regions. ### 5. Choose Initial Survey Cycles Use `1` for a balanced interactive result or `0` for immediate request ID return. ### 6. Review Global Status Check whether the overall result is complete, partial, failed, or still running. ### 7. Analyze Each Layer Review Ping, HTTP, TCP, DNS, and UDP independently. ### 8. Compare Nodes Look for regions where one node fails while others succeed. ### 9. Identify the Failing Layer Use differences between protocols to isolate DNS, web, TCP, UDP, or routing problems. ### 10. Copy or Export Results Use summaries for incident tickets, reports, or support communication. --- ## 🔎 Common Use Cases Host Diagnostics can support many technical workflows. ### Website Availability Check Use HTTP and DNS checks to confirm whether a website is reachable. ### Network Reachability Check Use Ping and TCP checks to verify basic connectivity. ### DNS Propagation Review Use DNS checks across nodes to compare A, AAAA, and TTL values. ### Firewall Troubleshooting Compare TCP / UDP / Ping behavior to identify filtering. ### Incident Response Quickly determine whether a target is globally down or regionally affected. ### DevOps Monitoring Use repeated diagnostics to investigate deployment, DNS, or routing issues. ### SOC Triage Check suspicious hosts or infrastructure indicators from multiple layers. ### Regional Connectivity Analysis Use node-level results to identify geographic network problems. --- ## ⚠️ Result Interpretation Notes Host Diagnostics results should be interpreted carefully. Important limitations: - Public nodes may have their own outages or restrictions. - A failed ping does not always mean the service is down. - HTTP checks may follow redirects or return expected non-200 statuses. - TCP success does not prove application health. - DNS results may vary by resolver, cache, or geography. - UDP timeouts are common and not always a failure. - Some targets block diagnostic nodes. - Results can be partial while some checks are still updating. - Different nodes may see different network paths. - Data depends on public nodes of the service. For production incidents, combine Host Diagnostics with server logs, application monitoring, traceroute, firewall logs, DNS provider dashboards, and cloud provider status pages. --- ## 🛡️ Security, Privacy & Responsible Use Host Diagnostics is intended for lawful network diagnostics, troubleshooting, uptime checks, incident response, and infrastructure analysis. Acceptable use cases include: - Checking your own infrastructure - Troubleshooting website downtime - Validating DNS resolution - Testing TCP connectivity - Reviewing UDP reachability - Supporting incident response - Comparing regional network behavior - Preparing support tickets - SOC enrichment of network indicators - DevOps and monitoring workflows Users should follow responsible use principles: - Do not use the tool to harass or overload third-party infrastructure. - Do not repeatedly test systems without a legitimate reason. - Do not interpret diagnostic failures as proof of malicious activity. - Do not rely on one check type for critical conclusions. - Validate important findings with additional sources. - Treat local history as potentially sensitive on shared devices. - Use the tool only for lawful and ethical diagnostics. --- ## ⚙️ Technical Highlights - Combined network diagnostic tool - Available at `dash.niamonx.io/host_diagnostics` - Supports IPv4 - Supports IPv6 - Supports domains and hostnames - Check types: Ping, HTTP, TCP, DNS, UDP - Minimum one check type required - Flexible check type selection - Max nodes control - Optional manual node list - Automatic node selection - Initial survey cycles for faster initial acquisition - Per-check request IDs - Aggregated metrics - Detailed node tables - Ping avg / min / max and samples - HTTP status code, status text, time, and IP - TCP success rate and connection time - DNS A / AAAA and TTL by node - UDP answer rate and timeouts - Combined diagnostics status - Summary copy - Export support - Local browser request history - Raw output for debugging - Suitable for network diagnostics, SOC, DevOps, incident response, and infrastructure monitoring --- ## 📌 Usage Hints - Enter an IPv4 address, IPv6 address, domain, or hostname. - Select at least one check type. - Use Ping for latency and basic reachability. - Use HTTP for web status, response time, and resolved IP. - Use TCP for connection-level availability. - Use DNS for A / AAAA and TTL comparison. - Use UDP for UDP response and timeout checks. - Use more nodes for broader regional visibility. - Leave the node list empty for automatic selection. - Use manual nodes when testing from specific regions. - Set initial survey cycles to `0` if you need the request ID immediately. - Use Raw output for format debugging. - Remember that public node availability affects results. - Store copied diagnostics securely when used in incident reports. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX Host Diagnostics** is a combined multi-protocol network diagnostic tool for checking IPv4 addresses, IPv6 addresses, domains, and hostnames across Ping, HTTP, TCP, DNS, and UDP layers. It supports flexible check selection, multi-node testing, automatic or manual node selection, initial survey cycles, per-check request IDs, aggregated metrics, node-level tables, summary copy, export support, local browser history, and raw output for debugging. The tool is designed for network troubleshooting, DevOps workflows, SOC triage, incident response, website availability checks, DNS diagnostics, firewall validation, and regional connectivity analysis. Results should be interpreted as diagnostic signals and validated with additional monitoring sources for critical decisions. # Domain WHOIS Checker | WHOIS / RDAP Domain Intelligence [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/4FjpDxVODSWt40Jq-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/4FjpDxVODSWt40Jq-image.png) The platform available at **[https://dash.niamonx.io/domain\_whois](https://dash.niamonx.io/domain_whois)** — known as **Domain WHOIS Checker** — is a domain intelligence and registration analysis tool within the NiamonX platform. It allows users to check WHOIS / RDAP information for a domain name, normalize raw registry responses, extract key ownership and registration fields, assess domain risk, and review domain age, expiration, registrar, name servers, statuses, abuse contacts, and parsed technical data. ## Overview of the Service **Domain WHOIS Checker** is designed to help users quickly understand the registration profile of a domain. The tool collects and normalizes WHOIS / RDAP-style data and displays it in a clean, structured format. Instead of forcing the user to manually read raw WHOIS text, the system extracts the most important fields and presents them as a readable domain report. The module is useful for: - SOC triage - OSINT investigation - Domain reputation review - Phishing investigation - Brand protection - Abuse reporting - Infrastructure analysis - Compliance checks - Threat intelligence enrichment - Domain lifecycle monitoring - Security research The tool displays domain status, registrar, WHOIS server, IANA registrar ID, DNSSEC status, creation date, update date, expiration date, name servers, registry statuses, contact emails, raw WHOIS, extra text, and parsed JSON. All data is provided “as is” and should be validated with official registrar or registry sources when used for critical decisions. --- ## 🔍 How the Tool Works The user enters a domain name and selects optional normalization settings. Example input: ```text google.com ``` The tool then performs a WHOIS / RDAP lookup and parses the returned response. The result may include: - Domain name - Domain activity status - Risk score - Risk level - Domain age - Days until expiration - Registrar - WHOIS server - IANA ID - DNSSEC status - Creation date - Updated date - Expiration date - Name servers - Registry statuses - Abuse or contact emails - Raw WHOIS text - Extra WHOIS text - Parsed JSON - Local request history The tool also calculates high-level metrics such as domain age and remaining expiration time, which help analysts quickly understand whether the domain appears newly registered, mature, expiring soon, or stable. --- ## 🧩 What Can Be Checked Domain WHOIS Checker accepts domain names. Valid examples: ```text google.com ``` ```text cloudflare.com ``` ```text niamonx.io ``` ```text github.io ``` Invalid examples: ```text https://google.com ``` ```text google.com/search ``` ```text https://example.com/login ``` ```text 1.1.1.1 ``` The tool is intended for domain names only. IP lookup, DNS resolution, reverse IP, ASN, and service intelligence are handled by separate NiamonX modules. --- ## ⚙️ Interface Structure The Domain WHOIS Checker interface contains several main sections. ### Domain The input field where the user enters the domain name. Example: ```text google.com ``` ### Options The tool provides optional processing settings. Available options may include: - lower-case - trim - Mask email These options help normalize input and protect sensitive contact details in the displayed report. ### Results The result panel displays the normalized domain report. ### General The General section shows core WHOIS / RDAP fields. ### Dates The Dates section displays creation, update, and expiration timestamps. ### Name Servers The Name Servers section lists authoritative name servers returned by the registry or registrar. ### Statuses The Statuses section shows domain registry status flags. ### Emails The Emails section shows detected contact or abuse emails, depending on WHOIS availability and masking settings. ### Raw WHOIS Displays the original raw WHOIS response. ### Extra Text Displays additional unstructured text returned by the WHOIS source. ### Parsed JSON Displays the normalized structured representation of the WHOIS result. ### Request History Stores recent domain checks locally in the browser. --- ## 🛠️ Input Normalization Options Domain WHOIS Checker includes options that help prepare and sanitize the input or output. ### Lower-case Converts the submitted domain to lowercase. Example: ```text GOOGLE.COM → google.com ``` This improves consistency because domain names are case-insensitive in normal DNS usage. ### Trim Removes extra spaces before and after the domain. Example: ```text google.com → google.com ``` This prevents accidental lookup errors caused by copied whitespace. ### Mask Email Masks or partially hides email addresses in the displayed result. This is useful when: - Sharing screenshots - Preparing documentation - Publishing internal reports - Reducing exposure of abuse or contact addresses - Avoiding unnecessary display of personal or operational contact data When full contact details are needed for an authorized workflow, users should handle them carefully. --- ## 📊 Result Summary After a successful lookup, the tool displays a high-level summary. Example structure: ```text google.com Active Risk 0 Low Age 10502d Exp 819d Registrar: MarkMonitor Inc. NS Count: 4 ``` The summary helps users quickly understand: - Whether the domain appears active - Its calculated risk score - Its age in days - How many days remain until expiration - Which registrar manages it - How many name servers are configured - Whether emails or statuses were detected --- ## 🚦 Domain Status The result may show a general domain state, such as: ```text Active ``` This means the domain appears to have valid registration data and is not obviously expired or unavailable in the returned WHOIS / RDAP response. Possible domain states may include: - Active - Expired - Unknown - Suspended - Pending - Error / unavailable The exact state depends on the registry data and parser output. --- ## ⚠️ Risk Score Domain WHOIS Checker calculates a risk score and risk level. Example: ```text Risk 0 Low ``` The risk score is an analytical indicator. It may consider factors such as: - Very new domain age - Expiration soon - Missing or unusual fields - Suspicious status combinations - Unusual registrar or WHOIS structure - Missing name servers - Domain lifecycle anomalies - Potentially risky registration patterns - Parser warnings Risk score helps with triage, but it is not a final reputation verdict. A low risk score does not guarantee that the domain is safe. A higher score does not automatically prove malicious activity. --- ## 📅 Domain Age The **Age** metric shows how many days have passed since the domain creation date. Example: ```text Age 10502d ``` Domain age is useful for reputation analysis. General interpretation:
Domain AgePossible Interpretation
0–30 daysNewly registered domain; review carefully
31–180 daysYoung domain; may require context
181–365 daysEstablished but still relatively new
1–5 yearsMore mature domain
5+ yearsLong-running domain, often lower registration-age risk
Newly registered domains are often important in phishing, scam, malware, and impersonation investigations, but domain age alone is not proof of malicious activity. --- ## ⏳ Expiration Metric The **Exp** metric shows how many days remain until the domain expiration date. Example: ```text Exp 819d ``` Expiration data is useful for: - Domain lifecycle monitoring - Brand protection - Asset management - Security review - Detecting domains close to expiry - Preventing accidental domain loss A domain close to expiration may represent operational risk if it belongs to an organization. For suspicious domains, short expiration windows may indicate temporary infrastructure, but this must be interpreted with other signals. --- ## 🏢 Registrar Information The Registrar field shows which registrar manages the domain registration. Example: ```text Registrar: MarkMonitor Inc. ``` The General section may also show:
FieldDescription
RegistrarRegistrar name
WHOIS ServerRegistrar WHOIS server
IANA IDRegistrar identifier assigned by IANA
DNSSECDNSSEC status
Example: ```text Whois Server: whois.markmonitor.com IANA ID: 292 DNSSEC: unsigned ``` Registrar data is useful for: - Abuse reporting - Domain ownership context - Brand protection - Legal escalation - Investigating suspicious registrations - Validating domain management provider --- ## 🔐 DNSSEC Status The DNSSEC field shows whether the domain has DNSSEC configured according to the returned data. Example: ```text DNSSEC: unsigned ``` Possible values may include: - signed - unsigned - unknown - unavailable DNSSEC helps protect DNS integrity by allowing cryptographic validation of DNS responses. However, lack of DNSSEC does not automatically mean a domain is malicious. --- ## 📅 Dates Section The Dates section displays key lifecycle timestamps. Common fields:
FieldDescription
Creation DateWhen the domain was first registered
Updated DateWhen the registration record was last updated
Expiration DateWhen the domain is scheduled to expire
Example: ```text Creation Date: 1997-09-15T04:00:00Z Updated Date: 2019-09-09T15:39:04Z Expiration Date: 2028-09-14T04:00:00Z ``` ### Creation Date Useful for domain age analysis. ### Updated Date Useful for detecting recent registration changes, registrar transfers, DNS changes, or administrative updates. ### Expiration Date Useful for lifecycle monitoring and risk assessment. --- ## 🌐 Name Servers The Name Servers section lists authoritative DNS servers for the domain. Example: ```text NS1.GOOGLE.COM NS2.GOOGLE.COM NS3.GOOGLE.COM NS4.GOOGLE.COM ``` Name servers are useful for: - Identifying DNS provider - Checking domain infrastructure - Detecting DNS migration - Reviewing hosting or CDN setup - Investigating suspicious domain clusters - Brand protection - Security audits A sudden change in name servers may indicate migration, takeover, compromise, or operational change depending on context. --- ## 🏷️ Registry Statuses Domain statuses show registry-level restrictions or lifecycle states. Example statuses: ```text clientDeleteProhibited clientTransferProhibited clientUpdateProhibited serverDeleteProhibited serverTransferProhibited serverUpdateProhibited ``` Common statuses include:
StatusMeaning
`clientTransferProhibited`Registrar-level transfer lock
`clientDeleteProhibited`Registrar-level delete protection
`clientUpdateProhibited`Registrar-level update restriction
`serverTransferProhibited`Registry-level transfer restriction
`serverDeleteProhibited`Registry-level delete restriction
`serverUpdateProhibited`Registry-level update restriction
`ok`Standard active state
`pendingDelete`Domain is pending deletion
`redemptionPeriod`Domain is in redemption period
`clientHold`Domain may be prevented from resolving
`serverHold`Registry-level hold
Status codes help analysts understand domain protection, lifecycle, and administrative restrictions. --- ## 📧 Emails and Contacts The tool extracts visible email addresses from the WHOIS / RDAP response when available. Example: ```text abusecomplaints@example-registrar.com ``` Email fields may include: - Abuse contact - Registrar contact - Administrative contact - Technical contact - Generic WHOIS contact Due to privacy rules and redaction practices, many WHOIS records no longer expose registrant personal email addresses. If Mask email is enabled, emails may be hidden or partially masked in the interface. Contact emails are useful for: - Abuse reports - Phishing takedown requests - Registrar escalation - Legal workflows - Security notifications --- ## 🧾 Raw WHOIS The **Raw WHOIS** section displays the original unnormalized WHOIS response. Raw WHOIS is useful when: - Parser output needs verification - Important fields are missing from the structured view - The registry uses unusual formatting - Analysts need exact source text - Legal or compliance workflows require raw evidence - Manual review is necessary Raw WHOIS may contain unstructured text, registry disclaimers, contact fields, status lines, name servers, and timestamps. --- ## 📄 Extra Text The **Extra Text** section displays additional unstructured content that may not fit into standard parsed fields. This may include: - Registry disclaimers - Terms of use - Registrar notices - RDAP messages - Additional contact notes - Parser-unmapped fields - Legal text Extra Text can be useful when investigating unusual registry responses. --- ## 🧬 Parsed JSON The **Parsed JSON** section displays structured normalized data extracted from WHOIS / RDAP. Parsed JSON may include: - Domain name - Registrar - WHOIS server - IANA ID - DNSSEC status - Dates - Name servers - Statuses - Emails - Raw text mapping - Risk values - Parser metadata Parsed JSON is useful for: - API workflows - SOC automation - Case management - Evidence preservation - Technical documentation - Internal dashboards - Compliance reporting --- ## 🕓 Request History The tool stores recent domain checks in the browser. History entries may include: - Domain - Status - Risk score - Age - Expiration remaining days - Timestamp Example history format: ```text google.com active R0 A:10502d E:819d 17.06.2026, 22:28:54 ``` History is useful for quickly repeating previous checks and comparing how domain age, expiration, and risk score change over time. Because history is browser-local, it may be cleared when users delete browser data or switch devices. On shared devices, users should clear history when investigated domains are sensitive. --- ## 🧠 Key Features ### WHOIS / RDAP Lookup Checks domain registration data using WHOIS / RDAP-style sources. ### Normalization Normalizes non-standard keys and inconsistent registry responses. ### Risk Assessment Calculates domain risk score and risk level. ### Domain Age Calculates how many days have passed since creation. ### Expiration Tracking Calculates how many days remain until expiration. ### Registrar Information Shows registrar, WHOIS server, and IANA ID. ### DNSSEC Status Displays DNSSEC signing state when available. ### Name Server Extraction Lists authoritative name servers. ### Status Extraction Displays registry and registrar status codes. ### Email Extraction and Masking Extracts contact emails and supports masking. ### Raw WHOIS Allows manual review of original response. ### Parsed JSON Provides structured technical data. ### Request History Stores recent checks locally in the browser. ### Export Support Supports history and result export workflows when available. --- ## 🔎 Common Use Cases Domain WHOIS Checker supports many investigative and operational workflows. ### Phishing Investigation Check whether a suspicious domain is newly registered or has risky lifecycle signals. ### Brand Protection Monitor domains that imitate a company, product, or executive name. ### Abuse Reporting Find registrar and abuse contact information. ### SOC Triage Enrich suspicious domains from alerts, emails, logs, or SIEM events. ### Domain Lifecycle Monitoring Check expiration dates for owned or critical domains. ### Infrastructure Review Identify registrar, name servers, and DNSSEC status. ### Threat Intelligence Collect registration metadata for suspicious infrastructure. ### Compliance and Documentation Document domain ownership and registration details. ### Fraud Analysis Review domain age, registrar, and status flags for suspicious websites. --- ## ⚠️ Result Interpretation WHOIS / RDAP data should be interpreted carefully. Important points: - WHOIS data may be redacted for privacy. - Registrar data may differ from registry data. - Some fields may be missing or normalized. - Raw WHOIS formats vary by TLD and registrar. - Domain age does not prove legitimacy. - New domains are not automatically malicious. - Old domains are not automatically safe. - Status codes may reflect normal domain protection. - Expiration date may change after renewal. - DNSSEC unsigned does not automatically mean insecure or malicious. - Risk score is a heuristic, not a final verdict. For legal, takedown, or high-impact security actions, validate with the registrar, registry, RDAP, DNS, certificate transparency, passive DNS, and content analysis. --- ## ✅ Recommended Analyst Workflow A practical WHOIS investigation should follow these steps. ### 1. Enter a Clean Domain Use only the domain name without protocol or path. ### 2. Enable Normalization Options Use lower-case and trim to avoid input mistakes. ### 3. Enable Email Masking When Sharing Mask email addresses before screenshots or external reports. ### 4. Review the Summary Check activity status, risk, age, expiration, registrar, name server count, and detected emails. ### 5. Review Dates Check creation, update, and expiration dates. ### 6. Review Registrar Identify registrar, WHOIS server, and IANA ID. ### 7. Review Name Servers Check whether name servers match expected infrastructure. ### 8. Review Status Codes Look for transfer locks, holds, pending deletion, or lifecycle restrictions. ### 9. Inspect Raw WHOIS Use raw WHOIS when parser output looks incomplete or unusual. ### 10. Use Parsed JSON Use structured JSON for reports, automation, or case management. --- ## 🛡️ Security, Privacy & Responsible Use Domain WHOIS Checker is intended for lawful domain intelligence, cybersecurity analysis, infrastructure review, and abuse reporting. Acceptable use cases include: - Checking your own domains - Investigating suspicious domains - Reviewing phishing infrastructure - Finding registrar abuse contacts - Monitoring domain expiration - Supporting SOC triage - Brand protection - Threat intelligence enrichment - Compliance documentation - Infrastructure auditing Users should follow responsible use principles: - Do not use contact information for harassment or spam. - Do not assume malicious intent from domain age alone. - Do not publish personal data from WHOIS records unnecessarily. - Respect privacy redaction and applicable data protection laws. - Validate important findings with additional sources. - Treat local history as sensitive on shared devices. - Use the tool only for lawful and ethical analysis. --- ## ⚙️ Technical Highlights - Domain WHOIS / RDAP checker - Available at `dash.niamonx.io/domain_whois` - Domain input - Lower-case option - Trim option - Email masking option - Client-side timing display - WHOIS / RDAP data normalization - Normalization of non-standard keys - Domain status detection - Risk score and risk level - Domain age calculation - Expiration remaining calculation - Registrar extraction - WHOIS server extraction - IANA registrar ID extraction - DNSSEC status - Creation date - Updated date - Expiration date - Name server extraction - Registry status extraction - Email extraction - Raw WHOIS viewer - Extra Text section - Parsed JSON section - Request history - Export support - Suitable for SOC, OSINT, phishing analysis, brand protection, compliance, and domain lifecycle monitoring --- ## 📌 Usage Hints - Enter only the domain name. - Do not include `https://`, paths, query strings, or slashes. - Use lower-case and trim for clean normalization. - Enable Mask email when sharing screenshots or reports. - Check domain age for phishing and fraud triage. - Check expiration for lifecycle risk. - Review registrar and WHOIS server for abuse escalation. - Review name servers for infrastructure context. - Review statuses to understand locks or lifecycle restrictions. - Use Raw WHOIS when parsed data looks incomplete. - Use Parsed JSON for technical workflows. - Remember that all data is provided “as is.” - Validate critical findings with additional sources. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX Domain WHOIS Checker** is a WHOIS / RDAP domain intelligence tool that normalizes raw registry responses and displays key domain registration metrics, including status, risk, age, expiration, registrar, WHOIS server, IANA ID, DNSSEC, name servers, statuses, emails, raw WHOIS, extra text, parsed JSON, and request history. The tool is designed for phishing investigation, SOC triage, OSINT enrichment, brand protection, abuse reporting, domain lifecycle monitoring, compliance review, and infrastructure analysis. Results are provided “as is” and should be validated with official registrar, registry, DNS, and security sources when used for important decisions. # WebSite Screenshot | Web Capture & Device Emulation Tool [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/5dGbUYvqKdHrN1Yy-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/5dGbUYvqKdHrN1Yy-image.png) The platform available at **[https://dash.niamonx.io/webscreen](https://dash.niamonx.io/webscreen)** — known as **WebSite Screenshot** — is a universal web screenshot and page-capture tool within the NiamonX platform. It allows users to capture visual snapshots of websites using desktop, phone, or tablet emulation, with support for viewport screenshots, full-page screenshots, DOM element capture, selector-based interaction, crop areas, custom headers, cookies, language settings, zoom, delay, cache control, and multiple output formats. ## Overview of the Service **WebSite Screenshot** is designed to help users capture accurate visual evidence of web pages, interfaces, landing pages, dashboards, public websites, suspicious pages, phishing pages, brand impersonation pages, documentation pages, and web content that needs to be reviewed, archived, or shared. The tool can emulate different devices and screen sizes, wait for dynamic content to load, hide unwanted elements, click selectors before capture, crop a specific area, or capture the entire page. It is useful for OSINT analysts, SOC teams, brand protection teams, compliance departments, QA engineers, developers, investigators, content reviewers, and support teams. The module supports several capture modes and configuration options, making it suitable for both quick screenshots and more controlled technical captures. --- ## 🔍 How the Tool Works When a user enters a website URL and selects capture settings, WebSite Screenshot loads the page in a controlled rendering environment and creates a screenshot based on the selected options. The tool can capture: - Standard viewport screenshots - Full-page screenshots - Mobile screenshots - Tablet screenshots - Desktop screenshots - Specific DOM elements - Cropped areas - Pages after clicking a selector - Pages after hiding selected elements - Pages with custom language, user-agent, or cookies The result is returned as an image file with size, format, cache key, timestamp, and screenshot preview. Example capture configuration: ```text Website URL: https://niamonx.io/en/ Device: Desktop Dimension: 1024x768 Format: JPG Delay: 200 ms Zoom: 100% ``` Example result: ```text JPG 110.6 KB Key: 40285e67 17.06.2026, 22:32:30 ``` --- ## 🧩 What Can Be Captured WebSite Screenshot supports full website URLs. Valid examples: ```text https://niamonx.io/en/ ``` ```text https://example.com/ ``` ```text https://docs.example.com/page ``` Unsupported or invalid examples: ```text example.com ``` ```text niamonx.io/en/ ``` ```text localhost ``` ```text file:///C:/page.html ``` For best results, users should enter a complete URL with `http://` or `https://`. --- ## ⚙️ Capture Settings The Capture Settings panel contains the main screenshot configuration options. ### Website URL The full URL of the page to capture. Example: ```text https://niamonx.io/en/ ``` The URL should include the protocol and should point to a page that can be loaded by the screenshot backend. --- ### Device The device setting controls browser emulation. Available device modes may include: - Desktop - Phone - Tablet Device emulation affects viewport size, user-agent behavior, layout rendering, and responsive design. Example: ```text Device: Desktop ``` --- ### Dimension The dimension field defines viewport width and height. Example: ```text 1024 x 768 ``` Supported examples: ```text 1024x768 480x800 1024xfull ``` The `full` height mode captures the full page instead of only the visible viewport. --- ### Format The output format controls the image type. Example: ```text Format: JPG ``` Possible output formats may include: - JPG - PNG - WebP, depending on backend support JPG is usually best for smaller file size. PNG is useful when sharper UI text, transparency, or lossless output is required. --- ### Delay Delay controls how long the tool waits before taking the screenshot. Example: ```text Delay: 200 ms ``` Supported delay values may include: ```text 0, 200, 400, ..., 10000 ``` Delay is useful for pages that load content dynamically, show animations, fetch API data, display cookie banners, or need time for layout stabilization. Recommended values:
Page TypeSuggested Delay
Static page0–400 ms
Normal dynamic website1000–2000 ms
Heavy page / animations2000–5000 ms
Full-page capture2000 ms or more
Complex dashboards3000–10000 ms
--- ### Zoom Zoom controls the rendering scale. Example: ```text Zoom: 100% ``` Zoom can be used when users need to capture a wider area, make text smaller or larger, or reproduce a specific visual layout. --- ### Cache Limit Cache limit controls how long a screenshot result may be reused. Example: ```text Cache limit: 14 days ``` Special value: ```text 0 = no cache ``` Example for one hour: ```text 0.041666 = 1 hour ``` Caching improves speed and reduces repeated captures for the same URL and settings. When fresh visual evidence is required, cache should be disabled or reduced. --- ## 🖥️ Device Presets The tool supports common device presets. ### Desktop Recommended sizes: ```text 1024x768 1366x768 1920x1080 ``` Desktop mode is useful for: - Standard website screenshots - Admin panels - Landing pages - Documentation pages - Full-width layouts - Web app interfaces --- ### Phone Recommended size: ```text 480x800 ``` Phone mode is useful for: - Mobile responsive testing - Mobile phishing page review - Mobile landing page capture - App-like web interface screenshots - Mobile UX documentation --- ### Tablet Recommended size: ```text 800x1280 ``` Tablet mode is useful for: - Tablet responsive testing - Mid-size layouts - Touch-oriented pages - Product QA workflows --- ### Full Page Example: ```text 1024xfull ``` Full-page capture is useful for: - Long landing pages - Documentation pages - Terms and policy pages - Blog posts - Phishing kits - Evidence collection - Website archive snapshots For heavy pages, a delay of at least 2000 ms is recommended. --- ## 🧠 Advanced Options The Advanced section allows more precise control over the capture. ### CSS Selector The CSS Selector field captures a specific DOM element instead of the whole viewport. Example: ```text #main-content ``` ```text .article-body ``` Use cases: - Capture one component - Capture a login box - Capture a pricing table - Capture an article - Capture a modal - Capture a specific evidence block --- ### Click Selector The click selector is used to click an element before the screenshot is taken. Examples: ```text .cookie-accept ``` ```text #close ``` Use cases: - Accept cookie consent - Close a modal - Open a menu - Expand a section - Dismiss a banner - Reveal hidden content This option is useful for pages that require one simple interaction before capture. --- ### Hide Selectors Hide selectors remove or visually hide unwanted elements before capture. Example: ```text .ads, .cookie, #modal ``` Use cases: - Hide advertisements - Hide cookie banners - Hide popups - Hide floating chat widgets - Hide overlays - Clean up screenshots for reports Users should use this carefully when capturing evidence. If the screenshot is used for compliance, legal, or incident response, the report should mention that some elements were hidden. --- ### Crop The crop option captures a specific rectangle from the rendered page. Format: ```text x,y,width,height ``` Example: ```text 100,0,800,300 ``` Use cases: - Capture header area - Capture only above-the-fold content - Capture one section of a page - Remove irrelevant page areas - Produce compact evidence images --- ### Accept-Language The Accept-Language field controls the language preference sent with the request. Example: ```text en-US ``` This is useful when websites show different content based on language settings. Examples: ```text en-US de-DE uk-UA ru-RU ``` --- ### User-Agent The User-Agent field allows custom browser identification. Example: ```text Mozilla/5.0 (...) ``` Use cases: - Desktop browser emulation - Mobile browser emulation - Testing responsive behavior - Checking bot filtering behavior - Comparing content shown to different clients Custom user-agent should be used responsibly and documented when screenshots are used as evidence. --- ### Cookies Cookies can be passed to the page before capture. Format: ```text name1=value1;name2=value2 ``` Use cases: - Capture authenticated-like states when authorized - Preserve consent state - Set language or region preferences - Reproduce a specific user session state - Capture pages that depend on cookie-based settings Sensitive cookies must be handled carefully. Users should not paste private session tokens unless they are authorized and understand the security implications. --- ## 📊 Result Section After a successful capture, the result panel displays screenshot output details. Typical fields include:
FieldDescription
FormatOutput image format
File sizeSize of generated screenshot
KeyCache or result key
TimestampCapture time
PreviewScreenshot preview
Example: ```text JPG 110.6 KB Key 40285e67 17.06.2026, 22:32:30 ``` The preview allows users to quickly verify that the capture looks correct before saving or using it in a report. --- ## 🕓 Local History The tool stores recent capture requests locally in the user’s browser. Example behavior: ```text Stores last 100 queries in your browser. ``` History entries may include: - Device mode - URL - Dimension - Output format - Capture timestamp Example history item: ```text desktop https://niamonx.io/en/ 1024x768 JPG 17.06.2026, 22:32:30 ``` Local history helps users repeat previous captures with the same settings. Because history is stored locally, it may be cleared when users delete browser data, switch devices, or use a different browser profile. On shared devices, users should clear local history when captured URLs are sensitive. --- ## 🚦 Query Limits and Plan Access WebSite Screenshot uses plan-based query limits. Example: ```text 179 / 180 Queries remaining / total Plan: Sentinel ``` Important points: - Each capture request may consume plan quota. - Limits are enforced by the user’s plan. - Repeated captures with no cache may consume more requests. - Cached results may reduce repeated processing. - Large full-page captures may require more backend resources. Users should monitor remaining queries when performing bulk captures or evidence collection. --- ## 🧠 Key Features ### Universal Web Screenshot Capture Captures public web pages and web interfaces into image format. ### Device Emulation Supports desktop, phone, and tablet modes. ### Custom Viewport Allows custom width and height values. ### Full-Page Capture Supports long-page screenshot capture using `full` height. ### Element Capture Captures a specific DOM element using a CSS selector. ### Crop Capture Captures a specific rectangle from the rendered page. ### Delay Control Waits before capture to allow dynamic content to load. ### Zoom Control Adjusts rendering scale. ### Output Format Selection Supports image output such as JPG and other configured formats. ### Cookie and Header Control Supports custom cookies, language headers, and user-agent. ### Selector Interaction Can click selectors before capture and hide selected elements. ### Cache Control Allows caching screenshot results for a configurable number of days. ### Local History Stores last 100 capture requests in the browser. ### Plan-Based Limits Access and query volume depend on the user’s plan. --- ## 🔎 Common Use Cases WebSite Screenshot supports many practical workflows. ### OSINT Evidence Capture Capture public web pages for investigation notes. ### Phishing Page Documentation Capture suspicious login pages, clone pages, or malicious landing pages. ### Brand Protection Document impersonation pages, fake stores, fake login pages, or unauthorized brand use. ### SOC and Incident Response Attach visual evidence to security incidents and tickets. ### Website QA Test desktop, phone, and tablet rendering. ### Compliance Review Capture policy pages, consent banners, or public disclosures. ### Content Monitoring Create screenshots of public pages for review. ### Support Documentation Capture UI states for support tickets or user guides. ### Archive Snapshots Preserve visual appearance of pages at a specific time. --- ## 📸 Full-Page Capture Full-page capture is useful when the content extends below the visible viewport. Example: ```text 1024xfull ``` Recommended settings for heavy pages: ```text Delay: 2000 ms or higher ``` Full-page screenshots are useful for: - Long product pages - Documentation - Blog posts - Terms pages - Phishing kits - Evidence reports - Landing pages - Marketing pages Full-page captures may be larger and may take longer to process. --- ## 🧩 Element Capture Element capture allows users to screenshot only a specific part of a page. Example selector: ```text #pricing ``` This is useful when the user needs a clean image of one section without surrounding content. Common selectors: ```text #main .article .login-form .pricing-table .hero ``` Element capture depends on valid CSS selectors and page structure. If the selector does not match any element, the capture may fail or return an empty result. --- ## 🧹 Cleaning the Page Before Capture The tool can click and hide elements before capturing. ### Click Selector Use this to accept consent or close overlays. Example: ```text .cookie-accept ``` ### Hide Selectors Use this to remove visual clutter. Example: ```text .ads, .cookie, #modal ``` Common elements to hide: - Cookie banners - Ads - Popups - Chat widgets - Sticky headers - Newsletter modals - Consent overlays For evidence workflows, users should document any hidden or clicked elements so the screenshot remains transparent and reproducible. --- ## 🌍 Language, Region, and Session Context Web pages may show different content depending on browser headers, cookies, region, and device. WebSite Screenshot provides controls for: - Accept-Language - User-Agent - Cookies - Device mode - Viewport size These settings help reproduce specific page states. Examples: ```text Accept-Language: en-US ``` ```text Device: Phone Dimension: 480x800 ``` ```text Cookies: region=de;consent=yes ``` This is useful when investigating region-specific phishing pages, localized landing pages, or responsive layouts. --- ## 🧾 Cache Behavior The cache limit controls how long the screenshot result can be reused. Examples: ```text 0 = no cache ``` ```text 14 = cache for 14 days ``` Cache is useful for: - Repeating the same capture - Reducing backend load - Faster access to previous results - Consistent screenshots for reports No-cache mode is useful when: - The page changes frequently - Fresh evidence is required - Investigating live incidents - Verifying takedown status - Capturing time-sensitive content --- ## ⚠️ Result Interpretation Screenshots should be interpreted carefully. Important notes: - A screenshot captures only one point in time. - Dynamic pages may change after capture. - Ads, geolocation, cookies, and language can change page content. - Some pages detect automation or block rendering. - Delays may affect whether content appears. - Full-page screenshots can miss lazy-loaded content if it does not load properly. - Hidden selectors change the visible evidence. - Click selectors may alter the page state. - Cached screenshots may not show the latest page version. - A screenshot does not prove who controls the website. For investigations, screenshots should be combined with timestamp, URL, DNS data, WHOIS, HTTP headers, TLS certificate data, and raw page evidence when available. --- ## ✅ Recommended Capture Workflow A practical screenshot workflow should follow these steps. ### 1. Enter the Full URL Use `https://` or `http://` and include the exact path. ### 2. Choose Device Mode Select desktop, phone, or tablet depending on the page version you need. ### 3. Set Dimensions Use a standard viewport such as `1024x768`, `480x800`, or `1024xfull`. ### 4. Choose Format Use JPG for small files or PNG when sharper UI quality is needed. ### 5. Set Delay Use at least 2000 ms for heavy or dynamic pages. ### 6. Handle Popups Use click selector or hide selectors for cookie banners, ads, or modals when appropriate. ### 7. Use Full Page or Crop Use full page for long content or crop for a precise section. ### 8. Set Language and Cookies if Needed Use Accept-Language, User-Agent, or Cookies to reproduce a specific state. ### 9. Review Preview Confirm that the screenshot captured the correct content. ### 10. Save Evidence Securely Store screenshots and settings together when used for investigations or reports. --- ## 🛡️ Security, Privacy & Responsible Use WebSite Screenshot is intended for lawful web capture, documentation, OSINT, QA, compliance, support, and cybersecurity workflows. Acceptable use cases include: - Capturing your own websites - Capturing public pages for documentation - Phishing page evidence collection - Brand abuse documentation - QA and responsive testing - Compliance screenshots - Support and bug reports - SOC and incident response evidence - Public OSINT investigation Users should follow responsible use principles: - Do not capture private pages without authorization. - Do not submit sensitive session cookies unless authorized. - Do not use screenshots for harassment, doxxing, or impersonation. - Do not bypass access controls. - Do not misuse user-agent or cookies to access restricted content. - Document advanced settings when screenshots are used as evidence. - Treat screenshot history as sensitive on shared devices. - Validate critical findings with additional technical evidence. --- ## ⚙️ Technical Highlights - Universal web screenshot tool - Available at `dash.niamonx.io/webscreen` - Supports website URL capture - Desktop, phone, and tablet emulation - Custom viewport dimensions - Full-page capture with `full` height - JPG output support - Delay control from 0 to 10000 ms - Zoom percentage control - Cache limit in days - CSS selector element capture - Click selector before capture - Hide selectors before capture - Crop region support - Accept-Language override - Custom User-Agent support - Cookie injection support - Screenshot preview - Result key and timestamp - Local browser history - Stores last 100 queries locally - Plan-based query limits - Suitable for OSINT, SOC, QA, compliance, documentation, and support workflows --- ## 📌 Usage Hints - Use full URLs with `https://` or `http://`. - Use `1024x768` for standard desktop screenshots. - Use `480x800` for phone screenshots. - Use `800x1280` for tablet screenshots. - Use `1024xfull` for long pages. - Set delay to at least 2000 ms for heavy full-page captures. - Use `.cookie`, `.ads`, or `#modal` in hide selectors to clean screenshots. - Use click selector to accept consent or close overlays. - Use crop when only one area is needed. - Use cache `0` when fresh evidence is required. - Be careful with cookies and session data. - Remember that limits are enforced by your plan. - Local history stores the last 100 capture requests in the browser. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX WebSite Screenshot** is a flexible screenshot capture and device emulation tool for public web pages. It supports desktop, phone, and tablet rendering, custom viewport dimensions, full-page capture, element capture, crop regions, delay, zoom, cache control, selector-based clicking, selector hiding, custom language, user-agent, cookies, screenshot preview, local history, and plan-based query limits. The tool is designed for OSINT evidence collection, phishing investigation, SOC workflows, brand protection, QA testing, compliance documentation, support cases, and web archive snapshots. Screenshots should be treated as point-in-time visual evidence and interpreted together with the capture settings, timestamp, URL, and supporting technical data. # Website to PDF | Webpage PDF Conversion Tool [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/1eBGgWQdpVPCPVnE-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/1eBGgWQdpVPCPVnE-image.png) The platform available at **[https://dash.niamonx.io/web\_topdf](https://dash.niamonx.io/web_topdf)** — known as **Website to PDF** — is a webpage-to-PDF conversion tool within the NiamonX platform. It allows users to convert public webpages into PDF documents with configurable paper size, orientation, rendering media mode, delay, scale, background rendering, cookies, language headers, custom user-agent, click selectors, and hidden elements. ## Overview of the Service **Website to PDF** is designed to help users convert public web pages into structured PDF files for documentation, investigation, evidence preservation, compliance review, QA testing, reporting, archiving, and sharing. The tool loads a target webpage in a controlled rendering environment and exports it as a PDF document based on the selected conversion settings. Users can choose paper layout, orientation, screen or print rendering mode, background rendering, delay, scale, and several advanced options that help reproduce a specific page state. Website to PDF is useful for OSINT analysts, SOC teams, cybersecurity investigators, compliance departments, brand protection teams, support teams, legal reviewers, QA engineers, developers, researchers, and documentation teams. The module is especially helpful when users need a portable, timestamped, shareable PDF representation of a website instead of a screenshot image. --- ## 🔍 How the Tool Works When a user enters a website URL and selects conversion settings, Website to PDF loads the page, waits according to the configured delay, optionally performs selector-based actions, applies rendering options, and generates a PDF file. The tool can convert: - Public webpages - Landing pages - Documentation pages - Articles and blog posts - Product pages - Policy pages - Terms and privacy pages - Public dashboards - Printer-friendly pages - Suspicious or phishing pages - Brand impersonation pages - Pages that require simple cookie/banner handling Example conversion configuration: ```text Website URL: https://www.netflix.com/de-en/ Paper: A4 Orientation: Portrait Media: Screen Include background: Yes Delay: 200 ms Scale: 100% ``` Example result: ```text PDF 1.39 MB Key: d7d63a63 17.06.2026, 22:38:39 ``` --- ## 🧩 What Can Be Converted Website to PDF supports complete public website URLs. Valid examples: ```text https://www.netflix.com/de-en/ ``` ```text https://niamonx.io/ ``` ```text https://help.ubuntu.ru/wiki/nginx-phpfpm ``` ```text https://www.netacad.com ``` Unsupported or invalid examples: ```text netflix.com ``` ```text www.netflix.com/de-en/ ``` ```text localhost ``` ```text file:///C:/page.html ``` ```text 192.168.1.1 ``` For best results, users should enter a complete URL with `http://` or `https://`. Private, local, internal, or restricted resources may not be accessible from the conversion backend unless they are publicly reachable and authorized for capture. --- ## ⚙️ Conversion Settings The Conversion Settings panel contains the main PDF generation options. ### Website URL The full URL of the page to convert into PDF. Example: ```text https://www.netflix.com/de-en/ ``` The URL should include the protocol and should point to a webpage that can be loaded by the backend. Recommended format: ```text https://domain.com/path ``` The entered page should be publicly accessible or intentionally accessible through the provided authorized context, such as cookies. --- ### Paper The paper setting controls the target PDF page size. Example: ```text Paper: A4 ``` A4 is commonly used for reports, evidence exports, documentation, compliance archives, and printable records. Common use cases for A4: - Investigation reports - Evidence bundles - Compliance documentation - Policy page exports - Legal review material - Support attachments - Printable documentation Depending on backend configuration, additional paper sizes may be supported. The current interface example uses A4. --- ### Orientation Orientation controls whether the PDF page is generated vertically or horizontally. Available orientation modes include: - Portrait - Landscape Example: ```text Orientation: Portrait ``` Portrait mode is usually best for articles, policy pages, documentation pages, legal pages, and standard website exports. Landscape mode is useful for wide layouts, dashboards, tables, admin panels, pricing comparisons, or pages with horizontal UI elements. Example: ```text Orientation: Landscape ``` Recommended orientation:
Page TypeSuggested Orientation
Article or blog postPortrait
Terms or privacy policyPortrait
Documentation pagePortrait
Wide dashboardLandscape
Pricing tableLandscape
Data tableLandscape
Landing pagePortrait or Landscape
--- ### Media The media setting controls how the webpage is rendered before PDF generation. Available media modes include: - Screen - Print Example: ```text Media: Screen ``` Screen mode captures the page as it would normally appear in a browser. Print mode uses the website’s print stylesheet when available. This can produce cleaner, more document-like output for pages that support printer-friendly layouts. Example: ```text Media: Print ``` Recommended media mode:
GoalSuggested Media
Preserve visual browser appearanceScreen
Create printer-friendly PDFPrint
Capture marketing landing pageScreen
Export documentationPrint or Screen
Export policy or legal pagePrint
Capture phishing or scam pageScreen
Remove unnecessary web UI naturallyPrint
Important note: Print mode may change the appearance of the page because many websites hide navigation menus, banners, sidebars, videos, ads, and interactive elements in their print stylesheet. --- ### Include Background The Include Background option controls whether backgrounds are rendered in the PDF. Example: ```text Include background: Yes ``` When enabled, the PDF includes background colors, background images, section backgrounds, hero blocks, styled buttons, and other visual design elements. When disabled, the PDF may look cleaner and more printer-friendly. Example: ```text Include background: No ``` Recommended usage:
GoalInclude Background
Visual evidenceYes
Brand impersonation documentationYes
Phishing page captureYes
Clean printingNo
Text-focused reviewNo
Smaller PDF sizeNo
UI/UX documentationYes
For evidence workflows, background rendering should usually stay enabled because it preserves the page’s visual appearance more accurately. --- ### Delay Delay controls how long the tool waits before generating the PDF. Example: ```text Delay: 200 ms ``` Supported delay values may include: ```text 0, 200, 400, ..., 10000 ``` Delay is useful when pages need time to load dynamic content, animations, external resources, cookie banners, fonts, images, API data, or lazy-loaded sections. Recommended delay values:
Page TypeSuggested Delay
Simple static page0–400 ms
Normal website1000–2000 ms
Dynamic landing page2000–3000 ms
Heavy page with animations3000–5000 ms
Complex dashboard3000–10000 ms
Page with cookie banner1000–3000 ms
Page with lazy-loaded content2000–5000 ms
Evidence capture2000 ms or more
Example for a heavier page: ```text Delay: 2000 ms ``` A longer delay can improve completeness, but it may also increase processing time and resource usage. --- ### Scale Scale controls the rendering size of the webpage content inside the PDF. Example: ```text Scale: 100% ``` Scale can be used to fit more content on each page or make content larger and easier to read. Examples: ```text Scale: 80% ``` ```text Scale: 100% ``` ```text Scale: 120% ``` Recommended usage:
GoalSuggested Scale
Default PDF export100%
Fit more content per page70–90%
Improve readability110–125%
Capture wide layout on A470–90%
Preserve normal browser feel100%
Scale affects layout, pagination, text size, and the number of PDF pages. --- ## 🧠 Advanced Options The Advanced section allows more controlled webpage conversion. ### Click Selector The Click Selector option clicks a specific element before PDF generation. Example: ```text .cookie-accept ``` ```text #close ``` Use cases: - Accept cookie banners - Close popups - Dismiss overlays - Open hidden sections - Expand accordions - Close newsletter modals - Reveal page content before export Example: ```text Click selector: .cookie-accept ``` This option is useful when a page blocks content with a banner or modal that can be handled with one simple click. For evidence workflows, users should document the clicked selector because it changes the visible state of the page. --- ### Hide Selectors Hide Selectors allows users to hide unwanted elements before converting the page to PDF. Example: ```text .ads, .cookie, #modal ``` Use cases: - Hide advertisements - Hide cookie banners - Hide newsletter popups - Hide floating chat widgets - Hide sticky headers - Hide overlays - Remove irrelevant UI elements - Create cleaner documentation PDFs Common selectors: ```text .ads .cookie #modal .newsletter .chat-widget .sticky-header ``` Example: ```text Hide selectors: .ads, .cookie, #modal ``` Users should use this option carefully when creating evidence. If elements were hidden, the report should mention it so the PDF remains transparent and reproducible. --- ### Cookies Cookies can be passed to the webpage before conversion. Format: ```text name1=value1;name2=value2 ``` Example: ```text region=de;consent=yes ``` Use cases: - Preserve consent state - Set language or region preferences - Reproduce a specific page state - Capture pages that depend on cookie-based settings - Avoid repeated cookie banners - Capture authorized content when the user has permission Important security note: Users should not paste sensitive session cookies unless they are authorized and fully understand the risk. Session cookies can provide access to accounts or private data. For sensitive investigations, cookies should be handled as confidential data. --- ### Accept-Language Accept-Language controls the language preference sent with the webpage request. Example: ```text Accept-Language: en-US ``` Other examples: ```text de-DE ``` ```text uk-UA ``` ```text ru-RU ``` This is useful when websites show different content depending on language settings. Use cases: - Capture localized landing pages - Compare regional content - Investigate language-specific phishing pages - Export documentation in a specific language - Reproduce content shown to users from a certain locale Example: ```text Accept-Language: de-DE ``` --- ### User-Agent The User-Agent field allows custom browser identification during conversion. Example: ```text Mozilla/5.0 (...) ``` Use cases: - Desktop browser emulation - Mobile browser behavior testing - Checking content variation by browser - Reproducing a specific client environment - Comparing bot-filtered or browser-specific content - Debugging rendering differences Custom user-agent should be used responsibly and documented when the PDF is used as evidence. --- ## 📄 Result Section After a successful conversion, the Result panel displays PDF output details. Typical fields include:
FieldDescription
File sizeSize of the generated PDF
KeyCache or result identifier
TimestampDate and time of PDF generation
OutputGenerated PDF document
Example: ```text 1.39 MB Key d7d63a63 17.06.2026, 22:38:39 ``` The result allows users to confirm that the conversion was completed and that the generated PDF is available for review, download, sharing, or reporting. PDF file size depends on: - Page length - Images - Fonts - Backgrounds - Media mode - Scale - Paper size - Number of generated pages - Dynamic content - Website complexity --- ## 🕓 Local History Website to PDF stores recent conversion requests locally in the user’s browser. Example behavior: ```text Stores last 100 queries in your browser. ``` History entries may include: - Website URL - Paper size - Orientation - Media mode - Conversion timestamp Example history item: ```text https://www.netflix.com/de-en/ A4 PORTRAIT SCREEN 17.06.2026, 22:38:39 ``` Another example: ```text https://www.netacad.com A4 PORTRAIT PRINT 12.10.2025, 23:12:38 ``` Local history helps users repeat previous conversions with the same or similar settings. Because history is stored locally, it may be cleared when users delete browser data, change browsers, use a different device, or switch browser profiles. On shared devices, users should treat conversion history as sensitive and clear it when URLs contain confidential, investigative, legal, or internal context. --- ## 🚦 Query Limits and Plan Access Website to PDF uses plan-based query limits. Example: ```text 179 / 180 Queries remaining / total Plan: Sentinel ``` Important points: - Each conversion request may consume plan quota. - Limits depend on the active user plan. - Repeated conversions may consume additional queries. - Heavy pages may require more backend resources. - Long delays and complex pages may increase processing cost. - Failed conversions may still count depending on backend rules. - Plan limits apply to normal and advanced usage. Users should monitor remaining queries when converting multiple pages for reports, investigations, evidence packages, compliance reviews, or bulk documentation. --- ## 🧠 Key Features ### Webpage to PDF Conversion Converts public webpages into portable PDF documents. ### Paper Configuration Supports paper-based PDF output such as A4. ### Orientation Control Allows Portrait or Landscape PDF layout. ### Media Rendering Supports Screen and Print media rendering modes. ### Background Rendering Can include or exclude webpage backgrounds. ### Delay Control Waits before conversion to allow dynamic content to load. ### Scale Control Adjusts webpage rendering size inside the PDF. ### Selector Interaction Can click a selected element before conversion. ### Hide Selectors Can hide unwanted page elements before PDF generation. ### Cookie Support Allows cookie-based page state reproduction. ### Language Header Control Supports Accept-Language customization. ### User-Agent Control Allows custom browser identification. ### Result Metadata Displays PDF size, result key, and timestamp. ### Local History Stores the last 100 conversion requests in the browser. ### Plan-Based Limits Access and query volume depend on the user’s plan. --- ## 🔎 Common Use Cases Website to PDF supports many practical workflows. ### OSINT Evidence Export Convert public webpages into PDF documents for investigation notes and reports. ### Phishing Page Documentation Export suspicious login pages, clone pages, scam pages, or malicious landing pages as PDF evidence. ### Brand Protection Document fake websites, impersonation pages, counterfeit stores, unauthorized brand use, or misleading public pages. ### SOC and Incident Response Attach PDF evidence to incident tickets, case management systems, internal reports, or escalation workflows. ### Compliance Review Export terms, privacy policies, cookie notices, public disclosures, regulatory pages, or public-facing statements. ### Legal and Audit Documentation Create PDF records of public webpages for legal review, audit trails, or compliance archives. ### QA and Web Testing Check how pages render in screen or print mode and preserve output for bug reports. ### Documentation Archiving Convert technical documentation, help pages, guides, or knowledge base pages into PDF files. ### Support Cases Attach converted web pages to support tickets for easier review. ### Research and Reporting Save public articles, pages, and references as stable PDF documents for later analysis. ### Printer-Friendly Output Use print media and background control to create clean, readable PDF files. --- ## 📐 Paper, Orientation, and Media Recommendations The best settings depend on the target page and intended use. ### Standard Webpage Export Recommended settings: ```text Paper: A4 Orientation: Portrait Media: Screen Include background: Yes Delay: 1000–2000 ms Scale: 100% ``` Best for: - Landing pages - Public websites - Visual evidence - Brand protection - Phishing pages - General webpage archiving --- ### Clean Printable PDF Recommended settings: ```text Paper: A4 Orientation: Portrait Media: Print Include background: No Delay: 1000–2000 ms Scale: 100% ``` Best for: - Articles - Policies - Terms pages - Documentation - Legal review - Text-focused reports --- ### Wide Layout or Table Export Recommended settings: ```text Paper: A4 Orientation: Landscape Media: Screen Include background: Yes Delay: 2000 ms Scale: 80–90% ``` Best for: - Dashboards - Pricing tables - Comparison pages - Wide UI layouts - Data tables - Admin panels --- ### Heavy Dynamic Page Recommended settings: ```text Paper: A4 Orientation: Portrait Media: Screen Include background: Yes Delay: 3000–5000 ms Scale: 100% ``` Best for: - JavaScript-heavy websites - Animated pages - Pages with lazy-loaded content - Pages with delayed API data - Complex landing pages --- ### Evidence Collection Recommended settings: ```text Paper: A4 Orientation: Portrait Media: Screen Include background: Yes Delay: 2000 ms or higher Scale: 100% ``` Recommended evidence notes: ```text URL Timestamp Paper size Orientation Media mode Delay Scale Background setting Click selector Hide selectors Cookies used Accept-Language User-Agent Result key ``` For investigation work, PDF output should be stored together with conversion settings and supporting technical evidence. --- ## 🖨️ Screen Media vs Print Media Website to PDF supports two major rendering modes: Screen and Print. ### Screen Media Screen media renders the webpage as it appears in a normal browser. Best for: - Visual evidence - Phishing pages - Brand impersonation - Landing pages - Public web UI - Screenshot-like PDF exports - Design and QA review Example: ```text Media: Screen ``` Screen mode is usually the best choice when visual appearance matters. --- ### Print Media Print media uses the website’s print stylesheet if available. Best for: - Clean PDFs - Documentation - Articles - Policies - Terms pages - Legal review - Printer-friendly output Example: ```text Media: Print ``` Print mode may remove or change: - Navigation menus - Headers - Footers - Backgrounds - Videos - Animations - Sidebars - Ads - Interactive elements - Cookie banners Print mode can produce cleaner output, but it may not reflect what a normal user saw in the browser. --- ## 🧹 Cleaning the Page Before Conversion Some websites display banners, overlays, popups, ads, or chat widgets that interfere with PDF output. Website to PDF provides two main cleanup options: ### Click Selector Use Click Selector when an element needs to be clicked before conversion. Example: ```text .cookie-accept ``` Common uses: - Accept cookie banner - Close modal - Dismiss overlay - Expand collapsed section - Open menu - Reveal hidden content --- ### Hide Selectors Use Hide Selectors when elements should be visually removed before conversion. Example: ```text .ads, .cookie, #modal ``` Common elements to hide: - Cookie banners - Ads - Popups - Sticky headers - Floating chat widgets - Newsletter forms - Consent overlays - Promotional banners For evidence and compliance workflows, users should document all cleanup actions. Example documentation note: ```text Before PDF generation, the selector .cookie-accept was clicked and .ads, #modal were hidden. ``` --- ## 🌍 Language, Region, and Session Context Webpages may show different content depending on language, region, cookies, browser type, or session context. Website to PDF provides controls for: - Cookies - Accept-Language - User-Agent - Media mode - Delay - Click selector - Hide selectors Examples: ```text Accept-Language: en-US ``` ```text Accept-Language: de-DE ``` ```text Cookies: region=de;consent=yes ``` ```text User-Agent: Mozilla/5.0 (...) ``` These settings help reproduce a more specific page state. Use cases: - Region-specific content review - Localized phishing page investigation - Language-specific landing page capture - Cookie-consent state preservation - Browser-specific rendering comparison - Reproducing a user-reported issue Important note: A PDF created with custom cookies, language, or user-agent reflects that specific request context, not necessarily the default version of the website. --- ## 📊 Result Interpretation PDF output should be interpreted carefully. Important notes: - A PDF captures a webpage at one point in time. - Dynamic content may change after conversion. - Screen and print media can produce different results. - Cookies can change what content is shown. - Accept-Language can change language and regional content. - User-Agent can affect layout and content. - Hidden selectors change the visible output. - Click selectors may change the page state. - Background disabled may remove important visual elements. - Scale can affect pagination and layout. - Some websites block automated rendering. - Some resources may fail to load. - Lazy-loaded content may be incomplete without enough delay. - A PDF does not prove who owns or controls a website. For investigations, PDF evidence should be combined with: - Exact URL - Timestamp - HTTP headers - DNS records - WHOIS data - TLS certificate details - Screenshot evidence - HTML source when available - Redirect chain - IP information - Threat intelligence context - Analyst notes --- ## ✅ Recommended Conversion Workflow A practical Website to PDF workflow should follow these steps. ### 1. Enter the Full Website URL Use a complete URL with protocol. Example: ```text https://www.netflix.com/de-en/ ``` Avoid incomplete URLs such as: ```text www.netflix.com/de-en/ ``` --- ### 2. Select Paper Size Use A4 for standard reports, documentation, and printable PDF output. Example: ```text Paper: A4 ``` --- ### 3. Choose Orientation Use Portrait for normal pages and Landscape for wide layouts. Example: ```text Orientation: Portrait ``` --- ### 4. Choose Media Mode Use Screen for visual accuracy and Print for printer-friendly output. Example: ```text Media: Screen ``` --- ### 5. Decide Whether to Include Background Use background enabled for visual evidence. Example: ```text Include background: Yes ``` Use background disabled for clean printing. Example: ```text Include background: No ``` --- ### 6. Set Delay Use a short delay for simple pages and a longer delay for dynamic pages. Example: ```text Delay: 2000 ms ``` --- ### 7. Set Scale Start with 100%. Reduce scale if content is too large or too wide. Example: ```text Scale: 100% ``` --- ### 8. Handle Popups or Cookie Banners Use Click Selector or Hide Selectors when needed. Example: ```text Click selector: .cookie-accept ``` Example: ```text Hide selectors: .ads, .cookie, #modal ``` --- ### 9. Add Language, User-Agent, or Cookies if Needed Use advanced settings to reproduce a specific context. Example: ```text Accept-Language: de-DE Cookies: region=de;consent=yes ``` --- ### 10. Generate and Review the PDF Check the result size, key, timestamp, and output. Example: ```text 1.39 MB Key d7d63a63 17.06.2026, 22:38:39 ``` --- ### 11. Store the PDF With Context For professional workflows, store the PDF together with the conversion settings. Recommended record: ```text URL: https://www.netflix.com/de-en/ Paper: A4 Orientation: Portrait Media: Screen Include background: Yes Delay: 200 ms Scale: 100% Result key: d7d63a63 Timestamp: 17.06.2026, 22:38:39 ``` --- ## 🛡️ Security, Privacy & Responsible Use Website to PDF is intended for lawful webpage conversion, documentation, OSINT, QA, compliance, support, cybersecurity, and evidence workflows. Acceptable use cases include: - Converting your own websites - Exporting public pages for documentation - Capturing public evidence - Documenting phishing pages - Reviewing brand abuse - Archiving public policy pages - Creating support attachments - Testing print rendering - Generating compliance records - Saving public documentation as PDF Users should follow responsible use principles: - Do not convert private pages without authorization. - Do not submit sensitive session cookies unless authorized. - Do not use the tool to bypass access controls. - Do not misuse user-agent or cookies to access restricted content. - Do not use generated PDFs for harassment, doxxing, impersonation, or abuse. - Document advanced settings when PDFs are used as evidence. - Treat local history as sensitive on shared devices. - Store PDFs securely when they contain investigative or confidential context. - Validate critical findings with additional technical evidence. Sensitive cookies, private URLs, authentication tokens, and internal resources must be handled carefully. --- ## ⚙️ Technical Highlights - Webpage to PDF conversion tool - Available at `dash.niamonx.io/web_topdf` - Converts public webpages into PDF documents - Supports A4 paper output - Supports Portrait and Landscape orientation - Supports Screen and Print media modes - Supports background rendering control - Delay control from 0 to 10000 ms - Scale percentage control - Click selector before conversion - Hide selectors before conversion - Cookie injection support - Accept-Language override - Custom User-Agent support - Result file size display - Result key generation - Timestamped output - Local browser history - Stores last 100 queries locally - Plan-based query limits - Suitable for OSINT, SOC, QA, compliance, documentation, support, legal review, and cybersecurity workflows --- ## 📌 Usage Hints - Use full URLs with `https://` or `http://`. - Use A4 Portrait Screen for standard webpage exports. - Use A4 Landscape for wide pages, dashboards, and tables. - Use Print media for cleaner printer-friendly documents. - Use Screen media when visual evidence matters. - Keep background enabled for phishing, brand abuse, and visual evidence. - Disable background for cleaner printing and smaller PDFs. - Use at least 2000 ms delay for dynamic pages. - Use longer delay for animated, lazy-loaded, or heavy pages. - Use scale 100% as the default. - Reduce scale to 80–90% for wide layouts. - Use Click Selector to accept cookie banners or close dialogs. - Use Hide Selectors to remove ads, banners, popups, or overlays. - Use Accept-Language to capture localized page versions. - Use Cookies only when authorized and necessary. - Use custom User-Agent responsibly. - Review generated PDFs before using them in reports. - Store conversion settings together with the PDF for reproducibility. - Remember that plan limits apply. - Local history stores the last 100 conversion requests in the browser. --- ## 🧾 Example Configurations ### Basic PDF Export ```text Website URL: https://niamonx.io Paper: A4 Orientation: Portrait Media: Screen Include background: Yes Delay: 200 ms Scale: 100% ``` Best for normal visual webpage export. --- ### Printer-Friendly Export ```text Website URL: https://www.netacad.com Paper: A4 Orientation: Portrait Media: Print Include background: No Delay: 1000 ms Scale: 100% ``` Best for clean reading and printing. --- ### Investigation Evidence Export ```text Website URL: https://www.netflix.com/de-en/ Paper: A4 Orientation: Portrait Media: Screen Include background: Yes Delay: 2000 ms Scale: 100% Click selector: .cookie-accept Hide selectors: .ads, #modal Accept-Language: de-DE ``` Best for documenting a specific visual page state. --- ### Wide Page Export ```text Website URL: https://example.com/dashboard Paper: A4 Orientation: Landscape Media: Screen Include background: Yes Delay: 2000 ms Scale: 80% ``` Best for dashboards, tables, and wide layouts. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX Website to PDF** is a flexible webpage PDF conversion tool for public websites. It supports paper configuration, Portrait and Landscape orientation, Screen and Print rendering modes, background control, delay, scale, selector-based clicking, selector hiding, cookies, Accept-Language, custom User-Agent, result metadata, local history, and plan-based limits. The tool is designed for OSINT evidence export, phishing investigation, SOC workflows, brand protection, QA testing, compliance documentation, support cases, legal review, research, and web archiving. Generated PDFs should be treated as point-in-time webpage records and interpreted together with the exact URL, timestamp, conversion settings, result key, and supporting technical evidence. # IP WHOIS | RDAP / WHOIS IP Intelligence Tool [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/PydVA7QCunrcl0Lz-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/PydVA7QCunrcl0Lz-image.png) The platform available at **[https://dash.niamonx.io/ip\_whois](https://dash.niamonx.io/ip_whois)** — known as **IP WHOIS** — is an IP intelligence and registration lookup tool within the NiamonX platform. It allows users to search RDAP / WHOIS information for IPv4 and IPv6 addresses, including network ranges, CIDR blocks, IP version, country, network name, allocation type, registration status, events, notices, remarks, related entities, contacts, abuse contacts, administrative contacts, technical contacts, RDAP links, and raw JSON data. ## Overview of the Service **IP WHOIS** is designed to help users investigate the public registration and network ownership information associated with an IP address. The tool retrieves structured RDAP / WHOIS data and presents it in an analyst-friendly interface. It is useful for cybersecurity investigations, OSINT research, incident response, SOC triage, abuse reporting, infrastructure mapping, network ownership checks, threat intelligence enrichment, compliance review, and technical due diligence. Instead of manually querying multiple WHOIS or RDAP endpoints, users can enter a single IP address and receive a structured summary of the network, related objects, contacts, events, statuses, and remarks. The tool is especially helpful when users need to answer questions such as: - Which network range contains this IP address? - What CIDR block is associated with the IP? - Which organization or registry is linked to the network? - Is there an abuse contact for reporting malicious activity? - What administrative or technical contacts are listed? - What country is associated with the registration data? - What RDAP links are available for verification? - What registration events or update events exist? - What raw JSON data was returned by the source? - Which contacts can be exported for reporting or escalation? --- ## 🔍 How the Tool Works When a user enters an IPv4 or IPv6 address, IP WHOIS validates the input and performs an RDAP / WHOIS lookup. The result is parsed and displayed in multiple structured sections. Example query: ```text IP Address: 1.1.1.1 ``` Example result summary: ```text Range: 1.1.1.0 - 1.1.1.255 CIDR: 1.1.1.0/24 Name: APNIC-LABS Type: ASSIGNED PORTABLE Country: AU IP Version: v4 Objects: 3 ``` The tool may display: - Network range - Network CIDR - Start IP - End IP - IP version - Network name - Allocation type - Country - ASN information, when available - Related RDAP links - Registration events - Network status - Notices - Remarks - Contact objects - E-mail addresses - Phone numbers - Physical addresses - Raw JSON response - Local query history --- ## 🧩 Supported Input IP WHOIS supports direct lookup of IP addresses only. Supported input types: - IPv4 - IPv6 Valid examples: ```text 1.1.1.1 ``` ```text 8.8.8.8 ``` ```text 2606:4700:4700::1111 ``` ```text 2001:4860:4860::8888 ``` Unsupported examples: ```text example.com ``` ```text https://1.1.1.1 ``` ```text 1.1.1.1/24 ``` ```text cloudflare.com ``` ```text localhost ``` ```text 999.999.999.999 ``` Important validation rule: ```text Only IPv4 or IPv6. ``` The tool is not intended for domain WHOIS lookups. Domain names, URLs, hostnames, and CIDR ranges should be checked with other dedicated tools. --- ## 📊 Summary Section The **Summary** section provides a compact overview of the IP lookup result. Example: ```text 1.1.1.0 - 1.1.1.255 ASN — CIDR 1.1.1.0/24 Entities: 0 22:42:09 ``` Typical fields include:
FieldDescription
RangeThe IP range containing the queried address
ASNAutonomous System Number, if available
CIDRNetwork block in CIDR notation
EntitiesNumber of related objects or contacts
TimeLookup or display time
The Summary section is useful for quick triage. It allows analysts to understand the basic network assignment without opening the full raw response. --- ## 🧾 Query Details The **Query** section displays the main lookup data returned for the IP address and associated network. Example: ```text Query: 1.1.1.0 - 1.1.1.255 ASN: — ASN CIDR: — ASN CC: — ASN Registry: — ASN Date: — ASN Description: — Entities Count: 0 Network CIDR: 1.1.1.0/24 Start: 1.1.1.0 End: 1.1.1.255 IP Version: v4 ``` This section helps users separate the queried IP from the larger network block it belongs to. --- ## 🌐 Network Information The network block describes the IP allocation or assignment returned by RDAP / WHOIS. Example: ```text Name: APNIC-LABS Type: ASSIGNED PORTABLE Network: ASSIGNED PORTABLE Handle: 1.1.1.0 - 1.1.1.255 Parent: - CIDR: 1.1.1.0/24 Start: 1.1.1.0 End: 1.1.1.255 Version: v4 Country: AU ``` ### Name The network name identifies the registered network object. Example: ```text APNIC-LABS ``` The name may represent a registry project, organization, network allocation, ISP block, cloud provider range, hosting provider range, enterprise network, research prefix, or another registered resource. --- ### Type The type field describes the allocation or assignment category. Example: ```text ASSIGNED PORTABLE ``` Common type values may include: - ALLOCATED - ASSIGNED - ASSIGNED PORTABLE - DIRECT ALLOCATION - DIRECT ASSIGNMENT - LEGACY - RESERVED - PROVIDER AGGREGATABLE The exact values depend on the registry and RDAP source. --- ### Handle The handle is the identifier of the network object. Example: ```text 1.1.1.0 - 1.1.1.255 ``` In some registries, the handle may be a textual object ID. In other cases, it may resemble the network range itself. --- ### Parent The parent field shows the parent network object if one is available. Example: ```text Parent: - ``` A missing parent value does not necessarily mean that no broader allocation exists. It may simply mean that the source did not expose parent information in the returned object. --- ### CIDR CIDR shows the network prefix that contains the queried IP address. Example: ```text 1.1.1.0/24 ``` CIDR is useful for: - firewall rules; - network grouping; - threat intelligence enrichment; - infrastructure mapping; - abuse escalation; - IP block analysis; - understanding the size of the allocation. --- ### Start and End Start and End define the first and last IP addresses in the returned network range. Example: ```text Start: 1.1.1.0 End: 1.1.1.255 ``` This helps users understand whether a suspicious IP belongs to a small network, a large provider allocation, a cloud range, or a specific assigned block. --- ### IP Version The version field identifies whether the network is IPv4 or IPv6. Example: ```text Version: v4 ``` Possible values: ```text v4 v6 ``` --- ### Country The country field displays the country code associated with the network registration. Example: ```text Country: AU ``` Important note: the country value in WHOIS / RDAP data does not always represent the physical location of the server. It may represent the registration country, registry region, organization address, or administrative contact location. For accurate infrastructure geolocation, the country field should be compared with IP geolocation, routing data, ASN information, DNS records, latency, and other technical signals. --- ## 🛰️ ASN Information ASN data describes the Autonomous System associated with an IP address, when available. The tool may display: - ASN - ASN CIDR - ASN country code - ASN registry - ASN date - ASN description Example: ```text ASN: AS13335 ASN CIDR: 1.1.1.0/24 ASN CC: AU ASN Registry: APNIC ASN Date: 2011-08-11 ASN Description: CLOUDFLARENET ``` In some responses, ASN fields may be unavailable. Example: ```text ASN: — ASN CIDR: — ASN CC: — ASN Registry: — ASN Date: — ASN Description: — ``` Missing ASN data does not always mean that the IP is not routed. It may mean that the selected RDAP / WHOIS response did not include ASN enrichment. For complete routing analysis, ASN data should be verified with BGP, RPKI, route collectors, passive DNS, and external network intelligence sources. --- ## 🔗 Links The Links section displays RDAP or registry URLs related to the network or entity objects. Example: ```text https://rdap.apnic.net/entity/AIC3-AP ``` Links are useful for: - opening the original registry record; - verifying NiamonX-parsed data against the source; - reviewing full RDAP entity pages; - checking related organization records; - copying references into investigation reports. Interface hint: ```text Hover your cursor over the open link icon to open the link in a new tab. ``` --- ## 📅 Events Events describe registration-related actions associated with the network or contact objects. Possible event types may include: - registration; - last changed; - last updated; - allocation; - assignment; - validation; - expiration, where applicable. Example display: ```text Events: action — - action — - ``` Some RDAP responses contain complete event dates. Others may return incomplete or minimal event objects. Events are useful for: - checking when a network was registered; - identifying recent ownership or metadata changes; - supporting timeline analysis; - enriching incident reports; - assessing whether infrastructure appears newly created or long-standing. Important note: event availability depends on the source registry. Not every RDAP / WHOIS response includes complete event data. --- ## ✅ Status The Status section shows the current state of the network object. Example: ```text Status: active ``` Common statuses may include: - active; - allocated; - assigned; - validated; - reserved; - deprecated; - transferred; - locked; - inactive. Status values depend on the registry and RDAP implementation. A status such as `active` usually means the registration object is currently active in the registry database. It does not automatically mean that every IP inside the range is currently reachable, safe, or in use. --- ## 📌 Notices Notices contain registry-provided informational messages, legal notices, terms of use, source information, or disclaimers. Example: ```text Notices: No ``` If notices are present, they may include: - registry terms; - copyright statements; - acceptable use notices; - rate limit warnings; - referral information; - data accuracy notes; - RDAP service disclaimers. Users should review notices when using WHOIS / RDAP data in legal, compliance, or official reporting workflows. --- ## 📝 Remarks Remarks contain additional registry-provided descriptions or notes about the network. Example: ```text description: APNIC and Cloudflare DNS Resolver project, Routed globally by AS13335/Cloudflare, Research prefix for APNIC Labs remarks: --------------- All Cloudflare abuse reporting can be done via resolver-abuse@cloudflare.com --------------- ``` Remarks are often highly valuable because they may contain: - project descriptions; - abuse reporting instructions; - routing notes; - service explanations; - operational comments; - special handling instructions; - registry-specific context. For investigations, remarks should be reviewed carefully. They may contain the correct abuse escalation channel even when the main contact object is generic. --- ## 👥 Objects and Contacts The **Objects** section shows related RDAP entities such as organizations, abuse contacts, administrative contacts, technical contacts, NOC contacts, and registrants. Example: ```text Objects: 3 ``` Objects may include: - organization; - registrant; - abuse contact; - administrative contact; - technical contact; - infrastructure contact; - NOC contact; - group; - role account. The tool supports searching and filtering objects by role. Example: ```text Search... Role: all ``` --- ## 🧑‍💼 Example Contact Object Example object: ```text AIC3-AP APNICRANDNET Infrastructure Contact Kind: group Roles: administrative technical E-mails: research@apnic.net Phones: +61 7 3858 3100 Addresses: 6 Cordelia St South Brisbane QLD 4101 Links: https://rdap.apnic.net/entity/AIC3-AP ``` A contact object may contain:
FieldDescription
HandleUnique entity identifier
NameDisplay name of the entity
KindEntity type, such as group or org
RolesRDAP roles assigned to the entity
E-mailsContact e-mail addresses
PhonesListed phone numbers
AddressesPostal or office addresses
LinksRDAP links for the entity
StatusEntity status, if available
EventsEntity registration or update events
RemarksAdditional registry-provided notes
--- ## 🏷️ RDAP Roles Objects use standard RDAP role designations. Common roles include:
RoleMeaning
registrantOrganization or entity associated with the registration
administrativeAdministrative contact
technicalTechnical contact
abuseAbuse reporting contact
nocNetwork Operations Center contact
billingBilling contact
registrarRegistrar-related entity
resellerReseller-related entity
sponsorSponsoring organization
Example: ```text Roles: administrative technical ``` Another example: ```text Roles: abuse ``` Roles are important for choosing the correct escalation path. For malicious activity, the abuse role is usually the most relevant contact type. --- ## 🚨 Abuse Contacts Abuse contacts are used to report malicious, unauthorized, or harmful activity associated with an IP address or network. Example: ```text IRT-APNICRANDNET-AU Roles: abuse E-mails: helpdesk@apnic.net ``` Abuse contacts may be used for reports related to: - phishing; - malware; - spam; - scanning; - brute-force attacks; - botnet activity; - fraud infrastructure; - credential theft; - impersonation pages; - abusive hosting; - command-and-control infrastructure. Before sending an abuse report, users should collect supporting evidence such as timestamps, URLs, logs, packet captures, screenshots, HTTP headers, DNS data, and affected systems. --- ## 📤 Copy and Export Features IP WHOIS supports data extraction features that help users move results into reports or external workflows. Available actions may include: - Copy summary - Copy JSON - Copy contacts - Export contacts to CSV - View Raw JSON These features are useful for: - incident reports; - SOC tickets; - case management systems; - legal documentation; - abuse reports; - compliance records; - internal escalation; - customer support cases; - threat intelligence enrichment. --- ## 📄 Export Contacts to CSV The **Export contacts to CSV** function allows users to export aggregated contact information from the objects section. The exported data may include: - object handle; - object name; - kind; - roles; - e-mail addresses; - phone numbers; - addresses; - links; - remarks. This is useful when an investigation involves multiple entities and the analyst needs to preserve contact data in a structured format. Example use cases: - exporting abuse contacts for reporting; - collecting technical contacts for escalation; - saving organization details for a case file; - sharing contact information with an internal SOC team; - building an investigation evidence package. --- ## 🧬 Raw JSON The **Raw JSON** view displays the original structured response returned by the RDAP / WHOIS source. Raw JSON is useful for: - advanced technical review; - verifying parsed fields; - debugging incomplete records; - extracting fields not shown in the UI; - preserving source data; - integrating with other systems; - evidence storage; - analyst validation. When accuracy matters, users should compare the visual UI fields with the raw JSON response. --- ## 🕓 Local IP History IP WHOIS stores recent IP lookups locally in the browser. Example interface section: ```text IP History Filter... ``` History helps users: - repeat previous lookups; - filter investigated IPs; - continue an investigation session; - compare multiple IPs; - avoid retyping addresses. Since the history is stored locally, it may be removed when browser data is cleared. It may also not sync between devices or browser profiles. Security recommendation: clear local history on shared or untrusted devices when investigating sensitive IPs, customer incidents, or confidential infrastructure. --- ## 🔎 Common Use Cases IP WHOIS supports many practical cybersecurity and OSINT workflows. ### IP Ownership Investigation Identify the registered network, organization, allocation type, and contact objects associated with an IP address. ### SOC Alert Triage Enrich suspicious IP addresses from alerts, logs, firewall events, EDR detections, IDS events, or SIEM correlations. ### Abuse Reporting Find abuse contacts and supporting registration details for reporting malicious activity. ### Phishing Infrastructure Analysis Investigate IP addresses hosting phishing pages, fake login portals, clone websites, or malicious redirects. ### Malware Infrastructure Review Check IP addresses linked to malware delivery, command-and-control servers, botnets, or payload hosting. ### Brand Protection Identify infrastructure behind impersonation websites, fake stores, unauthorized brand pages, or fraudulent campaigns. ### Network Troubleshooting Check which network block an IP belongs to and review registration details. ### Threat Intelligence Enrichment Add WHOIS / RDAP context to indicators of compromise. ### Compliance and Audit Preserve registration data for investigation files, audit trails, incident documentation, or legal review. ### OSINT Research Map public infrastructure, investigate hosting providers, and identify related contact entities. --- ## 🧠 Practical Investigation Workflow A recommended IP WHOIS workflow should follow these steps. ### 1. Enter a Valid IP Address Use only IPv4 or IPv6. Example: ```text 1.1.1.1 ``` Avoid domains, URLs, hostnames, and CIDR input. --- ### 2. Review the Summary Check the returned range, CIDR, ASN, entity count, and lookup time. Example: ```text Range: 1.1.1.0 - 1.1.1.255 CIDR: 1.1.1.0/24 Entities: 3 ``` --- ### 3. Review Network Details Check the network name, allocation type, country, start IP, end IP, version, and handle. Example: ```text Name: APNIC-LABS Type: ASSIGNED PORTABLE Country: AU Version: v4 ``` --- ### 4. Check ASN Information Review ASN-related fields when available. Example: ```text ASN Description: description of the autonomous system. ``` If ASN data is missing, verify routing information using additional BGP or ASN lookup tools. --- ### 5. Review Status and Events Check whether the network is active and whether registration or update events are available. Example: ```text Network Status: active ``` Events can support timeline analysis and help identify recent changes. --- ### 6. Inspect Remarks Read remarks carefully because they may contain special instructions, abuse reporting information, routing notes, or project descriptions. Example: ```text All Cloudflare abuse reporting can be done via resolver-abuse@cloudflare.com ``` --- ### 7. Inspect Objects and Roles Review all related contacts and filter by role when necessary. Important roles: ```text abuse administrative technical registrant noc ``` For reporting malicious activity, prioritize abuse contacts. --- ### 8. Copy or Export Data Use copy and export features to preserve results. Recommended items to save: ```text IP address Network range CIDR Network name Country ASN data Status Events Remarks Contact objects Abuse e-mails Raw JSON Lookup timestamp ``` --- ### 9. Validate With Additional Evidence For professional investigations, combine IP WHOIS data with: - DNS records; - passive DNS; - HTTP headers; - TLS certificate data; - screenshots; - webpage captures; - malware logs; - SIEM events; - firewall logs; - BGP routing data; - ASN intelligence; - geolocation data; - threat intelligence feeds. WHOIS / RDAP data is only one part of the investigation. --- ## 📌 Field Interpretation Guide ### ASN Description The ASN Description field describes the autonomous system, when available. Example meaning: ```text Description of the autonomous system. ``` This may identify an ISP, cloud provider, hosting provider, enterprise network, CDN, or other routing organization. --- ### Network Status Network Status shows the current status values associated with the network object. Example: ```text active ``` Status values can indicate whether the object is active, allocated, assigned, reserved, or otherwise marked by the registry. --- ### Events Events show registration and change-related dates when the source provides them. Possible examples: ```text registration last changed last updated ``` Events are useful for understanding when the object was created or modified. --- ### Objects Objects represent entities connected to the network. Examples: ```text org abuse admin technical noc registrant ``` Objects follow standard RDAP role designations and may contain names, e-mails, phones, addresses, links, statuses, events, and remarks. --- ## ⚠️ Limitations and Important Notes WHOIS / RDAP data should be interpreted carefully. Important limitations: - WHOIS / RDAP data may be incomplete. - ASN data may be missing from some responses. - Contact information may be outdated. - Some registries redact personal data. - Some records contain generic abuse contacts. - Country fields do not always indicate server location. - Cloud and CDN IPs may represent shared infrastructure. - Hosting providers may assign IPs to many different customers. - The listed organization may not be the actual end user. - Dynamic IPs may change ownership or customer assignment. - Events may be incomplete or unavailable. - RDAP sources may return inconsistent field names. - Server-side errors may occur. - Some registries may rate-limit or temporarily fail. In case of a server-side `500` error, repeat the request. Example note: ```text In case of a 500 error on the server side, please repeat your request. ``` --- ## 🛡️ Security, Privacy & Responsible Use IP WHOIS is intended for lawful cybersecurity, OSINT, compliance, reporting, infrastructure analysis, and network investigation workflows. Acceptable use cases include: - checking your own IP infrastructure; - investigating suspicious IP addresses; - enriching SOC alerts; - identifying abuse contacts; - preparing abuse reports; - reviewing public registration data; - mapping public network ownership; - supporting incident response; - documenting threat intelligence findings; - validating public infrastructure records. Users should follow responsible use principles: - Do not harass contacts listed in WHOIS / RDAP data. - Use abuse contacts only for legitimate abuse reports. - Include clear evidence when submitting reports. - Do not treat WHOIS data as definitive proof of attribution. - Do not expose sensitive investigation notes unnecessarily. - Store exported contact data securely. - Respect registry terms and privacy restrictions. - Validate critical findings with multiple independent sources. WHOIS / RDAP data can support investigations, but it should not be used alone to accuse an organization or individual of malicious activity. --- ## 🧾 Recommended Abuse Report Context When using IP WHOIS to prepare an abuse report, include enough evidence for the receiving team to understand and verify the issue. Recommended report fields: ```text Source IP: 1.1.1.1 Observed activity: phishing / malware / scanning / spam / abuse Timestamp with timezone: 17.06.2026, 22:42:09 Affected system or URL: relevant target Evidence: logs, screenshots, headers, URLs, samples WHOIS range: 1.1.1.0 - 1.1.1.255 CIDR: 1.1.1.0/24 Network name: APNIC-LABS Abuse contact: listed abuse e-mail Additional notes: analyst summary ``` A high-quality abuse report should be factual, concise, and evidence-based. --- ## ⚙️ Technical Highlights - IP WHOIS / RDAP lookup tool - Available at `dash.niamonx.io/ip_whois` - Supports IPv4 and IPv6 validation - Retrieves public IP registration data - Displays network range - Displays CIDR block - Displays start and end IP - Shows IP version - Shows network name - Shows allocation or assignment type - Shows country code - Shows ASN fields when available - Shows ASN description when available - Shows entity count - Displays RDAP links - Displays registration events - Displays network status - Displays notices - Displays remarks - Displays related objects and contacts - Supports object search - Supports role filtering - Aggregates contact e-mails - Aggregates phone numbers - Shows physical addresses when available - Allows copying summary - Allows copying JSON - Allows copying contacts - Supports contact export to CSV - Provides Raw JSON view - Stores IP history locally - Suitable for OSINT, SOC, incident response, abuse reporting, infrastructure mapping, and threat intelligence --- ## 📌 Usage Hints - Enter only a valid IPv4 or IPv6 address. - Do not enter domains, URLs, hostnames, or CIDR ranges. - Use the Summary section for quick triage. - Use the Network section to understand the assigned range. - Check CIDR before creating firewall or detection rules. - Review ASN Description to understand the autonomous system. - Review Network Status to understand the current object state. - Review Events for registration and update context. - Review Objects to find organization, abuse, administrative, and technical contacts. - Use role filtering to focus on abuse or technical contacts. - Check Remarks for special reporting instructions. - Open RDAP links to verify source records. - Copy summary for reports. - Copy JSON for technical analysis. - Export contacts to CSV for case management. - Use Raw JSON when parsed UI data appears incomplete. - Repeat the request if a server-side 500 error occurs. - Treat WHOIS / RDAP data as supporting evidence, not final attribution. - Combine results with DNS, HTTP, TLS, BGP, passive DNS, and threat intelligence data. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX IP WHOIS** is an RDAP / WHOIS lookup tool for IPv4 and IPv6 addresses. It provides structured IP registration intelligence, including network range, CIDR, start and end IP, IP version, network name, allocation type, country, ASN fields, status, events, notices, remarks, RDAP links, related objects, contacts, e-mails, phone numbers, addresses, raw JSON, local history, copy options, and CSV export. The tool is designed for OSINT research, SOC workflows, incident response, abuse reporting, phishing investigations, malware infrastructure analysis, brand protection, compliance documentation, network troubleshooting, and threat intelligence enrichment. Results should be interpreted as public registration context and combined with additional technical evidence before making conclusions about ownership, infrastructure usage, or attribution. # Subdomains Extended | Subdomain Discovery & DNS Inventory Tool [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/EJjNi5ThtHcjigGa-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/EJjNi5ThtHcjigGa-image.png) The platform available at **[https://dash.niamonx.io/subdomains\_extended](https://dash.niamonx.io/subdomains_extended)** — known as **Subdomains Extended** — is a domain intelligence and DNS inventory tool within the NiamonX platform. It discovers subdomains for a target domain, resolves DNS records, and presents a clear technical inventory for each discovered hostname. The tool helps users identify exposed subdomains, review DNS configuration, map public infrastructure, detect forgotten assets, verify mail and security-related records, and support OSINT, SOC, incident response, compliance, and attack surface management workflows. --- ## Overview of the Service **Subdomains Extended** is designed to perform a more detailed subdomain audit than a basic subdomain list. Instead of only returning discovered hostnames, it enriches each subdomain with DNS resolution data. For every discovered subdomain, the tool may show: - Hostname - IPv4 addresses - IPv6 addresses - CNAME targets - MX records - TXT records - NS records This makes the module useful not only for discovery, but also for understanding how each subdomain is connected to infrastructure, cloud services, mail systems, verification records, third-party services, CDN providers, and DNS delegation. The tool is useful for: - OSINT analysts - SOC teams - Threat intelligence teams - Incident response teams - Bug bounty and security researchers - Brand protection teams - Compliance departments - System administrators - DevOps engineers - DNS administrators - Attack surface management teams - Infrastructure owners - Technical support teams --- ## 🔍 How the Tool Works When a user enters a domain and starts an audit, Subdomains Extended searches for known or discoverable subdomains and resolves DNS records for each result. Example audit input: ```text Domain: niamonx.io ``` Example summary result: ```text Domain: niamonx.io Total: 2 17.06.2026, 22:45:18 ``` Example discovered subdomains: ```text _dmarc.niamonx.io poreva.niamonx.io ``` Example resolved DNS data: ```text poreva.niamonx.io IPv4: 172.67.153.184 104.21.12.231 IPv6: 2606:4700:3030::ac43:99b8 2606:4700:3033::6815:ce7 ``` The system performs a thorough audit and may require time to collect, resolve, and organize results. Example interface note: ```text The system performs a thorough audit; please wait while results are collected and resolved. ``` --- ## 🧩 What Can Be Audited Subdomains Extended accepts a root domain as input. Valid examples: ```text niamonx.io ``` ```text example.com ``` ```text company.org ``` ```text security.example.net ``` Unsupported or invalid examples: ```text https://niamonx.io ``` ```text http://example.com/page ``` ```text 192.168.1.1 ``` ```text user@example.com ``` ```text localhost ``` ```text *.example.com ``` Recommended input format: ```text domain.tld ``` Users should enter only the domain name, without protocol, path, wildcard prefix, query parameters, or URL fragments. --- ## ⚙️ Main Audit Function ### Run Subdomain Audit The main action starts the subdomain discovery and DNS resolution process. Example: ```text Run Subdomain Audit Domain: niamonx.io ``` After running the audit, the tool returns a summary and a structured table of discovered subdomains with DNS records. The audit may include: - subdomain discovery; - DNS resolution; - IPv4 lookup; - IPv6 lookup; - CNAME lookup; - MX lookup; - TXT lookup; - NS lookup; - result grouping; - local history storage. --- ## 🚦 Plan Limits and Usage Subdomains Extended uses plan-based query limits. Example: ```text Plan: Sentinel Used: 1 / 60 Remaining: 59 ``` Important points: - Each audit may consume plan quota. - Query limits depend on the active user plan. - More thorough audits may require more processing time. - Large domains may produce more results. - DNS resolution may take longer for domains with many records. - Repeated audits may consume additional quota. - Results may change over time because DNS and subdomain exposure are dynamic. Users should monitor remaining queries when auditing multiple domains, customer assets, investigation targets, or large infrastructure footprints. --- ## 📊 Summary Section The Summary section provides a compact overview of the audit result. Example: ```text Domain: niamonx.io Total: 2 17.06.2026, 22:45:18 ``` Typical fields include:
FieldDescription
DomainThe audited root domain
TotalNumber of discovered subdomains
TimestampDate and time when the audit was completed
The Summary section is useful for quick reporting and audit comparison. It allows users to see how many subdomains were discovered at a specific point in time. --- ## 📋 Subdomain Results Table The Subdomain Results table displays discovered hostnames and their resolved DNS records. Example table columns:
ColumnDescription
SubdomainDiscovered hostname
IPv4A records resolved for the hostname
IPv6AAAA records resolved for the hostname
CNAMECanonical name target
MXMail exchanger records
TXTText records
NSName server records
Example result: ```text Subdomain: _dmarc.niamonx.io IPv4: — IPv6: — CNAME: — MX: — TXT: v=DMARC1; p=none; NS: — ``` Another example: ```text Subdomain: poreva.niamonx.io IPv4: 172.67.153.184 104.21.12.231 IPv6: 2606:4700:3030::ac43:99b8 2606:4700:3033::6815:ce7 CNAME: — MX: — TXT: — NS: — ``` If a record type is not available, the interface displays: ```text — ``` This means that no value was returned for that specific DNS record type during the audit. --- ## 🔎 Result Pagination For domains with many discovered subdomains, results may be paginated. Example: ```text Page 1 of 1 Showing 1–2 of 2 ``` Pagination helps keep the interface readable when auditing larger domains. Possible pagination information includes: - current page; - total pages; - visible result range; - total discovered subdomains. For large domains, users should review all pages to avoid missing important records. --- ## 🧾 Details Panel The Details panel shows a focused view of one selected subdomain. Example: ```text Details Subdomain: poreva.niamonx.io IPv4: 172.67.153.184 104.21.12.231 IPv6: 2606:4700:3030::ac43:99b8 2606:4700:3033::6815:ce7 CNAME: — MX: — TXT: — NS: — ``` The Details panel is useful when a subdomain has many records or when the user needs to copy, inspect, or document a specific hostname. --- ## 🌐 Hostname The Hostname field shows the discovered subdomain. Example: ```text poreva.niamonx.io ``` Hostnames may represent: - public websites; - API endpoints; - staging environments; - development systems; - mail-related records; - CDN endpoints; - third-party service integrations; - verification records; - delegated DNS zones; - forgotten or legacy assets. Subdomain discovery is useful because organizations often expose services across many hostnames that are not visible from the main website. --- ## 🌍 IPv4 Records IPv4 records show A records resolved for the subdomain. Example: ```text 172.67.153.184 104.21.12.231 ``` IPv4 results help identify: - hosting providers; - CDN usage; - public-facing infrastructure; - shared IP ranges; - possible origin exposure; - network ownership; - security monitoring targets; - firewall or allowlist candidates. A subdomain can resolve to one IPv4 address or multiple IPv4 addresses. Multiple addresses may indicate load balancing, CDN usage, high availability, or provider-managed routing. --- ## 🌐 IPv6 Records IPv6 records show AAAA records resolved for the subdomain. Example: ```text 2606:4700:3030::ac43:99b8 2606:4700:3033::6815:ce7 ``` IPv6 results help users identify modern dual-stack infrastructure. IPv6 records are important because: - services may be reachable over IPv6 even when IPv4 is restricted; - firewall policies may differ between IPv4 and IPv6; - monitoring may miss IPv6 exposure; - misconfigured IPv6 services can create security gaps; - CDN and cloud services often publish IPv6 records automatically. Security teams should review both IPv4 and IPv6 records when assessing exposure. --- ## 🔁 CNAME Records CNAME records show canonical name targets for a subdomain. Example: ```text CNAME: app.example.hosting-provider.com ``` CNAME records are useful for identifying: - third-party services; - SaaS integrations; - CDN aliases; - cloud-hosted applications; - landing page platforms; - verification targets; - takeover risk indicators; - redirected service ownership. A missing CNAME is displayed as: ```text CNAME: — ``` Important security note: abandoned or misconfigured CNAME records may sometimes indicate potential subdomain takeover risk, especially when pointing to a third-party service that is no longer configured. Such findings should be validated carefully and responsibly. --- ## 📬 MX Records MX records show mail exchangers associated with a subdomain. Example: ```text MX: mail.example.com ``` MX records are useful for: - mail infrastructure mapping; - identifying mail providers; - detecting mail routing configuration; - reviewing security posture; - understanding subdomain-specific mail behavior; - verifying whether a subdomain can receive mail. A missing MX record is displayed as: ```text MX: — ``` For most normal application subdomains, MX records may be absent. This is expected. --- ## 🧾 TXT Records TXT records show text-based DNS records associated with a subdomain. Example: ```text v=DMARC1; p=none; ``` TXT records may contain: - DMARC policies; - SPF records; - DKIM selectors; - domain verification records; - security policies; - ownership verification tokens; - service integration tokens; - configuration metadata. Example discovered record: ```text Subdomain: _dmarc.niamonx.io TXT: v=DMARC1; p=none; ``` TXT records are especially important for e-mail security and domain ownership verification. Security teams should review TXT records for: - weak DMARC policies; - overly permissive SPF rules; - outdated verification tokens; - exposed internal metadata; - third-party service dependencies; - misconfigured mail security settings. --- ## 🛡️ DMARC Records Subdomains Extended may discover DMARC-related records such as `_dmarc.domain.tld`. Example: ```text _dmarc.niamonx.io TXT: v=DMARC1; p=none; ``` DMARC records are used to define domain-level e-mail authentication policy. A DMARC value such as: ```text v=DMARC1; p=none; ``` means that DMARC is present, but the policy is monitoring-only. It does not instruct receivers to quarantine or reject failing messages. Common DMARC policies include:
PolicyMeaning
p=noneMonitor only
p=quarantineTreat failing mail as suspicious
p=rejectReject failing mail
For stronger protection against spoofing, organizations often move from `p=none` to `p=quarantine` or `p=reject` after monitoring and validation. --- ## 🧭 NS Records NS records show name servers associated with a subdomain or delegated zone. Example: ```text NS: ns1.example.net ``` NS records are useful for: - identifying delegated subdomains; - mapping DNS providers; - finding separate DNS zones; - reviewing infrastructure ownership; - detecting forgotten delegations; - identifying third-party DNS dependencies. A missing NS record is displayed as: ```text NS: — ``` Delegated subdomains are important during security reviews because they may be managed separately from the main domain and may have different access controls, owners, or providers. --- ## 📚 Examples Section The tool includes examples that can prefill the audit form. Example interface note: ```text Examples Click to prefill the form, then run the audit. ``` Examples help users quickly understand the correct input format and run a test audit without manually typing a domain. --- ## 🕓 Local History Subdomains Extended stores recent audits locally in the user’s browser. Example: ```text History (local) Filter Stored only in your browser (last 50 audits). ``` Example history item: ```text niamonx.io Total: 2 17.06.2026, 22:45:18 ``` Local history helps users: - repeat previous audits; - compare recent results; - continue an investigation session; - quickly return to previously checked domains; - filter audit history; - preserve local workflow context. Because history is stored only in the browser, it may be removed when browser data is cleared, a different browser profile is used, or the user switches devices. On shared or untrusted devices, users should treat local history as sensitive and clear it after investigating confidential domains, client assets, or incident-related infrastructure. --- ## 🔐 Why Subdomain Discovery Matters Subdomains are often part of an organization’s public attack surface. Even when the main website is secure, exposed subdomains may reveal additional systems, legacy applications, development environments, staging panels, APIs, authentication portals, cloud services, or forgotten infrastructure. Subdomain discovery helps identify: - forgotten services; - exposed staging environments; - abandoned DNS records; - third-party integrations; - cloud-hosted applications; - vulnerable legacy systems; - shadow IT assets; - takeover-prone CNAME records; - mail security records; - DNS delegation risks; - undocumented public infrastructure. A complete subdomain inventory is an important foundation for attack surface management and defensive security. --- ## 🔎 Common Use Cases ### Attack Surface Inventory Create a list of public-facing subdomains and their DNS records to understand the visible infrastructure of a domain. ### OSINT Research Map publicly discoverable domain infrastructure during open-source intelligence investigations. ### SOC Triage Enrich alerts involving suspicious hostnames, unknown subdomains, or unusual DNS activity. ### Incident Response Check whether a suspicious subdomain is part of an organization’s known infrastructure. ### Brand Protection Identify suspicious, forgotten, or unexpected subdomains that may be used in impersonation, phishing, or brand abuse investigations. ### Subdomain Takeover Review Review CNAME records that point to third-party services and verify whether they are still properly configured. ### DNS Security Audit Inspect DNS records, including TXT, MX, NS, IPv4, and IPv6 records, for misconfigurations or unexpected exposure. ### E-mail Security Review Find DMARC, SPF, DKIM, MX, and TXT-related records that affect e-mail authentication and spoofing protection. ### Cloud and CDN Mapping Identify subdomains resolving to cloud providers, CDN endpoints, managed platforms, or external infrastructure. ### Compliance Documentation Create a record of public DNS exposure for compliance reviews, asset inventories, and audit documentation. ### DevOps and Infrastructure Review Help engineering teams identify public DNS entries and validate whether they match the intended infrastructure state. --- ## 🧠 Recommended Audit Workflow A practical Subdomains Extended workflow should follow these steps. ### 1. Enter the Domain Use only the domain name. Example: ```text niamonx.io ``` Do not include: ```text https:// http:// /path ?query=value #fragment * ``` --- ### 2. Run the Audit Start the audit using the main action button. Example: ```text Run Subdomain Audit ``` The tool will collect discovered subdomains and resolve their DNS records. --- ### 3. Review the Summary Check the audited domain, total number of discovered subdomains, and timestamp. Example: ```text Domain: niamonx.io Total: 2 17.06.2026, 22:45:18 ``` This gives a quick overview of the result set. --- ### 4. Review the Subdomain Table Inspect each discovered hostname and its DNS records. Important columns: ```text Subdomain IPv4 IPv6 CNAME MX TXT NS ``` Look for unexpected records, unknown hostnames, third-party dependencies, mail records, and delegated zones. --- ### 5. Open Details for Important Subdomains Use the Details panel to inspect a selected subdomain more closely. Example: ```text Subdomain: poreva.niamonx.io IPv4: 172.67.153.184 104.21.12.231 IPv6: 2606:4700:3030::ac43:99b8 2606:4700:3033::6815:ce7 ``` --- ### 6. Review CNAME Records CNAME records are especially important for third-party service mapping and takeover-risk review. Questions to ask: - Does the CNAME point to a known provider? - Is the third-party service still active? - Is the target properly configured? - Is the subdomain still needed? - Does ownership of the service match the organization? --- ### 7. Review TXT Records TXT records can reveal mail policies, verification records, and security configuration. Important records to review: ```text DMARC SPF DKIM domain verification service ownership tokens ``` Example: ```text v=DMARC1; p=none; ``` --- ### 8. Review MX Records MX records should be checked to understand mail routing and possible subdomain-specific mail handling. Questions to ask: - Does this subdomain need to receive mail? - Is the mail provider expected? - Are mail records consistent with the organization’s policy? - Are unused mail routes exposed? --- ### 9. Review NS Records NS records may indicate delegated subdomains. Questions to ask: - Is this subdomain intentionally delegated? - Who manages the delegated zone? - Is the DNS provider still active? - Are there stale delegations? - Does the delegated zone follow the same security standards? --- ### 10. Compare With Asset Inventory Compare discovered results against the organization’s official asset list. Focus on: - unknown subdomains; - unowned services; - staging environments; - legacy systems; - abandoned records; - cloud services; - unexpected IPs; - missing documentation. --- ### 11. Save or Document Findings For professional workflows, document important results with timestamp and context. Recommended record: ```text Domain: niamonx.io Audit time: 17.06.2026, 22:45:18 Total subdomains: 2 Subdomain: poreva.niamonx.io IPv4: 172.67.153.184, 104.21.12.231 IPv6: 2606:4700:3030::ac43:99b8, 2606:4700:3033::6815:ce7 CNAME: — MX: — TXT: — NS: — ``` --- ## 🚨 Security Review Checklist When using Subdomains Extended for security auditing, review the following areas. ### Unknown Subdomains Check whether every discovered subdomain is known and authorized. Questions: - Who owns this subdomain? - Which team manages it? - Is it documented? - Is it still required? - Does it expose a service? --- ### Staging and Development Systems Look for names such as: ```text dev test stage staging qa uat demo internal admin panel backup old legacy ``` Such systems are often less protected than production environments and may expose sensitive data or outdated software. --- ### CNAME Takeover Indicators Review CNAME targets pointing to third-party services. Potential risk indicators: - target service no longer exists; - provider returns an unclaimed service page; - DNS points to a deleted cloud resource; - subdomain exists but application is not configured; - service ownership cannot be verified. Any suspected takeover risk should be validated safely and responsibly without exploiting the domain. --- ### Mail Security Records Review mail-related records: ```text MX SPF DKIM DMARC ``` Potential issues: - missing DMARC; - DMARC set to monitoring only; - overly broad SPF records; - outdated verification records; - unexpected mail providers; - inconsistent mail routing. --- ### IPv6 Exposure Check whether services are exposed through IPv6. Important questions: - Is IPv6 intentionally enabled? - Are IPv6 firewall rules aligned with IPv4? - Are monitoring and logging systems covering IPv6? - Are IPv6 addresses expected? IPv6 exposure is sometimes overlooked during security reviews. --- ### Delegated DNS Zones Review NS records for delegated subdomains. Potential issues: - forgotten delegated zones; - third-party DNS provider risk; - expired provider accounts; - inconsistent security controls; - weak access management; - stale name server configuration. --- ## 📊 Interpreting Results Correctly Subdomain audit results should be interpreted carefully. Important notes: - A discovered subdomain does not automatically mean a vulnerability exists. - A missing DNS record does not always mean the subdomain is unused. - DNS data changes over time. - CDN IP addresses may be shared by many customers. - Cloud provider addresses may not identify the final application owner. - TXT records may contain sensitive service metadata. - CNAME records require manual validation before risk conclusions. - IPv4 and IPv6 exposure should both be reviewed. - Some subdomains may resolve differently depending on DNS resolver, region, or time. - Some records may be cached or temporarily unavailable. - Passive discovery may miss private or newly created subdomains. - DNS inventory should be combined with HTTP, TLS, WHOIS, ASN, and screenshot evidence. Subdomains Extended provides strong DNS inventory context, but conclusions should be validated with additional tools and evidence. --- ## 🧾 Recommended Reporting Format When documenting a subdomain audit, use a consistent format. Example: ```text Domain: niamonx.io Audit timestamp: 17.06.2026, 22:45:18 Total discovered subdomains: 2 Subdomain: _dmarc.niamonx.io IPv4: — IPv6: — CNAME: — MX: — TXT: v=DMARC1; p=none; NS: — Subdomain: poreva.niamonx.io IPv4: 172.67.153.184, 104.21.12.231 IPv6: 2606:4700:3030::ac43:99b8, 2606:4700:3033::6815:ce7 CNAME: — MX: — TXT: — NS: — ``` For security reports, add analyst notes: ```text Finding: DMARC policy is set to p=none. Impact: Monitoring-only policy does not instruct receivers to reject or quarantine failing messages. Recommendation: Review DMARC reports and consider phased migration to p=quarantine or p=reject when ready. ``` --- ## 🛡️ Security, Privacy & Responsible Use Subdomains Extended is intended for lawful domain analysis, OSINT, cybersecurity, compliance, infrastructure review, and defensive security workflows. Acceptable use cases include: - auditing domains you own or are authorized to test; - reviewing public DNS exposure; - mapping public infrastructure; - investigating suspicious subdomains; - supporting incident response; - reviewing mail security records; - documenting compliance evidence; - identifying forgotten assets; - checking third-party dependencies; - supporting brand protection investigations. Users should follow responsible use principles: - Do not use the tool for unauthorized targeting or harassment. - Do not attempt to exploit discovered services. - Validate findings responsibly. - Do not claim a vulnerability based only on DNS data. - Do not abuse discovered contact or infrastructure information. - Store audit results securely when they involve client or sensitive domains. - Follow applicable laws, policies, and authorization boundaries. - Report security issues through proper disclosure channels. Subdomain discovery is a legitimate defensive and OSINT technique, but it must be used responsibly. --- ## ⚙️ Technical Highlights - Subdomain discovery tool - Available at `dash.niamonx.io/subdomains_extended` - Performs extended subdomain audits - Resolves DNS records per subdomain - Shows hostnames - Shows IPv4 addresses - Shows IPv6 addresses - Shows CNAME records - Shows MX records - Shows TXT records - Shows NS records - Displays audit summary - Shows total discovered subdomains - Displays timestamped results - Supports result pagination - Provides per-subdomain details - Includes example-based form prefilling - Stores local audit history - Keeps last 50 audits in the browser - Supports local history filtering - Uses plan-based query limits - Suitable for OSINT, SOC, attack surface management, incident response, compliance, DNS review, and infrastructure mapping --- ## 📌 Usage Hints - Enter only the domain name, not a full URL. - Do not include `https://`, `http://`, paths, query strings, or wildcard prefixes. - Use the Summary section to check total discovered subdomains. - Review all result pages for large domains. - Open Details for important subdomains. - Check IPv4 and IPv6 records separately. - Review CNAME records for third-party dependencies. - Validate CNAME records for possible takeover risk. - Review MX records for mail routing. - Review TXT records for DMARC, SPF, DKIM, and verification tokens. - Review NS records for delegated zones. - Treat missing records as “not returned,” not always as proof of absence. - Compare discovered subdomains with the official asset inventory. - Repeat audits over time because DNS exposure changes. - Store important findings with timestamp and context. - Clear local history on shared devices when auditing sensitive domains. - Use results responsibly and within authorization boundaries. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX Subdomains Extended** is an extended subdomain discovery and DNS inventory tool for public domains. It discovers subdomains, resolves DNS records, and presents a structured view of hostnames, IPv4 addresses, IPv6 addresses, CNAME targets, MX records, TXT records, and NS records. The tool is designed for OSINT research, attack surface management, SOC workflows, incident response, DNS security reviews, brand protection, compliance documentation, cloud and CDN mapping, e-mail security analysis, and infrastructure inventory. Results should be interpreted as point-in-time DNS intelligence and combined with additional technical evidence such as HTTP responses, TLS certificates, WHOIS data, ASN information, screenshots, passive DNS, and asset inventory records. # Subdomains Check | Subdomain Enumeration Tool [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/r6dSV1ohISCxjzgj-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/r6dSV1ohISCxjzgj-image.png) The platform available at **[https://dash.niamonx.io/subdomains\_check](https://dash.niamonx.io/subdomains_check)** — known as **Subdomains Check** — is a subdomain enumeration tool within the NiamonX platform. It helps users discover subdomains associated with a target domain by using internal services, archives, and available discovery sources. The tool returns a structured list of discovered hostnames and calculates useful metadata such as the main zone, subdomain depth, total number of subdomains, unique areas, and maximum depth. ## Overview of the Service **Subdomains Check** is designed to help users quickly enumerate known or discoverable subdomains for a domain. It provides a clean and focused inventory of hostnames without requiring the user to manually search archives, public datasets, or internal discovery sources. The tool is useful for OSINT research, attack surface mapping, security audits, SOC workflows, incident response, brand protection, bug bounty reconnaissance, DNS inventory review, compliance checks, and infrastructure documentation. Unlike tools that focus primarily on DNS resolution, Subdomains Check focuses on the discovery and organization of subdomain names. It helps users understand what hostnames exist or have been observed for a target domain and provides export options for further analysis. The module is especially useful when users need to answer questions such as: - Which subdomains are known for this domain? - How many subdomains were discovered? - Which hostnames may belong to the same main zone? - How deep are the discovered subdomains? - Are there unexpected, forgotten, or suspicious hostnames? - Can the discovered list be copied, exported, or reviewed as raw JSON? - Can the results be filtered and paginated for easier analysis? --- ## 🔍 How the Tool Works When a user enters a domain, Subdomains Check validates the input and performs enumeration through internal services and archives. The result is returned as a structured table of discovered subdomains. Example input: ```text Domain: niamonx.io ``` Example result: ```text Domain: niamonx.io Subdomains: 4 Unique Areas: 1 Maximum Depth: 3 22:49:02 ``` Example discovered subdomains: ```text dash.niamonx.io data-wells.niamonx.io poreva.niamonx.io support.niamonx.io ``` The tool calculates and displays: - discovered subdomain; - main zone; - hostname depth; - total subdomain count; - number of unique areas; - maximum depth; - query timestamp. --- ## 🧩 Supported Input Subdomains Check accepts domain names only. Correct input examples: ```text niamonx.io ``` ```text example.com ``` ```text sub.example.com ``` ```text company.org ``` Incorrect input examples: ```text https://niamonx.io ``` ```text http://example.com ``` ```text https://example.com/path ``` ```text *.example.com ``` ```text user@example.com ``` ```text 192.168.1.1 ``` ```text localhost ``` The interface guidance is: ```text Enter only the domain (example.com, sub.example.com) without the protocol. ``` Users should not include: ```text https:// http:// /path ?query=value #fragment * ``` Recommended format: ```text domain.tld ``` --- ## ⚙️ Main Function: Search and Check Subdomains The main action performs subdomain enumeration for the entered domain. Example: ```text Search and Check Subdomains Domain: niamonx.io ``` After the query is processed, the tool returns a result summary and a searchable table of discovered hostnames. The enumeration process may use: - internal discovery services; - archived records; - historical observations; - indexed subdomain sources; - platform-side enrichment logic. This makes the tool useful for quickly building an initial subdomain inventory. --- ## 📊 Result Summary The Result section provides a compact overview of the enumeration result. Example: ```text Result niamonx.io Subdomains: 4 22:49:02 ``` Detailed summary: ```text Domain: niamonx.io Subdomains: 4 Unique Areas: 1 Maximum Depth: 3 ``` Typical fields include:
FieldDescription
DomainThe domain that was checked
SubdomainsTotal number of discovered subdomains
Unique AreasNumber of unique main zones or grouped areas found in the result
Maximum DepthHighest hostname depth found among discovered subdomains
TimeTime when the result was generated or displayed
The summary is useful for quick reporting and comparing enumeration results across multiple domains or repeated audits. --- ## 📋 Subdomain Results Table The Subdomain Results table displays discovered hostnames and calculated metadata. Example table:
\#SubdomainZoneDepth
1dash.niamonx.ioniamonx.io3
2data-wells.niamonx.ioniamonx.io3
3poreva.niamonx.ioniamonx.io3
4support.niamonx.ioniamonx.io3
The table helps users quickly review discovered assets and understand their relationship to the main domain. --- ## 🌐 Subdomain Field The **Subdomain** column shows the discovered hostname. Example: ```text dash.niamonx.io ``` A subdomain may represent: - public website; - dashboard; - API endpoint; - support portal; - data service; - staging environment; - development environment; - mail-related host; - CDN endpoint; - customer portal; - documentation site; - third-party integration; - forgotten or legacy asset. Subdomains are important because they often reveal additional public infrastructure that is not visible from the main website. --- ## 🧭 Zone Field The **Zone** column shows the main domain or area associated with the discovered subdomain. Example: ```text dash.niamonx.io → zone: niamonx.io ``` Another example: ```text api.dev.example.com → zone: example.com ``` The zone helps group discovered hostnames under their main domain. This is useful when: - analyzing multiple related domains; - grouping results by root zone; - identifying which main domain a hostname belongs to; - preparing asset inventories; - filtering large subdomain lists; - separating results from different areas. --- ## 📏 Depth Field The **Depth** column shows the number of levels in the hostname. Example: ```text dash.niamonx.io → depth: 3 ``` Explanation: ```text dash.niamonx.io 1: dash 2: niamonx 3: io Depth: 3 ``` Another example: ```text api.dev.example.com → zone: example.com, depth: 4 ``` Explanation: ```text api.dev.example.com 1: api 2: dev 3: example 4: com Depth: 4 ``` Depth is useful for identifying deeply nested assets such as: ```text api.dev.example.com login.internal.stage.example.com cdn.assets.app.example.com ``` Deep hostnames may indicate development structures, environment separation, internal naming conventions, or complex infrastructure. --- ## 🔢 Unique Areas The **Unique Areas** value shows how many unique zones or grouped domain areas are present in the result. Example: ```text Unique Areas: 1 ``` For a simple domain audit, this value is often `1`, because all discovered subdomains belong to the same main domain. This field becomes more useful when results include hostnames that may be grouped into different areas or zones. Use cases: - grouping discovered assets; - identifying separate domain areas; - reviewing multi-zone results; - organizing large inventories; - understanding result diversity. --- ## 📈 Maximum Depth The **Maximum Depth** value shows the deepest hostname level found in the result set. Example: ```text Maximum Depth: 3 ``` If the tool discovers a deeply nested hostname such as: ```text api.dev.example.com ``` the maximum depth would be: ```text 4 ``` Maximum Depth helps users identify whether the domain has only simple subdomains or more complex nested infrastructure. Higher depth may indicate: - development environments; - segmented services; - nested application structure; - regional infrastructure; - customer-specific hostnames; - internal naming conventions; - legacy systems; - multi-level service organization. --- ## 🔎 Search and Filtering The results table includes a search field for filtering discovered subdomains. Example: ```text Search... ``` Search is useful when working with large result sets. Users can search for terms such as: ```text api ``` ```text dev ``` ```text support ``` ```text admin ``` ```text stage ``` Search can help analysts quickly locate interesting or risky hostnames. --- ## 📄 Pagination The table supports pagination for easier review of large result sets. Example: ```text 25 / page ``` Pagination helps users: - keep large results readable; - review results page by page; - avoid browser overload; - focus on smaller groups of hostnames; - manage large enumeration results. For complete analysis, users should review all result pages. --- ## 🕓 History of Domains Subdomains Check stores entered domains locally in the browser history. Example interface section: ```text History of Domains Filter... ``` History helps users: - repeat previous checks; - continue an investigation session; - quickly access recently analyzed domains; - filter prior domain inputs; - compare repeated checks over time. Because the history is local, it may be removed when browser data is cleared or when the user changes devices, browsers, or profiles. On shared or untrusted devices, users should treat domain history as sensitive and clear it after investigating confidential, customer-related, or incident-related domains. --- ## 📤 Copy and Export Features Subdomains Check supports several output actions for using results in reports or external tools. Available actions may include: - Copy JSON - Copy list - Export to CSV - View Raw JSON These features are useful for: - security reports; - SOC tickets; - incident response notes; - asset inventory systems; - bug bounty documentation; - compliance evidence; - attack surface management; - internal escalation; - further processing in scripts or tools. --- ## 📋 Copy List The **Copy list** option allows users to copy discovered subdomains as a plain list. Example output: ```text dash.niamonx.io data-wells.niamonx.io poreva.niamonx.io support.niamonx.io ``` This is useful for: - pasting into notes; - feeding into DNS tools; - importing into scanners; - sharing with a team; - creating allowlists or monitoring lists; - adding assets to documentation. --- ## 🧬 Copy JSON and Raw JSON The **Copy JSON** and **Raw JSON** options provide structured machine-readable data. Raw JSON is useful for: - technical validation; - automation; - integration with external systems; - preserving the original response; - debugging; - audit trails; - further enrichment; - evidence storage. JSON output may include: ```text domain subdomains zone depth total unique_areas maximum_depth timestamp ``` When accuracy matters, users should preserve the Raw JSON together with the visible table result. --- ## 📄 Export to CSV The **Export to CSV** option allows users to download the subdomain table in a spreadsheet-friendly format. The CSV may include: - index; - subdomain; - zone; - depth. Example CSV-style structure: ```text #,Subdomain,Zone,Depth 1,dash.niamonx.io,niamonx.io,3 2,data-wells.niamonx.io,niamonx.io,3 3,poreva.niamonx.io,niamonx.io,3 4,support.niamonx.io,niamonx.io,3 ``` CSV export is useful for: - reporting; - asset inventory; - spreadsheet review; - compliance records; - security audit evidence; - comparing results over time; - sharing findings with non-technical teams. --- ## 🔐 Why Subdomain Enumeration Matters Subdomains are a critical part of an organization’s public attack surface. A company may secure its main website while leaving older, forgotten, or poorly maintained subdomains exposed. Subdomain enumeration helps identify: - public applications; - admin panels; - dashboards; - APIs; - development environments; - staging systems; - support portals; - legacy services; - forgotten assets; - cloud-hosted systems; - third-party integrations; - takeover-prone records; - exposed documentation; - unexpected public endpoints. A complete subdomain inventory is often the first step in attack surface management and external security review. --- ## 🔎 Common Use Cases ### Attack Surface Mapping Build a list of known public subdomains for a domain and use it as the foundation for further DNS, HTTP, TLS, and security analysis. ### OSINT Research Discover publicly known hostnames connected to an organization, product, brand, or domain. ### SOC Triage Check whether a suspicious hostname belongs to a known domain and determine whether it should be investigated further. ### Incident Response Identify related subdomains during a security incident, phishing investigation, infrastructure review, or compromise assessment. ### Brand Protection Find suspicious or unexpected subdomains that may be relevant to impersonation, phishing, fraud, or unauthorized use of brand infrastructure. ### Bug Bounty Reconnaissance Collect in-scope hostnames for authorized security testing and further technical validation. ### Asset Inventory Create or update an inventory of public-facing hostnames associated with an organization. ### Compliance Review Document known public subdomains as part of security audits, risk reviews, or infrastructure governance. ### Shadow IT Detection Identify hostnames that may belong to undocumented systems, old projects, unmanaged services, or unknown teams. ### Follow-Up DNS Analysis Use the discovered list as input for tools that resolve IPv4, IPv6, CNAME, MX, TXT, NS, HTTP, TLS, or screenshot data. --- ## 🧠 Recommended Workflow A practical Subdomains Check workflow should follow these steps. ### 1. Enter the Domain Use only the domain name without protocol. Example: ```text niamonx.io ``` Do not enter: ```text https://niamonx.io ``` --- ### 2. Run the Enumeration Start the search and wait for the result. Example: ```text Search and Check Subdomains ``` The system will enumerate subdomains through internal services and archives. --- ### 3. Review the Result Summary Check the domain, total number of subdomains, unique areas, maximum depth, and timestamp. Example: ```text Domain: niamonx.io Subdomains: 4 Unique Areas: 1 Maximum Depth: 3 ``` --- ### 4. Review the Subdomain Table Inspect every discovered hostname. Example: ```text dash.niamonx.io data-wells.niamonx.io poreva.niamonx.io support.niamonx.io ``` Look for unusual names, old systems, staging environments, administrative portals, and unexpected assets. --- ### 5. Use Search for Interesting Keywords Search for common high-risk terms. Examples: ```text admin ``` ```text dev ``` ```text test ``` ```text stage ``` ```text backup ``` ```text internal ``` These terms may indicate systems that require closer review. --- ### 6. Review Zone and Depth Use the Zone and Depth fields to understand hostname structure. Example: ```text api.dev.example.com → zone: example.com, depth: 4 ``` Deep subdomains may reveal application structure, environment naming, or internal service organization. --- ### 7. Export the Results Use copy or export actions to preserve the data. Recommended exports: ```text Copy list Copy JSON Export to CSV Raw JSON ``` --- ### 8. Enrich the Subdomain List After enumeration, enrich the discovered list with additional tools. Recommended follow-up checks: - DNS A and AAAA records; - CNAME records; - MX, TXT, and NS records; - HTTP status codes; - screenshots; - TLS certificates; - IP WHOIS; - ASN information; - technology fingerprints; - historical DNS; - vulnerability scanning, when authorized. --- ### 9. Compare With Official Asset Inventory Compare discovered subdomains with the organization’s known asset list. Questions to ask: - Is this subdomain expected? - Who owns it? - Is it documented? - Is it still active? - Is it monitored? - Is it protected by the same security controls? - Does it expose sensitive functionality? - Should it be removed or consolidated? --- ## 🚨 Security Review Checklist When reviewing subdomain enumeration results, pay special attention to suspicious or high-risk patterns. ### Administrative Interfaces Look for hostnames such as: ```text admin.example.com dashboard.example.com panel.example.com portal.example.com login.example.com ``` These may expose authentication portals or administrative systems. --- ### Development and Testing Environments Look for names such as: ```text dev.example.com test.example.com stage.example.com staging.example.com qa.example.com uat.example.com demo.example.com ``` These systems may have weaker security controls than production environments. --- ### Legacy or Forgotten Assets Look for names such as: ```text old.example.com legacy.example.com backup.example.com archive.example.com temp.example.com ``` Legacy assets may contain outdated software, expired certificates, weak authentication, or forgotten services. --- ### Internal-Looking Names Look for hostnames such as: ```text internal.example.com intranet.example.com vpn.example.com private.example.com corp.example.com ``` Even if the name suggests internal use, the hostname may still be publicly discoverable and should be reviewed. --- ### API and Data Services Look for names such as: ```text api.example.com data.example.com graphql.example.com db.example.com storage.example.com files.example.com ``` These may expose backend services, APIs, file storage, or data-related endpoints. --- ### Customer or Tenant Subdomains Look for patterns such as: ```text customer1.example.com client.example.com tenant.example.com org.example.com ``` Tenant-based subdomains may require special handling, access controls, and monitoring. --- ## 📊 Interpreting Results Correctly Subdomain enumeration results should be interpreted carefully. Important notes: - A discovered subdomain does not automatically mean the service is active. - A discovered subdomain does not automatically mean a vulnerability exists. - Some hostnames may be historical or archived. - Some subdomains may no longer resolve in DNS. - Some subdomains may be protected by access controls. - Internal services may still have public DNS names. - Results can change over time. - Discovery sources may not be complete. - Enumeration may miss newly created or private subdomains. - Hostname depth does not indicate risk by itself. - Zone grouping helps organization but does not prove ownership. - Further validation is required before making security conclusions. Subdomains Check provides a discovery layer. For deeper investigation, combine results with DNS resolution, HTTP checks, TLS inspection, screenshots, IP WHOIS, ASN data, and authorized security testing. --- ## 🧾 Recommended Reporting Format When documenting results, use a consistent structure. Example: ```text Domain: niamonx.io Enumeration time: 22:49:02 Total subdomains: 4 Unique areas: 1 Maximum depth: 3 Discovered subdomains: 1. dash.niamonx.io | Zone: niamonx.io | Depth: 3 2. data-wells.niamonx.io | Zone: niamonx.io | Depth: 3 3. poreva.niamonx.io | Zone: niamonx.io | Depth: 3 4. support.niamonx.io | Zone: niamonx.io | Depth: 3 ``` For security reports, add analyst notes: ```text Observation: The domain has 4 discovered subdomains. All discovered hostnames belong to the zone niamonx.io and have depth 3. Recommended next step: Resolve DNS records, check HTTP availability, review TLS certificates, capture screenshots, and compare the results against the official asset inventory. ``` --- ## 🛡️ Security, Privacy & Responsible Use Subdomains Check is intended for lawful domain analysis, OSINT research, security review, asset inventory, compliance, and defensive cybersecurity workflows. Acceptable use cases include: - auditing domains you own or are authorized to review; - mapping public attack surface; - discovering known public hostnames; - supporting incident response; - enriching SOC investigations; - reviewing brand-related infrastructure; - preparing asset inventories; - checking for forgotten subdomains; - documenting public exposure; - supporting authorized bug bounty reconnaissance. Users should follow responsible use principles: - Do not use the tool for unauthorized targeting or harassment. - Do not attempt to exploit discovered services. - Do not assume that discovery equals vulnerability. - Validate findings responsibly. - Follow authorization boundaries. - Store exported results securely. - Avoid sharing sensitive investigation results publicly. - Report security issues through proper disclosure channels. Subdomain enumeration is a normal defensive and OSINT technique, but it should be used responsibly and legally. --- ## ⚙️ Technical Highlights - Subdomain enumeration tool - Available at `dash.niamonx.io/subdomains_check` - Searches and checks subdomains for a target domain - Uses internal services and archives - Accepts domains without protocol - Validates domain input - Shows total number of discovered subdomains - Shows unique areas - Shows maximum depth - Displays timestamped results - Provides searchable result table - Supports pagination - Calculates zone for each subdomain - Calculates depth for each subdomain - Maintains local domain history - Supports filtering domain history - Allows copying JSON - Allows copying subdomain list - Supports CSV export - Provides Raw JSON view - Suitable for OSINT, SOC, incident response, attack surface mapping, compliance, brand protection, and infrastructure inventory --- ## 📌 Usage Hints - Enter only the domain, such as `example.com`. - Do not include `https://` or `http://`. - Do not include paths, query strings, fragments, or wildcards. - Use the result summary for quick triage. - Review total subdomain count. - Check Unique Areas to understand grouping. - Check Maximum Depth to identify nested hostnames. - Use the search field to find interesting names. - Review all pages when the result set is large. - Copy the list for quick use in other tools. - Export CSV for reporting or spreadsheet review. - Use Raw JSON for technical validation and automation. - Compare discovered hostnames with the official asset inventory. - Enrich results with DNS, HTTP, TLS, screenshot, WHOIS, and ASN tools. - Repeat checks over time because subdomain exposure changes. - Clear local history on shared devices when analyzing sensitive domains. - Use results only within legal and authorized boundaries. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX Subdomains Check** is a focused subdomain enumeration tool for discovering and organizing subdomains of a target domain. It validates domain input, searches internal services and archives, displays discovered subdomains, calculates zone and depth, shows total count, unique areas, maximum depth, and provides search, pagination, local history, copy options, CSV export, and Raw JSON view. The tool is designed for OSINT research, attack surface mapping, SOC triage, incident response, brand protection, compliance documentation, asset inventory, and authorized security workflows. Results should be treated as point-in-time discovery intelligence and enriched with DNS resolution, HTTP checks, TLS data, screenshots, IP WHOIS, ASN information, and official asset inventory validation before drawing security conclusions. # Subdomains Check V2 | Experimental Subdomain & DNS Records Discovery Tool [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/nCAspJ3lYCHtULp7-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/nCAspJ3lYCHtULp7-image.png) The platform available at **[https://dash.niamonx.io/subdomains\_v2](https://dash.niamonx.io/subdomains_v2)** — known as **Subdomains Check V2** — is an experimental domain intelligence tool within the NiamonX platform. It searches for subdomains and related DNS records for a specified domain name, including A records, CNAME records, MX records, NS records, TXT records, resolved IP addresses, and basic network/provider information. This tool is designed for fast domain reconnaissance, DNS inventory, infrastructure mapping, attack surface review, OSINT analysis, SOC workflows, incident response, and technical asset discovery. Because the module is experimental, the speed, coverage, and completeness of results may depend on crawler performance, available sources, DNS response behavior, and tariff limits. --- ## Overview of the Service **Subdomains Check V2** helps users discover subdomains and associated DNS records for a target domain. The tool accepts a domain name, performs discovery and DNS resolution, then organizes the results into clear sections. The module can return: - A records - Discovered subdomains - Resolved IP addresses - CNAME records - MX records - NS records - TXT records - Basic IP/network provider information - Local request history - Exportable CSV and JSON data Subdomains Check V2 is useful when users need to quickly understand which public DNS records and subdomains are associated with a domain. The tool is especially helpful for: - OSINT analysts - SOC teams - Incident response teams - Threat intelligence researchers - Attack surface management teams - Bug bounty researchers - DNS administrators - DevOps engineers - Security auditors - Brand protection teams - Compliance teams - Infrastructure owners --- ## 🔍 How the Tool Works When a user enters a domain name, Subdomains Check V2 searches for subdomains and related DNS records. The tool then resolves available records and presents the results in grouped sections. Example input: ```text Domain: niamonx.io ``` Example result summary: ```text niamonx.io A: 1 Subdomains: 1 IPs: 2 MX: 3 NS: 2 TXT: 2 22:51:28 ``` Example resolved A / subdomain result: ```text niamonx.io 104.21.12.231 CLOUDFLARENET Cloudflare 172.67.153.184 CLOUDFLARENET Cloudflare ``` Example DNS records: ```text MX: 20 mx2.zoho.eu 50 mx3.zoho.eu 10 mx.zoho.eu NS: abdullah.ns.cloudflare.com ashley.ns.cloudflare.com TXT: "google-site-verification=MQNH6Yoh9hKD1hgzeQtEb9VN5_ikdspHYQxlxGS6Y-4" "v=spf1 include:zohomail.eu -all" ``` The tool provides a practical overview of both discovered subdomains and domain-level DNS configuration. --- ## 🧩 Supported Input Subdomains Check V2 accepts only a domain name. Correct input examples: ```text niamonx.io ``` ```text example.com ``` ```text sub.example.com ``` ```text company.org ``` Incorrect input examples: ```text https://niamonx.io ``` ```text http://example.com ``` ```text https://example.com/page ``` ```text example.com/path ``` ```text *.example.com ``` ```text user@example.com ``` ```text 192.168.1.1 ``` ```text localhost ``` The interface guidance is: ```text Only the domain, without http(s):// and without the path. ``` Users should enter the domain only, without protocol, path, query parameters, fragments, wildcard prefixes, or URL formatting. Recommended input format: ```text domain.tld ``` --- ## ⚙️ Main Function: Search by Domain The main search field starts the domain discovery and DNS record collection process. Example: ```text Search by Domain Domain: niamonx.io ``` After the query is processed, the tool displays a result summary and grouped DNS sections. The tool may collect and display: - root domain A records; - discovered subdomains; - resolved IP addresses; - CNAME records; - MX records; - NS records; - TXT records; - IP ownership/provider hints; - local request history. Because this version is experimental, results may vary depending on crawler performance and available data sources. --- ## 🧪 Experimental Status Subdomains Check V2 is marked as experimental. Interface note: ```text This tool is experimental: speed and completeness depend on the crawler's performance. ``` This means: - not all sources may return complete data; - some subdomains may be missed; - some records may be temporarily unavailable; - crawler speed may vary; - large domains may take longer; - results may differ between repeated checks; - DNS changes may affect output; - tariff limits may affect whether a new query can be completed. The tool should be treated as a fast discovery and enrichment layer, not as a guaranteed complete DNS inventory. For critical security work, results should be validated with additional tools and repeated over time. --- ## 📊 Results Summary The Results section provides a compact overview of the discovered records. Example: ```text niamonx.io A: 1 Subdomains: 1 IPs: 2 MX: 3 NS: 2 TXT: 2 22:51:28 ``` Typical fields include:
FieldDescription
DomainThe domain that was searched
ANumber of A-record hostnames or A-record groups found
SubdomainsNumber of discovered subdomain entries
IPsNumber of resolved IP addresses
MXNumber of mail exchanger records
NSNumber of name server records
TXTNumber of text records
TimeQuery time or result timestamp
The summary is useful for quick triage and comparison between multiple domain checks. --- ## 🌐 A Records and Subdomains Section The **A / Subdomains** section shows hostnames and their resolved IPv4 addresses. Example: ```text A / Subdomains niamonx.io 104.21.12.231 CLOUDFLARENET Cloudflare 172.67.153.184 CLOUDFLARENET Cloudflare ``` A records are used to map hostnames to IPv4 addresses. This section helps users identify: - public-facing hosts; - CDN-backed services; - cloud-hosted infrastructure; - shared hosting or provider networks; - exposed root-domain records; - resolved subdomain infrastructure; - IPs that should be enriched with WHOIS or ASN data. A single hostname may resolve to multiple IP addresses because of: - CDN usage; - load balancing; - high availability; - geo-distributed infrastructure; - provider-managed routing; - DNS round-robin behavior. --- ## 🏢 Network and Provider Information Subdomains Check V2 may show basic provider or network hints next to resolved IP addresses. Example: ```text CLOUDFLARENET - Cl Cloudflare ``` This helps users quickly identify whether a hostname appears to be associated with: - CDN providers; - cloud providers; - hosting companies; - ISP infrastructure; - security proxy services; - managed DNS or edge networks. Provider information is useful for triage, but it should not be treated as final attribution. For accurate infrastructure ownership analysis, users should also check IP WHOIS, ASN data, BGP routes, passive DNS, HTTP headers, and TLS certificates. --- ## 🔎 Filtering by Subdomains The tool provides filtering by subdomain substring. Example: ```text Filter by subdomains (substring) ``` Filtering is useful when working with large result sets. Users can search for terms such as: ```text api ``` ```text admin ``` ```text dev ``` ```text stage ``` ```text support ``` ```text mail ``` This helps analysts quickly locate interesting, risky, or business-relevant hostnames. --- ## 🔁 CNAME Records The CNAME section displays canonical name records. Example: ```text CNAME No Records ``` A CNAME record points one hostname to another canonical hostname. Example: ```text app.example.com → example.hosting-provider.com ``` CNAME records are useful for identifying: - third-party services; - cloud applications; - SaaS integrations; - CDN aliases; - managed landing pages; - verification targets; - external dependencies; - possible subdomain takeover risks. If the tool shows: ```text No Records ``` it means no CNAME records were returned for the current result set. Important security note: CNAME records pointing to third-party services should be reviewed carefully. Abandoned or misconfigured CNAME records may indicate potential subdomain takeover risk, but this must be validated responsibly. --- ## 📬 MX Records The MX section shows mail exchanger records for the domain. Example: ```text MX 20 mx2.zoho.eu 50 mx3.zoho.eu 10 mx.zoho.eu ``` MX records define where e-mail for the domain should be delivered. The number before the mail server is the MX priority. Example: ```text 10 mx.zoho.eu ``` Lower priority numbers are preferred first. In the example above: ```text 10 mx.zoho.eu 20 mx2.zoho.eu 50 mx3.zoho.eu ``` the mail server with priority `10` is preferred before `20` and `50`. MX records are useful for: - identifying mail providers; - reviewing e-mail infrastructure; - checking business mail routing; - validating domain configuration; - supporting phishing and spoofing investigations; - preparing e-mail security reviews. --- ## 🌍 MX IP Resolution Subdomains Check V2 may also resolve MX hostnames to IP addresses. Example: ```text 20 mx2.zoho.eu 89.36.170.166 50 mx3.zoho.eu 185.230.212.166 10 mx.zoho.eu 185.20.209.166 ``` This helps users understand not only which mail servers are configured, but also which IP addresses they resolve to. MX IP resolution is useful for: - mail infrastructure mapping; - provider verification; - allowlist planning; - e-mail security review; - incident response; - troubleshooting mail delivery; - comparing DNS results across time. --- ## 🧭 NS Records The NS section shows authoritative name servers for the domain. Example: ```text NS abdullah.ns.cloudflare.com 162.159.44.203 ashley.ns.cloudflare.com 172.64.32.71 ``` NS records indicate which name servers are responsible for the domain’s DNS zone. Name server data helps identify: - DNS provider; - authoritative DNS infrastructure; - delegated DNS management; - provider dependencies; - DNS hosting configuration; - security and availability posture. The tool may also resolve name server hostnames to IP addresses. Example: ```text abdullah.ns.cloudflare.com → 162.159.44.203 ashley.ns.cloudflare.com → 172.64.32.71 ``` NS records are important during security audits because DNS provider compromise or misconfiguration can affect the entire domain. --- ## 🧾 TXT Records The TXT section displays text records associated with the domain. Example: ```text TXT "google-site-verification=MQNH6Yoh9hKD1hgzeQtEb9VN5_ikdspHYQxlxGS6Y-4" "v=spf1 include:zohomail.eu -all" ``` TXT records may contain: - SPF policies; - DMARC records; - DKIM records; - domain ownership verification tokens; - third-party service verification; - security policy metadata; - mail provider configuration; - platform integration records. TXT records are useful for identifying how a domain is connected to external services and how e-mail authentication is configured. --- ## 📧 SPF Records TXT records may include SPF configuration. Example: ```text v=spf1 include:zohomail.eu -all ``` SPF defines which mail servers are allowed to send e-mail on behalf of the domain. In this example: ```text include:zohomail.eu ``` allows Zoho Mail infrastructure to send mail for the domain. The ending: ```text -all ``` means mail from unauthorized senders should fail SPF validation. SPF records are important for: - preventing spoofing; - e-mail authentication; - phishing resistance; - mail delivery reliability; - domain security posture. --- ## 🔐 Domain Verification Records TXT records may also include verification tokens. Example: ```text google-site-verification=MQNH6Yoh9hKD1hgzeQtEb9VN5_ikdspHYQxlxGS6Y-4 ``` Verification records are commonly used by services such as: - Google; - Microsoft; - Zoho; - cloud providers; - SaaS platforms; - CDN services; - mail providers; - analytics platforms; - search console tools. These records prove domain ownership to third-party services. Security teams should review TXT records to identify outdated, unused, or unexpected third-party integrations. --- ## 🕓 Local Request History Subdomains Check V2 stores a local request history in the browser. Example interface note: ```text Request history (local) Filter... We keep the domain and a brief summary (up to 200 entries). ``` Example history item: ```text niamonx.io A:1 Subs:1 IPs:2 17.06.2026, 22:51:28 ``` Other examples: ```text itstep.org A:50 Subs:50 IPs:2 16.05.2026, 22:37:48 ``` ```text haveibeenpwned.com A:13 Subs:13 IPs:3 10.12.2025, 00:46:07 ``` The local history helps users: - repeat previous checks; - compare domain summaries over time; - continue investigation sessions; - filter previous requests; - quickly revisit recently analyzed domains. Because history is stored locally in the browser, it may be removed when browser data is cleared or when the user changes browser profiles, devices, or private browsing sessions. On shared or untrusted devices, users should clear local history after checking sensitive domains, client assets, or incident-related infrastructure. --- ## 🚦 Tariff Limits Subdomains Check V2 respects user tariff limits. Interface note: ```text Tariff limits are taken into account. If exceeded, we will display a message and will not clear the previous results. ``` Important points: - Each query may consume plan quota. - Limits depend on the user’s active plan. - Large or repeated searches may reach the limit faster. - If the limit is exceeded, the tool displays a warning. - Previous results remain visible when the limit is exceeded. - The interface does not clear previous results after a limit error. This behavior helps prevent users from losing their last successful result when a new query cannot be completed. --- ## 📤 Copying and Exporting Results Subdomains Check V2 supports copying and exporting data. Available actions may include: - copy results; - export CSV; - export JSON; - copy DNS records; - preserve local history summaries. Export features are useful for: - security reports; - SOC tickets; - incident response notes; - compliance evidence; - asset inventory; - attack surface documentation; - spreadsheet analysis; - automation workflows; - historical comparison. --- ## 📄 CSV Export CSV export allows users to work with results in spreadsheet tools or reporting systems. CSV data may include: - domain; - hostname; - record type; - record value; - resolved IP; - provider information; - priority for MX records; - timestamp. Example CSV-style structure: ```text Domain,Record Type,Hostname,Value,IP,Provider niamonx.io,A,niamonx.io,104.21.12.231,104.21.12.231,Cloudflare niamonx.io,A,niamonx.io,172.67.153.184,172.67.153.184,Cloudflare niamonx.io,MX,niamonx.io,10 mx.zoho.eu,185.20.209.166,Zoho niamonx.io,NS,niamonx.io,abdullah.ns.cloudflare.com,162.159.44.203,Cloudflare niamonx.io,TXT,niamonx.io,"v=spf1 include:zohomail.eu -all",, ``` CSV export is useful when results need to be shared with technical teams, compliance departments, management, or auditors. --- ## 🧬 JSON Export JSON export provides structured machine-readable output. JSON data may include: - searched domain; - A records; - subdomains; - IP addresses; - CNAME records; - MX records; - NS records; - TXT records; - resolved IP details; - timestamp; - summary counts. JSON is useful for: - automation; - API-style processing; - custom scripts; - evidence preservation; - technical validation; - integration with asset inventory systems; - comparing results over time. --- ## 🔐 Why This Tool Matters Subdomains and DNS records are a major part of an organization’s public attack surface. A domain may appear simple from the outside, but DNS records can reveal mail providers, name servers, cloud services, CDN usage, verification tokens, third-party dependencies, and public application endpoints. Subdomains Check V2 helps users identify: - public hostnames; - exposed services; - CDN-backed infrastructure; - mail infrastructure; - DNS providers; - TXT-based service integrations; - SPF configuration; - name server dependencies; - resolved IP addresses; - possible third-party exposure; - unexpected or forgotten records. This information supports both defensive security and operational infrastructure management. --- ## 🔎 Common Use Cases ### DNS Inventory Create a structured overview of DNS records associated with a domain. ### Subdomain Discovery Find discovered subdomains and review how they resolve. ### Attack Surface Mapping Identify public hostnames, IP addresses, DNS providers, and mail systems. ### SOC Triage Enrich alerts involving domains, hostnames, or suspicious DNS records. ### Incident Response Check whether a suspicious domain or subdomain is related to known infrastructure. ### Phishing Investigation Review DNS records, mail configuration, and provider information for suspicious domains. ### Brand Protection Inspect domains and subdomains related to impersonation, fraud, or unauthorized brand usage. ### Mail Security Review Review MX and TXT records, including SPF-related configuration. ### DNS Provider Review Check NS records and identify authoritative DNS providers. ### Cloud and CDN Mapping Identify whether hostnames resolve to CDN or cloud provider infrastructure. ### Compliance Documentation Document DNS records and public exposure for audits, reports, and risk reviews. ### Asset Inventory Add discovered hostnames, IPs, and records to an asset management workflow. --- ## 🧠 Recommended Workflow A practical Subdomains Check V2 workflow should follow these steps. ### 1. Enter the Domain Use only the domain name. Example: ```text niamonx.io ``` Do not include: ```text https:// http:// /path ?query=value #fragment * ``` --- ### 2. Run the Search Start the query and wait for the result. Example: ```text Search by Domain ``` The tool will search for subdomains and related DNS records. --- ### 3. Review the Summary Check the high-level result counts. Example: ```text A: 1 Subdomains: 1 IPs: 2 MX: 3 NS: 2 TXT: 2 ``` This gives a quick overview of how much data was found. --- ### 4. Review A / Subdomains Inspect discovered hostnames and IP addresses. Example: ```text niamonx.io 104.21.12.231 172.67.153.184 ``` Follow up with IP WHOIS, ASN lookup, HTTP checks, TLS inspection, or screenshot capture when needed. --- ### 5. Check CNAME Records Review whether the domain or subdomains point to external services. Example: ```text CNAME: No Records ``` If CNAME records exist, validate whether the targets are expected and still active. --- ### 6. Review MX Records Check mail routing and provider configuration. Example: ```text 10 mx.zoho.eu 20 mx2.zoho.eu 50 mx3.zoho.eu ``` Confirm that the mail provider is expected and that MX priorities are correct. --- ### 7. Review NS Records Check authoritative name servers. Example: ```text abdullah.ns.cloudflare.com ashley.ns.cloudflare.com ``` Verify that the DNS provider is expected and properly managed. --- ### 8. Review TXT Records Inspect TXT records for SPF, verification tokens, and third-party integrations. Example: ```text v=spf1 include:zohomail.eu -all ``` Check for outdated, unexpected, or overly permissive records. --- ### 9. Filter Subdomains Use substring filtering to locate interesting names. Examples: ```text api admin dev stage mail support ``` Filtering is useful for large domains with many discovered subdomains. --- ### 10. Export Results Use CSV or JSON export for reporting and follow-up analysis. Recommended exports: ```text CSV JSON ``` --- ### 11. Validate With Additional Tools Because the tool is experimental, validate important findings with additional sources. Recommended follow-up checks: - DNS resolver checks; - Subdomains Extended; - IP WHOIS; - ASN lookup; - HTTP status checks; - TLS certificate inspection; - website screenshot capture; - passive DNS; - historical DNS; - technology fingerprinting; - authorized vulnerability scanning. --- ## 🚨 Security Review Checklist When reviewing results, pay special attention to the following areas. ### Unexpected IP Addresses Check whether resolved IPs belong to expected providers. Questions: - Is this IP expected? - Does it belong to the correct provider? - Is it shared CDN infrastructure? - Is it an origin server? - Should this hostname be publicly exposed? --- ### Third-Party Dependencies Review CNAME, NS, MX, and TXT records for third-party services. Potential dependencies: - CDN providers; - DNS providers; - mail providers; - SaaS platforms; - cloud hosting services; - verification platforms; - analytics or marketing tools. --- ### Mail Security Review MX and TXT records. Important checks: - Is the mail provider expected? - Does SPF exist? - Is SPF too broad? - Is DMARC present in related records? - Are DKIM records configured elsewhere? - Are old verification records still needed? --- ### Name Server Control Review NS records. Questions: - Are the name servers expected? - Who controls the DNS provider account? - Is MFA enabled on the DNS provider? - Are there stale delegations? - Is DNS change monitoring enabled? --- ### Subdomain Exposure Review discovered subdomains and search for sensitive patterns. Examples: ```text admin dev test stage staging internal portal dashboard api backup old legacy ``` These names may indicate systems that need closer review. --- ### TXT Record Hygiene TXT records can expose operational information. Review for: - outdated verification tokens; - unused provider integrations; - old SPF includes; - sensitive metadata; - abandoned service records; - unclear ownership. --- ## ⚠️ Limitations and Important Notes Subdomains Check V2 should be interpreted carefully. Important limitations: - The tool is experimental. - Results may not be complete. - Crawler performance affects speed and coverage. - Some sources may not provide all subdomains. - DNS records may change frequently. - Some records may be cached. - Some subdomains may not resolve. - Provider information may be approximate. - A record count does not necessarily mean the number of active applications. - CDN IPs may be shared by many unrelated customers. - Missing CNAME records do not prove there are no external dependencies. - Missing TXT records do not prove that no verification records exist elsewhere. - Tariff limits may prevent new queries. - If tariff limits are exceeded, previous results remain visible. Interface note: ```text The tool is experimental; not all sources provide a complete list of subdomains. ``` For high-confidence analysis, combine results with multiple discovery and DNS validation methods. --- ## 📊 Interpreting Results Correctly Subdomains Check V2 provides point-in-time DNS and subdomain intelligence. Important interpretation notes: - A discovered hostname does not automatically indicate risk. - A missing record does not always prove absence. - DNS data can vary by resolver, region, cache, and time. - CDN and cloud records may hide origin infrastructure. - Mail records show routing, not necessarily account ownership. - TXT records may represent active or historical integrations. - NS records show authoritative DNS providers, but not full security posture. - IP provider names help with triage but should be validated. - Experimental discovery may miss subdomains. - Repeated checks over time may produce different results. The tool should be used as part of a broader investigation workflow. --- ## 🧾 Recommended Reporting Format When documenting results, use a consistent format. Example: ```text Domain: niamonx.io Query time: 17.06.2026, 22:51:28 Summary: A records: 1 Subdomains: 1 Resolved IPs: 2 MX records: 3 NS records: 2 TXT records: 2 A / Subdomains: niamonx.io - 104.21.12.231 - 172.67.153.184 MX: - 10 mx.zoho.eu → 185.20.209.166 - 20 mx2.zoho.eu → 89.36.170.166 - 50 mx3.zoho.eu → 185.230.212.166 NS: - abdullah.ns.cloudflare.com → 162.159.44.203 - ashley.ns.cloudflare.com → 172.64.32.71 TXT: - "google-site-verification=MQNH6Yoh9hKD1hgzeQtEb9VN5_ikdspHYQxlxGS6Y-4" - "v=spf1 include:zohomail.eu -all" ``` For security reports, add analyst notes: ```text Observation: The domain resolves through Cloudflare infrastructure and uses Zoho mail exchangers. TXT records include Google site verification and SPF authorization for Zoho Mail. Recommended next step: Validate DMARC and DKIM configuration, confirm that the listed providers are expected, review DNS provider account security, and enrich resolved IPs with WHOIS / ASN data. ``` --- ## 🛡️ Security, Privacy & Responsible Use Subdomains Check V2 is intended for lawful DNS analysis, OSINT research, security review, compliance, infrastructure mapping, and defensive cybersecurity workflows. Acceptable use cases include: - auditing domains you own or are authorized to assess; - reviewing public DNS configuration; - discovering subdomains; - mapping public infrastructure; - supporting incident response; - enriching SOC investigations; - reviewing mail and DNS security; - checking provider dependencies; - documenting public exposure; - preparing asset inventories; - supporting authorized bug bounty reconnaissance. Users should follow responsible use principles: - Do not use the tool for unauthorized targeting or harassment. - Do not attempt to exploit discovered systems. - Do not assume that DNS discovery equals vulnerability. - Validate important findings with additional evidence. - Follow authorization boundaries. - Store exported results securely. - Avoid exposing sensitive investigation results publicly. - Report issues through proper disclosure channels. Subdomain and DNS discovery is a legitimate defensive and OSINT technique, but it should be used responsibly and legally. --- ## ⚙️ Technical Highlights - Experimental subdomain and DNS discovery tool - Available at `dash.niamonx.io/subdomains_v2` - Searches by domain name - Accepts domains without protocol or path - Searches for subdomains - Collects A records - Collects CNAME records - Collects MX records - Collects NS records - Collects TXT records - Resolves IP addresses - Shows basic provider/network hints - Displays result summary counts - Supports filtering by subdomain substring - Supports copying results - Supports CSV export - Supports JSON export - Maintains local request history - Stores up to 200 local history entries - Preserves previous results if tariff limit is exceeded - Suitable for OSINT, SOC, incident response, attack surface management, DNS review, mail security analysis, and infrastructure mapping --- ## 📌 Usage Hints - Enter only the domain name, such as `example.com`. - Do not include `http://` or `https://`. - Do not include paths, query strings, fragments, or wildcards. - Review the summary counts first. - Check A records and resolved IPs. - Review provider hints, but validate them with IP WHOIS and ASN tools. - Use subdomain filtering to find interesting names. - Check CNAME records for third-party dependencies. - Review MX records to understand mail routing. - Review NS records to confirm DNS provider configuration. - Review TXT records for SPF and verification tokens. - Export CSV for reporting and spreadsheet review. - Export JSON for automation and technical validation. - Repeat checks over time because DNS data changes. - Treat results as experimental and validate important findings. - Keep local history in mind when using shared devices. - Use the tool only within authorized and lawful workflows. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX Subdomains Check V2** is an experimental subdomain and DNS records discovery tool for domain-based reconnaissance. It searches for subdomains and related DNS records, including A, CNAME, MX, NS, and TXT records, resolves IP addresses, shows basic provider information, supports substring filtering, provides CSV and JSON export, and stores local request history with brief summaries. The tool is designed for OSINT research, DNS inventory, SOC workflows, incident response, attack surface mapping, mail security review, provider dependency analysis, brand protection, compliance documentation, and authorized security assessments. Because it is experimental, results should be treated as point-in-time discovery intelligence and validated with additional DNS, WHOIS, ASN, HTTP, TLS, screenshot, passive DNS, and asset inventory sources before drawing final conclusions. # URL Shortener | Custom Short Link Creation Tool [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/wImkSbcqlRLRLAqP-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/wImkSbcqlRLRLAqP-image.png) The platform available at **[https://dash.niamonx.io/url\_shortener](https://dash.niamonx.io/url_shortener)** — known as **URL Shortener** — is a short link creation tool within the NiamonX platform. It allows users to create branded short URLs using available custom domains, optional custom slugs, optional expiration settings, and an optional expired redirect URL. The tool is designed for fast and controlled link shortening, link branding, sharing, campaign routing, documentation links, support links, internal workflows, and security-aware URL management. --- ## Overview of the Service **URL Shortener** helps users convert long URLs into shorter, cleaner, and easier-to-share links. Instead of sending long dashboard URLs, documentation URLs, campaign links, or support links, users can generate compact short URLs using available NiamonX-connected domains. The tool supports: - custom short link domains; - custom slugs; - target URL validation; - optional expired redirect URL; - optional expiration time in hours; - copy-friendly short links; - local request history; - plan-based query limits; - client-side controls; - export and reuse workflows. Example generated link: ```text https://clc.is/adsas345253 ``` Example target URL: ```text https://dash.niamonx.io/url_shortener ``` This makes the module useful for support teams, analysts, developers, marketing teams, internal documentation, OSINT workflows, SOC teams, customer communication, and controlled temporary link sharing. --- ## 🔍 How the Tool Works The user selects a short link domain, enters the target URL, optionally defines a custom slug, optionally sets an expired URL, and optionally configures expiration hours. The tool then creates a short URL that redirects users to the specified target destination. Example configuration: ```text Domain: clc.is Target URL: https://dash.niamonx.io/url_shortener Slug: adsas345253 Expired URL: https://example.com/expired Expired hours: 0 ``` Example result: ```text https://clc.is/adsas345253 Target: https://dash.niamonx.io/url_shortener Domain: clc.is Slug: adsas345253 Expires: Never 17.06.2026, 22:56:05 ``` If expiration is set to `0`, the short link does not expire. Example: ```text Expired hours: 0 0 = never ``` --- ## 🧩 Main Use Cases URL Shortener can be used for many link management workflows. Common use cases include: - creating short links for dashboards; - sharing long URLs in a compact format; - creating branded support links; - creating temporary links; - routing expired links to a fallback page; - simplifying links for documentation; - sharing tools inside reports; - creating easy-to-read links for presentations; - tracking internal link creation history locally; - preparing links for customer support or analyst workflows. Example: ```text Long URL: https://dash.niamonx.io/url_shortener Short URL: https://clc.is/adsas345253 ``` --- ## ⚙️ Create Short Link The main panel is used to create a new short URL. Main fields include: - Domain - Target URL - Slug - Expired URL - Expired hours Example interface section: ```text Create short link Domain: clc.is Target URL: https://dash.niamonx.io/url_shortener Slug: adsas345253 Expired URL: https://example.com/expired Expired hours: 0 ``` After submission, the tool displays the generated short link and its configuration. --- ## 🌐 Domain The **Domain** field controls which short domain will be used. Example: ```text Domain: clc.is ``` The available domains are populated from the API. Interface note: ```text Populates from API ``` Possible examples: ```text clc.is ``` ```text clc.cx ``` The selected domain becomes the base of the short link. Example: ```text https://clc.is/adsas345253 ``` Domain selection is useful for: - branding links; - separating use cases; - choosing a shorter domain; - creating campaign-specific links; - organizing links by project; - using trusted short domains for internal workflows. --- ## 🔗 Target URL The **Target URL** is the destination where users will be redirected when they open the short link. Example: ```text https://dash.niamonx.io/url_shortener ``` The target should be a complete URL with protocol. Recommended format: ```text https://example.com/page ``` Valid examples: ```text https://dash.niamonx.io/url_shortener ``` ```text https://dash.niamonx.io/webscreen ``` ```text https://support.niamonx.io/ ``` Invalid or incomplete examples: ```text dash.niamonx.io/url_shortener ``` ```text www.example.com/page ``` ```text example.com ``` ```text localhost ``` For reliable redirection, users should always include: ```text https:// ``` or: ```text http:// ``` --- ## 🏷️ Slug The **Slug** field defines the custom path part of the short link. Example: ```text Slug: adsas345253 ``` Generated short URL: ```text https://clc.is/adsas345253 ``` The slug is optional. If the user leaves the slug empty, the system may generate or assign a slug automatically, depending on backend behavior. Example with a custom slug: ```text https://clc.is/url_shortener ``` Example with another custom slug: ```text https://clc.cx/petux ``` A slug can be useful for: - branded links; - memorable links; - campaign naming; - tool shortcuts; - documentation references; - support links; - internal workflow shortcuts. Good slug examples: ```text webscreen ``` ```text url_shortener ``` ```text support-guide ``` ```text case-2026-001 ``` Less recommended slug examples: ```text 444444444444444444444444444444 ``` ```text - ``` ```text adsas345253 ``` Although technical slugs may work, descriptive slugs are easier to manage, trust, and remember. --- ## ⏳ Expired URL The **Expired URL** field defines where users should be redirected after the short link expires. Example: ```text Expired URL: https://example.com/expired ``` This is optional. Use cases for an expired URL: - redirect users to an expired campaign page; - send users to a support article; - show a deactivation notice; - redirect to a new landing page; - route old links to a safe fallback page; - prevent broken user experience after expiration. Example behavior: ```text Before expiration: https://clc.is/adsas345253 → https://dash.niamonx.io/url_shortener After expiration: https://clc.is/adsas345253 → https://example.com/expired ``` If no expired URL is provided, backend behavior may depend on platform configuration. For best user experience, users should provide a clear expired destination when creating temporary links. --- ## 🕓 Expired Hours The **Expired hours** field controls how long the short link remains active. Example: ```text Expired hours: 0 ``` Special value: ```text 0 = never ``` This means the link does not expire. Example: ```text Expires: Never ``` A non-zero value creates a temporary short link. Example: ```text Expired hours: 1 ``` This means the link expires after one hour. Temporary links are useful for: - limited-time access; - short campaigns; - expiring support links; - temporary documentation access; - incident response sharing; - controlled internal workflows; - test links; - demo links. Recommended expiration settings:
Use CaseSuggested Expiry
Permanent documentation shortcut0
Temporary support link1–24 hours
Campaign linkBased on campaign duration
Incident response link1–72 hours
Internal test link1–24 hours
Demo or training link24–168 hours
Long-term branded shortcut0
--- ## ✅ Results Section After successful creation, the Results section displays the generated short link and metadata. Example: ```text 17.06.2026, 22:56:05 https://clc.is/adsas345253 Target: https://dash.niamonx.io/url_shortener Domain: clc.is Slug: adsas345253 Expires: Never ``` Typical result fields include:
FieldDescription
TimestampDate and time when the short link was created
Short URLThe generated short link
TargetDestination URL
DomainSelected short domain
SlugCustom or generated slug
ExpiresExpiration status
The Results section is useful for quickly copying the generated link and verifying that it points to the correct destination. --- ## 📋 Request History URL Shortener stores recent actions locally in the user’s browser. Example interface note: ```text Request History Filter... Stores last 100 actions in your browser. ``` Example history item: ```text https://clc.is/adsas345253 Domain: clc.is Slug: adsas345253 Expires: Never 17.06.2026, 22:56:05 Target: https://dash.niamonx.io/url_shortener ``` The request history helps users: - reuse recently created links; - check the target of a previous link; - copy a short URL again; - review slug and domain choices; - filter previous actions; - confirm expiration settings; - continue link management workflows. Because the history is stored locally in the browser, it may be removed when users clear browser data, switch devices, use a different browser profile, or use private browsing mode. On shared or untrusted devices, users should treat link history as sensitive and clear it when links point to private dashboards, customer pages, internal tools, incident reports, or confidential resources. --- ## 🚦 Query Limits and Plan Access URL Shortener uses plan-based query limits. Example: ```text 1249 / 1250 Queries remaining / total Plan: Sentinel ``` Important points: - Each short link creation request may consume plan quota. - Limits depend on the user’s active plan. - Server-side plan limits apply. - If the limit is reached, new link creation may be blocked. - The interface may keep previous results visible even if a new request fails. - Users should monitor remaining queries when creating many links. Example interface note: ```text Server-side plan limits apply. ``` Plan limits help control resource usage and prevent abuse. --- ## 🧠 Key Features ### Custom Domain Selection Users can choose from available short link domains provided by the API. ### Custom Slug Support Users can define their own slug for branded, readable, or workflow-specific links. ### Target URL Validation The tool validates the destination URL to reduce invalid or malformed link creation. ### Optional Expiration Users can configure links to expire after a specified number of hours. ### Never-Expire Mode Setting expiration hours to `0` creates a non-expiring link. ### Expired Redirect URL Users can define a fallback destination for expired links. ### Copy-Friendly Results Generated short URLs are displayed clearly for easy copying and sharing. ### Local Request History The tool stores the last 100 actions locally in the browser. ### Filtering History Users can filter request history to find previous links. ### Plan-Based Limits Short link creation is controlled by the user’s active plan. ### Client-Side Controls The interface provides validation, copy, and export-oriented controls on the client side. --- ## 🔎 Common Use Cases ### Branded Short Links Create short links using selected custom domains for cleaner and more recognizable sharing. Example: ```text https://clc.is/webscreen ``` ### Dashboard Shortcuts Create compact links to NiamonX tools or internal dashboard pages. Example: ```text Target: https://dash.niamonx.io/webscreen Slug: webscreen ``` ### Support Links Create short links for support tickets, helpdesk responses, troubleshooting guides, or customer instructions. ### Documentation Links Create readable shortcuts for long documentation URLs. ### Temporary Access Links Use expiration hours to create time-limited links. Example: ```text Expires: 1 h ``` ### Campaign or Announcement Links Use custom slugs to create memorable campaign or announcement URLs. ### Incident Response Sharing Create controlled short links for reports, evidence packages, or internal incident documentation. ### Training and Demo Links Create short, easy-to-type links for presentations, workshops, and training sessions. ### Link Routing After Expiry Use expired URLs to send users to a fallback page after a campaign or temporary workflow ends. --- ## 🧾 Example Configurations ### Permanent Short Link ```text Domain: clc.is Target URL: https://dash.niamonx.io/url_shortener Slug: url_shortener Expired URL: — Expired hours: 0 ``` Result: ```text https://clc.is/url_shortener Expires: Never ``` Best for: - stable documentation links; - internal tool shortcuts; - dashboards; - reusable references. --- ### Temporary Short Link ```text Domain: clc.cx Target URL: https://dash.niamonx.io/url_shortener Slug: demo-link Expired URL: https://example.com/expired Expired hours: 1 ``` Result behavior: ```text Active for: 1 hour After expiry: redirects to https://example.com/expired ``` Best for: - demos; - temporary support; - time-limited sharing; - controlled campaigns; - short-lived internal workflows. --- ### Tool Shortcut Link ```text Domain: clc.is Target URL: https://dash.niamonx.io/webscreen Slug: webscreen Expired hours: 0 ``` Result: ```text https://clc.is/webscreen ``` Best for: - easy tool access; - documentation; - team shortcuts; - presentations; - internal onboarding. --- ### Automatically Assigned Slug ```text Domain: clc.is Target URL: https://dash.niamonx.io/url_shortener Slug: — Expired hours: 0 ``` Possible result: ```text (created) Domain: clc.is Slug: — Expires: Never ``` Backend behavior may assign a slug automatically depending on platform configuration. --- ## 🧠 Recommended Workflow A practical URL Shortener workflow should follow these steps. ### 1. Select a Domain Choose the short link domain that should be used. Example: ```text clc.is ``` Use a domain that matches the purpose of the link, brand, or workflow. --- ### 2. Enter the Target URL Paste the full destination URL. Example: ```text https://dash.niamonx.io/url_shortener ``` Make sure the URL includes `https://` or `http://`. --- ### 3. Choose a Slug Enter a custom slug if a readable or branded link is needed. Example: ```text url_shortener ``` Leave it empty if automatic slug generation is preferred. --- ### 4. Configure Expiry Set expiration hours. Example for no expiration: ```text Expired hours: 0 ``` Example for a temporary link: ```text Expired hours: 24 ``` --- ### 5. Add an Expired URL if Needed For temporary links, add a fallback URL. Example: ```text https://example.com/expired ``` This improves user experience after the link expires. --- ### 6. Create the Short Link Submit the form and wait for the result. Example result: ```text https://clc.is/adsas345253 ``` --- ### 7. Verify the Result Check: ```text Target URL Domain Slug Expiration Timestamp ``` Make sure the link points to the intended destination before sharing it. --- ### 8. Copy and Share the Link Copy the generated short URL and share it through the intended channel. Examples: - support ticket; - documentation; - chat; - e-mail; - report; - presentation; - internal wiki; - campaign message. --- ### 9. Review Local History if Needed Use request history to find recently created links. Example: ```text Filter... ``` This is useful when the short link was created earlier in the same browser. --- ## 🔐 Security Considerations Short links are convenient, but they should be used carefully. Important security points: - Short links hide the final destination from the visible URL. - Users may be cautious when clicking unknown short links. - Sensitive target URLs should not be shortened unless necessary. - Links to private dashboards should be shared only with authorized users. - Expiration should be used for temporary or sensitive workflows. - Expired URLs should point to a safe and controlled page. - Slugs should not reveal secrets, tokens, credentials, or private case details. - Local history may expose previously created links. - Shared devices should not retain sensitive link history. - Custom slugs may be guessable if they use simple words. - Non-expiring links should be reviewed periodically. Do not place sensitive information directly inside slugs. Bad examples: ```text customer-password-reset-token ``` ```text case-secret-token-123 ``` ```text private-client-incident-admin ``` Better examples: ```text case-2026-001 ``` ```text support-guide ``` ```text webscreen ``` --- ## 🛡️ Responsible Use URL Shortener is intended for legitimate link management, support, documentation, internal workflow, campaign routing, and controlled sharing. Acceptable use cases include: - shortening your own links; - creating branded support links; - sharing internal documentation; - creating temporary links; - routing expired links to safe fallback pages; - simplifying dashboard URLs; - preparing links for reports or presentations; - creating team shortcuts; - creating customer support references. Users should follow responsible use principles: - Do not use short links for phishing. - Do not hide malicious destinations. - Do not impersonate trusted services. - Do not create misleading slugs. - Do not use short links to distribute malware. - Do not use the tool for spam campaigns. - Do not shorten URLs containing exposed secrets or tokens. - Do not share private links with unauthorized users. - Use expiration for temporary or sensitive links. - Use clear, trustworthy slugs where appropriate. Short links should make access easier, not deceptive. --- ## 📊 Interpreting Results Correctly A generated short link should be interpreted as a redirect object. Important notes: - The short URL is not the same as the target URL. - The short URL redirects to the configured target. - The selected domain controls the visible short link base. - The slug controls the path of the short link. - Expiration controls how long the link remains active. - `0` expiration means the link does not expire. - The expired URL is used only after expiration, when configured. - Local history is browser-side and may not reflect server-side link state. - Deleting browser history does not necessarily delete the created server-side short link. - Plan limits apply to link creation requests. - Users should verify generated links before sharing. --- ## 📋 Recommended Link Naming Guidelines Good slugs should be: - readable; - short; - relevant; - non-sensitive; - easy to type; - easy to recognize; - appropriate for the audience; - not misleading. Good examples: ```text webscreen ``` ```text url-shortener ``` ```text support ``` ```text docs ``` ```text incident-guide ``` Avoid slugs that are: - too long; - random without purpose; - offensive; - misleading; - secret-bearing; - impersonating another brand; - likely to be guessed when privacy matters. --- ## 🧾 Recommended Reporting Format When documenting created short links, use a consistent format. Example: ```text Created: 17.06.2026, 22:56:05 Short URL: https://clc.is/adsas345253 Target URL: https://dash.niamonx.io/url_shortener Domain: clc.is Slug: adsas345253 Expires: Never Expired URL: https://example.com/expired Plan: Sentinel ``` For temporary links, document the expiration: ```text Short URL: https://clc.cx/demo-link Target URL: https://dash.niamonx.io/url_shortener Expires: 1 hour Expired URL: https://example.com/expired Purpose: temporary demo link ``` For internal security workflows, also document: ```text Owner Purpose Creation time Expected audience Expiration policy Review date ``` --- ## 🧹 Managing Local History The local request history stores the last 100 actions in the browser. Example: ```text Stores last 100 actions in your browser. ``` Recommended practices: - filter history to find recent links; - copy previously created short links when needed; - clear history on shared devices; - avoid creating sensitive links on untrusted browsers; - do not rely on local history as the only record of important links; - document important links separately in official systems. Local history is a convenience feature, not a full link management database. --- ## ⚙️ Technical Highlights - URL shortening tool - Available at `dash.niamonx.io/url_shortener` - Creates short links - Supports custom short domains - Domains populate from API - Supports custom slugs - Supports target URL validation - Supports optional expired URL - Supports expiration in hours - Supports never-expire mode with `0` - Shows generated short URL - Shows target URL - Shows selected domain - Shows selected slug - Shows expiration status - Shows creation timestamp - Supports copy-friendly output - Stores request history locally - Keeps last 100 actions in the browser - Supports history filtering - Uses plan-based query limits - Server-side plan limits apply - Suitable for branded links, support links, documentation links, dashboards, temporary sharing, reports, and internal workflows --- ## 📌 Usage Hints - Pick a custom domain and slug to brand your link. - Use a complete target URL with `https://` or `http://`. - Keep slugs short and readable. - Do not put secrets or private data in slugs. - Set expiry hours for temporary links. - Use `0` when the link should never expire. - Add an expired URL for time-limited links. - Copy and test the short URL before sharing. - Use descriptive slugs for documentation and support links. - Use non-guessable slugs for sensitive workflows. - Monitor remaining plan queries. - Remember that server-side plan limits apply. - Use request history to find recently created links. - Clear browser history on shared or untrusted devices. - Treat short links as redirects and verify the destination before distribution. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX URL Shortener** is a custom short link creation tool for generating compact redirect URLs. It supports API-provided short domains, custom slugs, target URL validation, optional expired URLs, expiration in hours, never-expire mode, copy-friendly results, local request history, filtering, and plan-based query limits. The tool is designed for branded short links, support workflows, documentation shortcuts, dashboard links, temporary sharing, campaign routing, internal communication, reports, and presentations. Users should choose clear slugs, verify target URLs before sharing, use expiration for temporary or sensitive workflows, and avoid placing secrets or private information in short links. # DNSSEC Configuration | DNSSEC Validation, Keys & Signature Analysis Tool [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/hVVuhlLx7DK4mMcB-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/hVVuhlLx7DK4mMcB-image.png) The platform available at **[https://dash.niamonx.io/dnssec\_check](https://dash.niamonx.io/dnssec_check)** — known as **DNSSEC Configuration** — is a DNSSEC validation and diagnostic tool within the NiamonX platform. It analyzes whether a domain is correctly protected with DNSSEC by checking DS records at the parent zone, DNSKEY records at the authoritative zone, RRSIG signatures, validation flags, DNS response status, authoritative name servers, IP nodes, and detected configuration issues. The tool helps users understand whether a domain has a valid DNSSEC trust chain or whether DNSSEC is missing, incomplete, misconfigured, or failing validation. --- ## Overview of the Service **DNSSEC Configuration** is designed to analyze the DNSSEC state of a domain in a structured and readable way. DNSSEC helps protect DNS responses against tampering by using cryptographic signatures and a chain of trust from the parent zone to the domain’s authoritative DNS zone. The tool checks several important parts of DNSSEC configuration: - DS records at the parent zone - DNSKEY records in the domain zone - RRSIG signatures - AD flag behavior - CD flag behavior - RD / RA recursion flags - DNS response status codes - authoritative name servers - resolved IP nodes - DNSSEC-related issues - extended DNS error information, when available The module is useful for DNS administrators, DevOps engineers, security teams, SOC teams, compliance teams, incident responders, domain owners, infrastructure engineers, and OSINT analysts. It is especially helpful when users need to answer questions such as: - Is DNSSEC enabled for this domain? - Is DNSSEC correctly configured? - Are DNSKEY records present? - Is there a DS record in the parent zone? - Are DNSSEC signatures validated successfully? - Is the AD flag set? - Which authoritative name servers are involved? - Which DNS nodes are returned? - What issues prevent a valid DNSSEC trust chain? - Are there extended DNS errors that explain the failure? --- ## 🔍 How the Tool Works When a user enters a domain, DNSSEC Configuration performs DNSSEC-related DNS queries and analyzes the results. Example input: ```text Domain: niamonx.io ``` Example summary result: ```text niamonx.io DNSSEC is NOT correctly configured Issues: 3 DNSKEY: 0 DS: 0 22:58:27 ``` The tool may perform checks for: - DNSKEY records - DS records - RRSIG records - AD flag validation - CD flag state - RD / RA recursion behavior - authoritative name servers - IP nodes - DNS response status - SOA / authority records - extended DNS errors The result is organized into multiple sections: - Summary - Domain status - Issues - DNSKEY query - DS query - RRSIG query - DNS Chain - Authoritative NS - IP nodes - local history --- ## 🧩 Supported Input DNSSEC Configuration accepts domain names only. Correct input examples: ```text niamonx.io ``` ```text example.com ``` ```text cloudflare.com ``` ```text sub.example.com ``` Incorrect input examples: ```text https://niamonx.io ``` ```text http://example.com ``` ```text https://example.com/path ``` ```text example.com/path ``` ```text user@example.com ``` ```text 192.168.1.1 ``` ```text localhost ``` Interface guidance: ```text Enter the domain without the protocol (example.com). ``` Users should enter only the domain name, without `http://`, `https://`, path, query string, fragment, wildcard, or e-mail formatting. --- ## 📊 Summary Section The Summary section provides a compact DNSSEC status overview. Example: ```text niamonx.io DNSSEC is NOT correctly configured Issues: 3 DNSKEY: 0 DS: 0 22:58:27 ``` Typical fields include:
FieldDescription
DomainThe checked domain
StatusDNSSEC validation result
IssuesNumber of detected configuration problems
DNSKEYNumber of DNSKEY records found
DSNumber of DS records found
TimeQuery or result timestamp
The Summary section is useful for quick triage. It immediately shows whether the domain appears to have a valid DNSSEC configuration or whether further investigation is needed. --- ## ✅ Status Validator The tool provides a clear status result. Example: ```text DNSSEC is NOT correctly configured ``` Possible high-level outcomes may include: - DNSSEC is correctly configured - DNSSEC is not correctly configured - DNSSEC validation failed - DNSSEC data is missing - DNSSEC status could not be fully determined A valid DNSSEC configuration normally requires: ```text DS record in the parent zone DNSKEY record in the authoritative zone Valid RRSIG signatures Successful validation AD=true ``` If one or more of these components are missing or invalid, the domain may fail DNSSEC validation. --- ## 🧾 Domain Details The detailed result section shows the checked domain and DNSSEC-related values. Example: ```text Domain: niamonx.io Status: DNSSEC is NOT correctly configured Issues: 3 DNSKEY count: 0 DS count: 0 AD DNSKEY: false AD DS: false AD RRSIG: false Authoritative NS: abdullah.ns.cloudflare.com, ashley.ns.cloudflare.com IP nodes: 104.21.12.231, 172.67.153.184, 2606:4700:3033::6815:ce7, 2606:4700:3030::ac43:99b8 ``` This section helps users understand both the DNSSEC state and the DNS infrastructure involved in the result. --- ## 🔐 DNSSEC Trust Chain DNSSEC depends on a chain of trust. A simplified trust chain looks like this: ```text Root zone → TLD parent zone → Domain DS record → Domain DNSKEY record → Signed DNS records → Validated response ``` For DNSSEC to validate correctly: 1. The parent zone must publish a DS record for the domain. 2. The domain’s authoritative zone must publish matching DNSKEY records. 3. DNS records must be signed with valid RRSIG signatures. 4. A validating resolver must be able to verify the signatures. 5. The response should set `AD=true` when validation succeeds. If the DS record is missing, the chain of trust cannot be established from the parent zone. If DNSKEY records are missing, the domain zone cannot provide the public keys needed to validate signatures. If RRSIG records are missing or invalid, DNSSEC-signed data cannot be validated. --- ## 🚨 Issues Section The Issues section lists detected DNSSEC problems. Example: ```text Issues Total: 3 #1 Missing DNSKEY record #2 Missing DS record #3 No Authenticated Data (AD flag not set) ``` Issues help users quickly identify what needs to be fixed. Common issues may include: - missing DNSKEY record; - missing DS record; - missing RRSIG record; - invalid signatures; - expired signatures; - mismatched DS and DNSKEY; - DNSSEC chain validation failure; - AD flag not set; - unsupported algorithm; - broken delegation; - inconsistent authoritative responses; - resolver validation failure. Each issue should be reviewed in the context of the domain’s DNS provider, registrar configuration, and authoritative zone settings. --- ## 🔑 DNSKEY Section The DNSKEY section shows DNSKEY query details and DNSKEY records when available. Example: ```text DNSKEY AD: false Status: 0 AD: false CD: false RD: true RA: true TC: false Status 0 No DNSKEY records ``` DNSKEY records contain public keys used to validate DNSSEC signatures. A DNSKEY record may include:
FieldDescription
DataDNSKEY record data
FlagsKey role indicator
ProtoDNSSEC protocol field
AlgoCryptographic algorithm
TTLTime to live
Example table when no records exist: ```text # Data Flags Proto Algo TTL No DNSKEY records ``` If no DNSKEY records are found, the domain zone does not provide the public keys required for DNSSEC validation. --- ## 🧬 DNSKEY Flags DNSKEY flags help identify the type of key. Common values include:
FlagMeaning
256Zone Signing Key, often called ZSK
257Key Signing Key, often called KSK
The exact DNSSEC key structure depends on the DNS provider and deployment model. In a typical DNSSEC configuration: - the KSK signs the DNSKEY set; - the ZSK signs ordinary zone records; - the DS record in the parent zone is derived from the KSK. If DNSKEY records are missing, DNSSEC cannot be validated at the domain zone level. --- ## 🧾 DS Section The DS section shows DS query results from the parent zone or authority response. Example: ```text DS AD: false Status: 0 AD: false CD: false RD: true RA: true TC: false Status 0 ``` A DS record connects the parent zone to the child domain’s DNSKEY. A valid DS record is required for a complete DNSSEC trust chain. If the DS record is missing, the parent zone does not delegate DNSSEC trust to the domain. Example issue: ```text Missing DS record ``` The DS section may also show authority records such as SOA, DS, RRSIG, or NSEC/NSEC3-related data. Example authority output: ```text a0.nic.io. hostmaster.donuts.email. 1781729005 7200 900 1209600 3600 ``` This information can help diagnose whether the parent zone returned a negative answer, an authority response, or related DNSSEC denial-of-existence data. --- ## 🧷 RRSIG Section The RRSIG section shows signature query information. Example: ```text RRSIG Query AD: false Status: 0 AD: false CD: false RD: true RA: true TC: false Status 0 Response from 172.64.35.203. ``` RRSIG records contain cryptographic signatures for DNS records. RRSIG is important because it proves that DNS records were signed by the domain’s DNSSEC keys. A valid DNSSEC response generally requires: - signed DNS records; - valid signatures; - non-expired signatures; - matching DNSKEY records; - a valid DS chain from the parent zone; - successful validation by the resolver. If RRSIG validation fails or no authenticated data is returned, the tool may show an issue such as: ```text No Authenticated Data (AD flag not set) ``` --- ## 🏁 AD Flag AD means **Authenticated Data**. Interface hint: ```text AD: Authenticated Data (server verified signatures). ``` Example: ```text AD DNSKEY: false AD DS: false AD RRSIG: false ``` When `AD=true`, the validating resolver indicates that DNSSEC validation succeeded for the response. When `AD=false`, it may mean: - the domain is not signed; - DNSSEC is not configured; - validation failed; - the resolver did not validate the response; - the trust chain is incomplete; - the queried data was not authenticated. For a correctly validated DNSSEC response, `AD=true` is an important positive signal. --- ## 🚫 CD Flag CD means **Checking Disabled**. Interface hint: ```text CD: Checking Disabled (client requested to skip verification). ``` Example: ```text CD: false ``` When `CD=true`, the client asks the resolver not to perform DNSSEC validation. When `CD=false`, DNSSEC validation is not intentionally disabled by the query. The CD flag is useful for diagnosing whether DNSSEC failures are caused by validation behavior or by the underlying DNSSEC configuration. --- ## 🔁 RD and RA Flags RD means **Recursion Desired**. RA means **Recursion Available**. Interface hint: ```text RD / RA: Recursion Desired / Available. ``` Example: ```text RD: true RA: true ``` Meaning:
FlagDescription
RDThe client requested recursive resolution
RAThe resolver supports recursive resolution
These flags help users understand how the DNS query was processed. --- ## 🧯 TC Flag TC means **Truncated**. Example: ```text TC: false ``` If `TC=true`, the DNS response was truncated. This can happen when the response is too large for the transport method and may require retrying over TCP. A truncated DNSSEC response can affect diagnostics because DNSSEC records may be large. --- ## 📟 DNS Status Code The Status field shows the DNS response code. Interface hint: ```text Status: Response code (0=NOERROR). ``` Example: ```text Status: 0 ``` Common DNS response codes include:
CodeMeaning
0NOERROR
1FORMERR
2SERVFAIL
3NXDOMAIN
4NOTIMP
5REFUSED
A status of `0` means the DNS response itself returned `NOERROR`, but it does not automatically mean DNSSEC is correctly configured. DNSSEC may still be missing or unauthenticated. --- ## 🧭 Authoritative Name Servers The DNS Chain section displays authoritative name servers for the domain. Example: ```text Authoritative NS: abdullah.ns.cloudflare.com ashley.ns.cloudflare.com ``` Authoritative name servers are responsible for serving the domain’s DNS zone. This information is useful for: - identifying the DNS provider; - troubleshooting DNSSEC setup; - confirming authoritative infrastructure; - checking whether the correct provider is serving the zone; - comparing registrar and DNS provider configuration; - diagnosing inconsistent records. If DNSSEC is missing or broken, the authoritative DNS provider configuration should be reviewed. --- ## 🌐 IP Nodes The DNS Chain section may also show IP nodes associated with the domain or authoritative resolution path. Example: ```text IP nodes: 104.21.12.231 172.67.153.184 2606:4700:3033::6815:ce7 2606:4700:3030::ac43:99b8 ``` IP nodes are useful for understanding the infrastructure returned by DNS resolution. They may represent: - CDN edge addresses; - web service addresses; - cloud provider infrastructure; - IPv4 addresses; - IPv6 addresses; - provider-managed routing endpoints. IP nodes should not be confused with DNSSEC keys. They are infrastructure addresses, not DNSSEC trust records. --- ## 💬 Query Comments The tool may display comments showing where a response came from. Examples: ```text DNSKEY Comment: Response from 173.245.58.71. ``` ```text DS Comment: Response from 2a01:8840:a1::17. ``` ```text RRSIG Comment: Response from 172.64.35.203. ``` These comments are useful for diagnostics because they show which resolver or server returned the response. Response comments can help analysts identify: - which server answered; - whether IPv4 or IPv6 was involved; - which infrastructure path was used; - whether different queries were answered by different nodes. --- ## 🧠 Extended DNS Errors Extended DNS Errors provide additional diagnostic information for DNS failures. Interface hint: ```text Extended DNS Errors: Additional codes (RFC 8914) for failure diagnostics. ``` Extended DNS Errors may help explain: - DNSSEC validation failure; - unsupported algorithm; - stale answer; - blocked query; - filtered response; - network error; - resolver policy issue; - invalid data; - missing signature; - bogus DNSSEC state. If extended errors are present, they should be reviewed together with DNSKEY, DS, RRSIG, and response flags. --- ## 🕓 History of Domains DNSSEC Configuration stores recently checked domains locally in the browser. Example interface section: ```text History of domains Filter... ``` History helps users: - repeat previous DNSSEC checks; - compare recent domain states; - continue troubleshooting sessions; - filter previously checked domains; - revisit domains after DNS changes. Because history is stored locally, it may be removed when browser data is cleared, a private browsing session is used, or the user switches devices or browser profiles. On shared or untrusted devices, users should clear local history after checking sensitive customer domains, investigation targets, or internal infrastructure. --- ## 📤 Copying and Exporting DNSSEC Configuration supports copying and exporting results. Available actions may include: - copy summary; - copy DNSSEC issues; - copy DNSKEY data; - copy DS data; - copy RRSIG results; - copy raw diagnostic output; - export results for reporting. Copying and exporting are useful for: - DNS troubleshooting tickets; - registrar support requests; - DNS provider support cases; - compliance reports; - SOC notes; - incident response documentation; - domain security reviews; - technical audit evidence. --- ## 🔎 Common Use Cases ### DNSSEC Configuration Check Verify whether a domain has DNSSEC enabled and correctly configured. ### Domain Security Audit Review DNSSEC status as part of a broader domain security assessment. ### Registrar Configuration Review Check whether DS records are published correctly at the parent zone. ### DNS Provider Troubleshooting Check whether DNSKEY and RRSIG records exist in the authoritative DNS zone. ### Incident Response Investigate whether DNS tampering protection is enabled for a domain involved in an incident. ### Compliance Documentation Document DNSSEC posture for compliance, audit, or risk management. ### Migration Validation Verify DNSSEC after changing DNS providers, registrars, nameservers, or signing configuration. ### Broken DNSSEC Diagnosis Identify whether validation failures are caused by missing DS, missing DNSKEY, invalid signatures, or resolver behavior. ### Infrastructure Review Map authoritative name servers and IP nodes involved in DNS resolution. ### OSINT and Defensive Research Check DNSSEC posture of domains during domain intelligence or external attack surface review. --- ## 🧠 Recommended Workflow A practical DNSSEC Configuration workflow should follow these steps. ### 1. Enter the Domain Use only the domain name. Example: ```text niamonx.io ``` Do not enter: ```text https://niamonx.io ``` --- ### 2. Review the Summary Start with the high-level status. Example: ```text DNSSEC is NOT correctly configured Issues: 3 DNSKEY: 0 DS: 0 ``` This quickly shows whether DNSSEC is working or requires troubleshooting. --- ### 3. Review the Issues List Check every issue reported by the tool. Example: ```text Missing DNSKEY record Missing DS record No Authenticated Data (AD flag not set) ``` The issue list provides the most direct explanation of the DNSSEC problem. --- ### 4. Check DS Records Review whether the parent zone publishes a DS record. Example issue: ```text Missing DS record ``` If DS is missing, DNSSEC trust cannot be established from the parent zone. This is often configured at the domain registrar. --- ### 5. Check DNSKEY Records Review whether DNSKEY records exist in the authoritative zone. Example issue: ```text Missing DNSKEY record ``` If DNSKEY is missing, the domain zone is not providing public keys for DNSSEC validation. This is usually configured at the DNS provider. --- ### 6. Check RRSIG and AD Flag Review whether signatures are present and whether authenticated data is returned. Example: ```text AD RRSIG: false ``` If `AD=false`, the response was not authenticated by the validating resolver. --- ### 7. Review Authoritative Name Servers Confirm that the expected name servers are authoritative. Example: ```text abdullah.ns.cloudflare.com ashley.ns.cloudflare.com ``` If the domain recently changed DNS providers, make sure the registrar and authoritative DNS provider are aligned. --- ### 8. Review IP Nodes Check which IP nodes were returned. Example: ```text 104.21.12.231 172.67.153.184 2606:4700:3033::6815:ce7 2606:4700:3030::ac43:99b8 ``` This helps understand the visible DNS infrastructure, although these IPs are not DNSSEC records. --- ### 9. Review Extended Errors If extended DNS errors are present, use them to diagnose the failure. Possible reasons may include: - validation failure; - missing signature; - bogus DNSSEC state; - unsupported algorithm; - resolver policy issue; - stale DNSSEC data. --- ### 10. Export or Copy Results Save the DNSSEC diagnostic output for troubleshooting. Recommended record: ```text Domain: niamonx.io Status: DNSSEC is NOT correctly configured Issues: 3 DNSKEY count: 0 DS count: 0 AD DNSKEY: false AD DS: false AD RRSIG: false Authoritative NS: abdullah.ns.cloudflare.com, ashley.ns.cloudflare.com Checked at: 22:58:27 ``` --- ## 🧰 DNSSEC Troubleshooting Guide ### Missing DS Record Issue: ```text Missing DS record ``` Meaning: The parent zone does not publish a DS record for the domain. Possible causes: - DNSSEC was not enabled at the registrar; - DS record was not submitted; - DS record was removed; - registrar configuration is incomplete; - DNSSEC setup was started but not finalized; - domain was moved to another DNS provider without updating DS. Recommended actions: - check DNSSEC settings at the registrar; - obtain DS record from the DNS provider; - publish DS at the parent zone through the registrar; - wait for DNS propagation; - rerun the DNSSEC check. --- ### Missing DNSKEY Record Issue: ```text Missing DNSKEY record ``` Meaning: The authoritative DNS zone does not publish DNSKEY records. Possible causes: - DNSSEC is not enabled at the DNS provider; - the DNS provider does not serve signed records; - DNSSEC was disabled; - the domain uses name servers that are not configured for DNSSEC; - the zone is not signed. Recommended actions: - enable DNSSEC at the authoritative DNS provider; - confirm that the zone is signed; - verify that DNSKEY records are published; - confirm that the registrar uses matching DS records; - rerun the check after propagation. --- ### AD Flag Not Set Issue: ```text No Authenticated Data (AD flag not set) ``` Meaning: The resolver did not return authenticated DNSSEC-validated data. Possible causes: - DNSSEC is not configured; - DNSSEC chain is incomplete; - signatures are missing or invalid; - resolver did not validate the response; - DS and DNSKEY do not match; - the response is unsigned; - DNSSEC validation failed. Recommended actions: - check DS records; - check DNSKEY records; - check RRSIG records; - verify the resolver supports DNSSEC validation; - review extended DNS errors; - rerun the test after DNS changes. --- ### Status 0 but DNSSEC Not Valid A DNS status code of `0` means `NOERROR`, but this only means the DNS query succeeded. Example: ```text Status: 0 ``` This does not mean DNSSEC is correctly configured. A domain can return `NOERROR` while still having: - no DS record; - no DNSKEY record; - no RRSIG; - no AD flag; - invalid DNSSEC chain. Always review DNSSEC-specific fields, not only the DNS response status. --- ## 🚦 Server Errors and Retry Behavior In some cases, the processing server may return an error. Interface note: ```text In case of a processing server error and receiving a 500 error, please repeat your request several times. ``` A temporary server-side error may be caused by: - resolver timeout; - upstream DNS failure; - transient network problem; - DNS provider response issue; - processing timeout; - temporary backend error. If this happens, repeat the request. If the issue continues, compare results with another DNSSEC validation method and contact support if needed. --- ## 📊 Interpreting Results Correctly DNSSEC Configuration results should be interpreted carefully. Important notes: - Missing DNSKEY means the zone does not expose DNSSEC keys. - Missing DS means the parent zone does not establish DNSSEC trust. - AD=false means the response was not authenticated by the validating resolver. - Status 0 means DNS query success, not DNSSEC success. - A domain may resolve normally even when DNSSEC is not configured. - DNSSEC protects DNS integrity, not website content. - DNSSEC does not replace HTTPS or TLS. - DNSSEC misconfiguration can cause resolution failures for validating resolvers. - DNSSEC changes may require propagation time. - Registrar and DNS provider settings must match. - DNS provider migration can break DNSSEC if DS records are not updated. - DNSSEC validation should be retested after changes. DNSSEC is one layer of domain security. It should be used together with HTTPS, HSTS, secure registrar accounts, MFA, DNS change monitoring, SPF, DKIM, DMARC, and proper access control. --- ## 🧾 Recommended Reporting Format When documenting DNSSEC status, use a consistent structure. Example: ```text Domain: niamonx.io Check time: 22:58:27 Status: DNSSEC is NOT correctly configured Issues: 1. Missing DNSKEY record 2. Missing DS record 3. No Authenticated Data (AD flag not set) Counts: DNSKEY: 0 DS: 0 Flags: AD DNSKEY: false AD DS: false AD RRSIG: false Authoritative name servers: - abdullah.ns.cloudflare.com - ashley.ns.cloudflare.com IP nodes: - 104.21.12.231 - 172.67.153.184 - 2606:4700:3033::6815:ce7 - 2606:4700:3030::ac43:99b8 ``` For a remediation report, add: ```text Recommended remediation: Enable DNSSEC signing at the authoritative DNS provider, publish DNSKEY records, add the matching DS record at the registrar or parent zone, wait for propagation, and rerun DNSSEC validation until AD=true is returned. ``` --- ## 🛡️ Security, Privacy & Responsible Use DNSSEC Configuration is intended for lawful DNS security analysis, infrastructure review, compliance, troubleshooting, and defensive cybersecurity workflows. Acceptable use cases include: - checking your own domains; - auditing customer domains with authorization; - validating DNSSEC after DNS changes; - troubleshooting broken DNSSEC; - reviewing registrar and DNS provider configuration; - documenting domain security posture; - supporting compliance checks; - investigating DNS-related incidents; - reviewing external attack surface; - validating DNSSEC deployment status. Users should follow responsible use principles: - Do not treat DNSSEC failure as proof of compromise. - Do not make attribution claims based only on DNSSEC status. - Validate important findings with additional DNS tools. - Use results as technical diagnostics, not legal conclusions. - Store domain security reports securely. - Follow authorization boundaries when auditing third-party domains. - Coordinate DNSSEC changes carefully to avoid outages. - Confirm registrar and DNS provider settings before publishing DS records. DNSSEC misconfiguration can affect domain availability. Changes should be planned and tested carefully. --- ## ⚙️ Technical Highlights - DNSSEC validation tool - Available at `dash.niamonx.io/dnssec_check` - Checks domain DNSSEC configuration - Accepts domains without protocol - Validates DS records at parent level - Checks DNSKEY records - Checks RRSIG signatures - Reports AD flag state - Reports CD flag state - Reports RD and RA flags - Reports TC flag - Displays DNS response status code - Shows DNSKEY count - Shows DS count - Displays DNSKEY flags, protocol, algorithm, and TTL when available - Displays DS authority / SOA information - Displays RRSIG query results - Shows extended DNS errors when available - Lists DNSSEC issues - Shows authoritative name servers - Shows IP nodes - Provides DNS query comments - Supports copying and exporting - Maintains local domain history - Supports history filtering - Suitable for DNS administrators, DevOps, SOC, compliance, incident response, OSINT, and domain security reviews --- ## 📌 Usage Hints - Enter only the domain, such as `example.com`. - Do not include `https://` or `http://`. - Review the Summary section first. - Check whether the status is OK or not OK. - Review the Issues list before looking at raw DNS data. - A valid trust chain requires DS in the parent zone. - A valid zone requires DNSKEY records. - DNSSEC-signed records require valid RRSIG signatures. - `AD=true` indicates authenticated data from a validating resolver. - `CD=true` means checking was disabled. - `RD=true` means recursion was requested. - `RA=true` means recursion was available. - `Status 0` means NOERROR, not necessarily DNSSEC success. - Review Extended DNS Errors for failure diagnostics. - Check authoritative name servers when troubleshooting. - Retest after DNSSEC changes and propagation. - Repeat the request if a temporary server-side 500 error occurs. - Use exported results for registrar or DNS provider support cases. - Treat DNSSEC as one part of a broader domain security posture. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX DNSSEC Configuration** is a DNSSEC validation and diagnostics tool for checking whether a domain has a valid DNSSEC configuration. It analyzes DS records, DNSKEY records, RRSIG signatures, AD/CD flags, RD/RA flags, DNS response status, authoritative name servers, IP nodes, issues, comments, and extended DNS error information. The tool is designed for DNS security audits, domain hardening, compliance checks, DNS provider troubleshooting, registrar validation, incident response, OSINT, and infrastructure review. A correct DNSSEC trust chain requires a valid DS record in the parent zone, DNSKEY records in the authoritative zone, valid signatures, and authenticated DNS responses. Results should be interpreted as DNSSEC diagnostics and combined with broader domain security checks such as HTTPS, TLS, HSTS, registrar security, SPF, DKIM, DMARC, DNS monitoring, and access control. # DMARC Policy & Configuration | DMARC Record Analysis Tool [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/g5NYt841qzyjpFwV-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/g5NYt841qzyjpFwV-image.png) The platform available at **[https://dash.niamonx.io/dmarc\_check](https://dash.niamonx.io/dmarc_check)** — known as **DMARC Policy & Configuration** — is an e-mail domain security analysis tool within the NiamonX platform. It checks whether a domain has a valid DMARC record, extracts and parses DMARC tags, identifies the active policy, analyzes reporting configuration, evaluates alignment settings, highlights security gaps, and provides a practical risk score. The tool helps domain owners, security teams, SOC analysts, administrators, compliance teams, and investigators understand how a domain handles unauthenticated e-mail and whether its DMARC configuration is strong enough to protect against spoofing and phishing. --- ## Overview of the Service **DMARC Policy & Configuration** analyzes the DMARC record published at: ```text _dmarc.domain ``` DMARC, which stands for **Domain-based Message Authentication, Reporting, and Conformance**, is an e-mail authentication policy framework. It works together with SPF and DKIM to help receiving mail servers determine whether messages claiming to come from a domain are legitimate. The tool checks the DMARC TXT record, parses its tags, displays the active policy, and evaluates whether the domain is using a monitoring-only policy or an enforcement policy. The module can analyze: - DMARC record existence - DMARC version validity - domain policy - subdomain policy - aggregate reporting addresses - forensic reporting addresses - DKIM alignment mode - SPF alignment mode - failure reporting options - policy coverage percentage - security posture - risk score - parsed DMARC tags - analysis checks - exportable results This makes the tool useful for e-mail security audits, anti-phishing hardening, domain protection, compliance reviews, brand protection, SOC workflows, and infrastructure security assessments. --- ## 🔍 How the Tool Works When a user enters a domain, the tool queries the DMARC TXT record for that domain and analyzes the returned policy. Example input: ```text Domain: niamonx.com ``` The tool checks the DNS location: ```text _dmarc.niamonx.com ``` Example result: ```text Domain: niamonx.com Policy: none Tags: 3 23:04:59 ``` Example parsed DMARC record: ```text v=DMARC1; p=none; rua=mailto:rua@dmarc.brevo.com ``` Example analysis result: ```text record_exists: OK valid_version: OK policy_enabled: FAIL reporting_enabled: OK strict_alignment: FAIL Risk Score: 40 / 100 ``` The result helps users understand whether DMARC is present, whether it is only monitoring mail, whether reports are enabled, and whether stricter protection should be considered. --- ## 🧩 Supported Input DMARC Policy & Configuration accepts second-level domains and subdomains. Correct examples: ```text niamonx.com ``` ```text example.com ``` ```text sub.example.com ``` ```text company.org ``` Incorrect examples: ```text https://niamonx.com ``` ```text http://example.com ``` ```text https://example.com/path ``` ```text user@example.com ``` ```text 192.168.1.1 ``` ```text _dmarc.example.com ``` Interface guidance: ```text Only a second-level domain or subdomain (without https://). ``` Users should enter only the domain or subdomain. The tool automatically checks the correct DMARC DNS location by querying `_dmarc.` in front of the submitted domain. --- ## 📊 Result Section The Result section provides a quick summary of the DMARC configuration. Example: ```text niamonx.com Policy: none Tags: 3 23:04:59 ``` Typical fields include:
FieldDescription
DomainThe checked domain
PolicyActive DMARC domain policy
TagsNumber of parsed DMARC tags
TimeQuery or result timestamp
The Result section is useful for quick triage. It immediately shows whether the domain has a DMARC policy and whether that policy is monitoring-only or enforcement-based. --- ## 🧾 Domain Details The detailed result view shows the parsed DMARC configuration. Example: ```text Domain: niamonx.com Policy (p): none Subdomain (sp): (inherits p) Reports (rua): mailto:rua@dmarc.brevo.com Percentage (pct): 100 (implicit) fo: 0 (default) adkim: r (default) aspf: r (default) ``` This view helps users understand both explicit and implicit DMARC values. Some values may be shown as default because they were not explicitly present in the DNS record but are defined by DMARC behavior. --- ## 🛡️ Policy Field The **Policy (p)** field defines what receiving mail servers should do when a message fails DMARC validation. Example: ```text Policy (p): none ``` DMARC supports three main policy levels:
PolicyMeaning
noneMonitor only; do not request enforcement
quarantineTreat failing messages as suspicious
rejectReject failing messages
### p=none Example: ```text p=none ``` `p=none` means that the domain is collecting DMARC information but is not asking receivers to quarantine or reject failing messages. This is useful during initial deployment and monitoring, but it does not provide strong spoofing protection by itself. ### p=quarantine Example: ```text p=quarantine ``` `p=quarantine` requests that receiving mail servers treat DMARC-failing messages as suspicious. These messages may be placed in spam or quarantine. ### p=reject Example: ```text p=reject ``` `p=reject` is the strongest policy. It requests that receiving mail servers reject messages that fail DMARC validation. For mature configurations, `p=reject` is usually the strongest anti-spoofing posture. --- ## 🧭 Subdomain Policy The **Subdomain Policy (sp)** field controls how DMARC should apply to subdomains. Example: ```text Subdomain (sp): (inherits p) ``` If `sp` is not defined, subdomains inherit the main domain policy. Example: ```text p=none sp not defined Result: subdomains inherit p=none ``` Possible `sp` values include: ```text sp=none sp=quarantine sp=reject ``` The subdomain policy is important because attackers may try to spoof or abuse subdomains if the root domain has incomplete enforcement. Recommended practice: - define `sp` explicitly for high-value domains; - use `sp=quarantine` or `sp=reject` when subdomain mail flows are understood; - review legitimate subdomain mail senders before enforcement. --- ## 📬 Aggregate Reports: RUA The **rua** tag defines where aggregate DMARC reports should be sent. Example: ```text rua=mailto:rua@dmarc.brevo.com ``` Aggregate reports provide summarized information about mail claiming to come from the domain. They may include: - sending IP addresses; - authentication results; - SPF alignment results; - DKIM alignment results; - message counts; - policy evaluation results; - receiver information; - pass/fail statistics. In the tool result, RUA may be shown as: ```text Reports (rua): mailto:rua@dmarc.brevo.com ``` Reporting is important because it allows domain owners to monitor legitimate and unauthorized e-mail sources before moving to stricter policies. --- ## 🧪 Forensic Reports: RUF The **ruf** tag defines where forensic or failure reports may be sent. Example: ```text ruf=mailto:forensic@example.com ``` If no forensic report address is configured, the tool may show: ```text RUF: — ``` Forensic reports can contain more detailed failure information, but support varies between receivers and privacy restrictions may limit their availability. RUF should be configured carefully because failure reports may contain sensitive message details or metadata. --- ## 📈 Percentage: PCT The **pct** tag defines the percentage of messages to which the DMARC policy should be applied. Example: ```text pct=100 ``` If `pct` is not explicitly defined, the tool may show: ```text Percentage (pct): 100 (implicit) ``` This means the policy applies to 100% of relevant messages by default. Use cases for `pct`: - gradual enforcement rollout; - testing quarantine or reject policies; - limiting impact during migration; - phased deployment for large mail environments. Example phased rollout: ```text p=quarantine; pct=25 p=quarantine; pct=50 p=quarantine; pct=100 p=reject; pct=25 p=reject; pct=50 p=reject; pct=100 ``` --- ## ⚙️ Failure Options: FO The **fo** tag controls failure reporting options. Example default: ```text fo: 0 (default) ``` Common values include:
ValueMeaning
0Generate reports if both SPF and DKIM fail to produce an aligned pass
1Generate reports if either SPF or DKIM fails
dGenerate reports if DKIM fails
sGenerate reports if SPF fails
The default value is: ```text fo=0 ``` Failure options are mainly relevant when forensic reporting is configured and supported. --- ## 🔐 DKIM Alignment: ADKIM The **adkim** tag defines DKIM alignment strictness. Example default: ```text adkim: r (default) ``` Possible values:
ValueMeaning
rRelaxed alignment
sStrict alignment
Relaxed DKIM alignment allows organizational-domain alignment. Strict DKIM alignment requires a closer match between the DKIM signing domain and the visible From domain. Example: ```text adkim=s ``` Strict alignment provides stronger control but may break legitimate mail if third-party senders are not configured properly. --- ## 🔐 SPF Alignment: ASPF The **aspf** tag defines SPF alignment strictness. Example default: ```text aspf: r (default) ``` Possible values:
ValueMeaning
rRelaxed alignment
sStrict alignment
Relaxed SPF alignment allows organizational-domain alignment between the SPF-authenticated domain and the visible From domain. Strict SPF alignment requires a closer match. Example: ```text aspf=s ``` Strict SPF alignment can improve security but should be enabled only after confirming all legitimate mail sources are correctly aligned. --- ## 🧾 Parsed Tags Table The tool displays parsed DMARC tags in a structured table. Example:
TagValueDescription
vDMARC1Protocol version
pnonePolicy for domain
ruamailto:rua@dmarc.brevo.comAggregate report URIs
Example record: ```text v=DMARC1; p=none; rua=mailto:rua@dmarc.brevo.com ``` The tag table helps users understand exactly which DMARC values are present in the DNS record. --- ## 🧠 Analysis Section The Analysis section translates raw DMARC tags into practical configuration meaning. Example: ```text Policy: none Subdomain Policy: inherit RUA: mailto:rua@dmarc.brevo.com RUF: — DKIM Alignment: r SPF Alignment: r Failure Options: 0 Coverage %: 100 ``` This section is useful for both technical and non-technical review because it explains the active DMARC posture in a structured format. --- ## ✅ Configuration Checks The tool performs several checks to evaluate DMARC health. Example: ```text Check: record_exists OK Check: valid_version OK Check: policy_enabled FAIL Check: reporting_enabled OK Check: strict_alignment FAIL ``` ### record\_exists Checks whether a DMARC record exists. Example: ```text record_exists: OK ``` If this check fails, the domain does not have a detectable DMARC record. --- ### valid\_version Checks whether the record uses a valid DMARC version tag. Example: ```text valid_version: OK ``` A valid DMARC record should include: ```text v=DMARC1 ``` --- ### policy\_enabled Checks whether the domain uses an enforcement policy. Example: ```text policy_enabled: FAIL ``` This may fail when the policy is: ```text p=none ``` `p=none` is valid for monitoring, but it does not request quarantine or rejection of failing messages. --- ### reporting\_enabled Checks whether DMARC reporting is configured. Example: ```text reporting_enabled: OK ``` This usually means that `rua` is present. Example: ```text rua=mailto:rua@dmarc.brevo.com ``` --- ### strict\_alignment Checks whether strict alignment is configured. Example: ```text strict_alignment: FAIL ``` This may fail when both alignment tags use relaxed mode or default relaxed behavior: ```text adkim=r aspf=r ``` Strict alignment is not always required, but it can improve protection for mature domains after legitimate senders are validated. --- ## 📊 Risk Score The tool provides a risk score to help prioritize remediation. Example: ```text Risk Score: 40 / 100 ``` A lower score may indicate a weaker DMARC posture, while a higher score may indicate stronger protection. The score may be influenced by: - whether a DMARC record exists; - whether the version is valid; - whether the domain uses `p=none`, `p=quarantine`, or `p=reject`; - whether aggregate reporting is enabled; - whether forensic reporting is configured; - whether strict alignment is enabled; - whether coverage is set to 100%; - whether subdomain policy is defined; - whether required tags are present. Example interpretation:
Score RangeGeneral Meaning
0–30Weak or missing DMARC protection
31–60Basic monitoring or partial configuration
61–80Good configuration with some improvement areas
81–100Strong DMARC enforcement posture
The score should be treated as a practical guidance indicator, not as the only measure of e-mail security. --- ## 📚 Reference by Tags ### v — Version Defines the DMARC protocol version. Example: ```text v=DMARC1 ``` This tag is required. --- ### p — Domain Policy Defines the policy for the main domain. Example: ```text p=none ``` Possible values: ```text none quarantine reject ``` --- ### sp — Subdomain Policy Defines the policy for subdomains. Example: ```text sp=reject ``` If `sp` is not present, subdomains inherit the main `p` policy. --- ### rua — Aggregate Reports Defines addresses for aggregate DMARC reports. Example: ```text rua=mailto:rua@example.com ``` Multiple report destinations may be separated by commas. --- ### ruf — Forensic Reports Defines addresses for forensic or failure reports. Example: ```text ruf=mailto:forensic@example.com ``` Support for RUF varies across mail receivers. --- ### pct — Policy Percentage Defines what percentage of messages the policy applies to. Example: ```text pct=100 ``` If omitted, the default is 100. --- ### fo — Failure Options Defines reporting behavior for SPF and DKIM failures. Example: ```text fo=0 ``` Common values: ```text 0 1 d s ``` --- ### adkim — DKIM Alignment Defines DKIM alignment strictness. Example: ```text adkim=s ``` Possible values: ```text r s ``` `r` means relaxed. `s` means strict. --- ### aspf — SPF Alignment Defines SPF alignment strictness. Example: ```text aspf=s ``` Possible values: ```text r s ``` `r` means relaxed. `s` means strict. --- ## 🧪 Example DMARC Configurations ### Monitoring-Only DMARC ```text v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com ``` Meaning: - DMARC exists. - Reports are enabled. - No enforcement is requested. - Good for initial monitoring. - Not strong enough for anti-spoofing enforcement. Best for: - first deployment; - mail source discovery; - monitoring legitimate senders; - preparing for enforcement. --- ### Quarantine Policy ```text v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=100 ``` Meaning: - DMARC is enabled. - Failing messages should be treated as suspicious. - Aggregate reports are enabled. - Policy applies to 100% of messages. Best for: - intermediate enforcement; - reducing spoofing risk; - phased rollout before rejection. --- ### Reject Policy ```text v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; pct=100 ``` Meaning: - Strong DMARC enforcement is enabled. - Failing messages should be rejected. - Aggregate reports are enabled. - Policy applies to all messages. Best for: - mature domains; - high-value brands; - anti-phishing protection; - domains with verified mail sources. --- ### Strict Alignment Policy ```text v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s; pct=100 ``` Meaning: - Strong enforcement for domain and subdomains. - Strict DKIM alignment. - Strict SPF alignment. - Aggregate reports enabled. - Full coverage. Best for: - high-security domains; - mature e-mail infrastructure; - brands with high spoofing risk; - organizations with controlled sender inventory. --- ## 🧠 Recommended DMARC Deployment Workflow A practical DMARC deployment workflow should be gradual. ### 1. Publish a Monitoring Policy Start with: ```text v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com ``` This allows the organization to collect reports without affecting mail delivery. --- ### 2. Analyze Reports Review aggregate reports to identify all legitimate senders. Check: - corporate mail provider; - marketing platforms; - CRM systems; - support systems; - transactional e-mail services; - billing systems; - cloud applications; - legacy mail servers; - third-party vendors. --- ### 3. Fix SPF and DKIM Alignment Make sure legitimate senders pass SPF or DKIM alignment. Review: ```text SPF pass and aligned DKIM pass and aligned Visible From domain Return-Path domain DKIM d= domain ``` --- ### 4. Move to Quarantine After monitoring, move to: ```text v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=100 ``` Optionally start with a lower percentage: ```text pct=25 ``` Then increase gradually. --- ### 5. Move to Reject After confirming legitimate mail is aligned, move to: ```text v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; pct=100 ``` This gives stronger protection against spoofing. --- ### 6. Define Subdomain Policy Add an explicit subdomain policy. Example: ```text sp=reject ``` This helps protect unused or unmanaged subdomains. --- ### 7. Consider Strict Alignment After confirming all senders are properly configured, consider: ```text adkim=s; aspf=s ``` Strict alignment should be tested carefully before production deployment. --- ## 🚨 Common DMARC Issues ### Missing DMARC Record The domain has no detectable DMARC TXT record. Risk: - spoofing protection is weak; - no DMARC reports are received; - attackers can impersonate the domain more easily. Recommended action: ```text Publish a DMARC record at _dmarc.domain with at least p=none and a valid rua address. ``` --- ### Policy Is Set to None Example: ```text p=none ``` Risk: - reports may be collected; - failing mail is not quarantined or rejected; - spoofing protection is limited. Recommended action: ```text After monitoring legitimate mail sources, move to p=quarantine or p=reject. ``` --- ### Reporting Is Not Enabled Missing `rua`. Risk: - no aggregate visibility; - difficult to identify legitimate senders; - difficult to safely move toward enforcement. Recommended action: ```text Add rua=mailto:dmarc-reports@example.com or use a trusted DMARC reporting provider. ``` --- ### Subdomain Policy Not Defined Missing `sp`. Risk: - subdomains inherit the main policy; - weak root policy may also weaken subdomain protection; - attackers may abuse unused subdomains. Recommended action: ```text Define sp=quarantine or sp=reject after reviewing legitimate subdomain mail usage. ``` --- ### Relaxed Alignment Example: ```text adkim=r aspf=r ``` Risk: - relaxed alignment is easier to operate; - strict identity matching is not enforced; - some spoofing scenarios may be harder to restrict. Recommended action: ```text Consider strict alignment only after all legitimate senders are validated. ``` --- ### Low Policy Coverage Example: ```text pct=25 ``` Risk: - only part of failing mail is affected by the enforcement policy; - spoofing protection is partial. Recommended action: ```text Gradually increase pct to 100 after validating mail delivery. ``` --- ## 🔎 Common Use Cases ### Domain Anti-Spoofing Review Check whether a domain is protected against spoofed e-mail. ### Phishing Defense Evaluate whether attackers can easily send unauthenticated mail using the domain in the visible From address. ### Brand Protection Review DMARC enforcement for high-value brand domains and customer-facing domains. ### SOC Triage Quickly check DMARC posture during phishing investigations. ### Mail Security Audit Review policy, reporting, SPF alignment, DKIM alignment, and subdomain behavior. ### Compliance Documentation Document whether e-mail authentication controls are deployed. ### Vendor Mail Review Confirm whether third-party senders are included in SPF and DKIM alignment before enforcement. ### Migration Monitoring Monitor DMARC reports when moving mail providers or adding new sending services. ### Subdomain Protection Review Check whether subdomain policy is inherited or explicitly enforced. ### Risk Prioritization Use the risk score and checks to prioritize remediation. --- ## 🧾 Recommended Reporting Format When documenting a DMARC check, use a consistent format. Example: ```text Domain: niamonx.com Check time: 23:04:59 DMARC Status: Record exists: OK Valid version: OK Policy enabled: FAIL Reporting enabled: OK Strict alignment: FAIL Policy: p=none sp=inherits p pct=100 implicit fo=0 default adkim=r default aspf=r default Reports: RUA: mailto:rua@dmarc.brevo.com RUF: — Risk Score: 40 / 100 Parsed tags: v=DMARC1 p=none rua=mailto:rua@dmarc.brevo.com ``` Recommended remediation note: ```text The domain has a valid DMARC record with aggregate reporting enabled, but the policy is set to p=none. This is suitable for monitoring, but it does not enforce protection against spoofed messages. After reviewing reports and confirming legitimate senders, move gradually to p=quarantine and then p=reject. ``` --- ## 🛡️ Security, Privacy & Responsible Use DMARC Policy & Configuration is intended for lawful e-mail security analysis, domain protection, compliance, anti-phishing review, and defensive cybersecurity workflows. Acceptable use cases include: - checking your own domains; - auditing customer domains with authorization; - reviewing anti-spoofing posture; - preparing DMARC deployment; - monitoring mail authentication readiness; - supporting phishing investigations; - documenting compliance controls; - reviewing brand protection risks; - validating mail provider migrations; - checking subdomain policy inheritance. Users should follow responsible use principles: - Do not assume a weak DMARC policy proves compromise. - Do not use DMARC results alone for attribution. - Validate findings with SPF, DKIM, DNS, and mail-flow evidence. - Review aggregate reports before moving to enforcement. - Coordinate changes with mail administrators and vendors. - Avoid publishing strict policies without testing legitimate senders. - Store reports securely because DMARC reports may reveal mail infrastructure. - Use authorized workflows when checking third-party domains. DMARC is a powerful control, but incorrect enforcement can disrupt legitimate mail delivery. --- ## 🚦 Server Errors and Retry Behavior In some cases, the system may return a server-side error. Interface note: ```text If you receive a 500 error from the database, repeat your request several times. ``` Temporary errors may be caused by: - database processing issues; - DNS lookup failure; - network timeout; - upstream resolver issue; - temporary backend error; - malformed or unusual DNS response. If the error persists, repeat the query later and compare results with raw DNS tools or another validation method. --- ## 📊 Interpreting Results Correctly DMARC results should be interpreted carefully. Important notes: - `p=none` is valid but monitoring-only. - `p=quarantine` provides partial enforcement. - `p=reject` provides the strongest enforcement. - `rua` enables aggregate visibility. - Missing `rua` makes monitoring harder. - Missing `sp` means subdomains inherit the main policy. - `pct=100` may be implicit even if not written in the record. - `adkim=r` and `aspf=r` are relaxed defaults. - Strict alignment can improve security but may break legitimate mail if deployed too early. - DMARC depends on SPF and DKIM alignment. - DMARC does not replace SPF or DKIM. - DMARC does not stop all phishing, especially lookalike domains. - DMARC protects the visible From domain from direct spoofing. - Enforcement should be deployed gradually after monitoring. A strong e-mail security posture normally includes SPF, DKIM, DMARC, secure DNS, monitored reports, vendor governance, and domain abuse monitoring. --- ## ⚙️ Technical Highlights - DMARC policy analysis tool - Available at `dash.niamonx.io/dmarc_check` - Checks `_dmarc.domain` - Supports second-level domains and subdomains - Accepts domains without protocol - Parses DMARC TXT records - Supports RFC 7489-style DMARC analysis - Parses `v`, `p`, `sp`, `rua`, `ruf`, `pct`, `fo`, `adkim`, and `aspf` - Displays active policy level - Highlights `none`, `quarantine`, and `reject` - Shows aggregate report URIs - Shows forensic report URIs - Displays DKIM alignment mode - Displays SPF alignment mode - Shows failure reporting options - Shows policy coverage percentage - Performs record existence check - Performs version validation check - Performs policy enforcement check - Performs reporting check - Performs strict alignment check - Calculates risk score - Displays parsed tag table - Shows analysis messages - Supports domain history in LocalStorage - Supports copying and exporting - Suitable for e-mail security audits, anti-phishing defense, SOC workflows, compliance, and brand protection --- ## 📌 Usage Hints - Enter only the domain, such as `example.com`. - Do not include `https://` or `http://`. - Do not enter `_dmarc.example.com`; enter `example.com`. - Start by checking whether the record exists. - Confirm that `v=DMARC1` is present. - Review the active `p` policy. - Treat `p=none` as monitoring-only. - Use `rua` to collect aggregate reports. - Review whether `sp` is explicitly configured. - Check whether `pct` is 100. - Review `adkim` and `aspf` alignment modes. - Move gradually from `p=none` to `p=quarantine` and then `p=reject`. - Validate legitimate senders before enforcing rejection. - Use the risk score to prioritize improvements. - Export results for compliance and audit documentation. - Repeat the request several times if a temporary 500 error occurs. - Combine DMARC analysis with SPF, DKIM, DNS, and mail-flow review. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX DMARC Policy & Configuration** is a DMARC analysis tool for checking e-mail domain protection. It extracts the DMARC record from `_dmarc.domain`, parses tags such as `v`, `p`, `sp`, `rua`, `ruf`, `pct`, `fo`, `adkim`, and `aspf`, displays policy level, reporting configuration, alignment settings, analysis checks, and risk score. The tool is designed for anti-phishing defense, brand protection, SOC triage, compliance review, domain security auditing, mail provider migration, and DMARC deployment planning. A domain with `p=none` can collect reports, but stronger protection normally requires a phased move to `p=quarantine` or `p=reject` after monitoring legitimate mail sources and confirming SPF / DKIM alignment. # PageRank | Open PageRank Domain Ranking Tool [![image.png](https://wiki.niamonx.io/uploads/images/gallery/2026-06/scaled-1680-/36RNH8mCGMkjfKrn-image.png)](https://wiki.niamonx.io/uploads/images/gallery/2026-06/36RNH8mCGMkjfKrn-image.png) The platform available at **[https://dash.niamonx.io/pagerank](https://dash.niamonx.io/pagerank)** — known as **PageRank** — is a domain ranking and Open PageRank lookup tool within the NiamonX platform. It allows users to check international ranking metrics, PageRank score, ranking position, availability status, and comparative authority signals for one or multiple domains. The tool supports bulk domain input, automatic URL cleanup, quick input presets, sortable result tables, export options, request history, and plan-based query limits. --- ## Overview of the Service **PageRank** is designed to help users evaluate the relative authority and ranking position of domains using Open PageRank-style metrics. It provides a fast way to compare multiple domains and understand which domain has stronger ranking signals. The tool is useful for: - SEO analysis - OSINT research - domain reputation review - competitive analysis - backlink and authority research - marketing research - brand protection - domain portfolio review - threat intelligence enrichment - website credibility checks - investigation reports - content and publishing strategy - technical due diligence Users can paste a list of domains, run a lookup, and receive a sortable overview containing rank, PageRank score, position, and response status for each domain. Example input: ```text cloudflare.com, itstep.org, mirohost.net ``` Example summary: ```text Results for 3 domain(s) Last updated: 28th Mar 2026 · 17.06.2026, 23:07:47 Requested: 3 Resolved: 3 Not found: 0 Max PR: 5.11 Avg PR: 3.77 Top domain: cloudflare.com ``` --- ## 🔍 How the Tool Works The user enters one or more domains into the input field. The tool normalizes the submitted values, removes URL formatting when needed, sends the cleaned domain list for ranking lookup, and displays the results in a table. The tool can process: - comma-separated domains; - line-separated domains; - copied domain lists; - URLs that can be cleaned to domains; - quick input values appended to the main list. Example input: ```text cloudflare.com, itstep.org, mirohost.net ``` Example normalized domains: ```text cloudflare.com itstep.org mirohost.net ``` Example result table: ```text cloudflare.com 5 5.11 3196 200 itstep.org 3 2.82 6758275 200 mirohost.net 3 3.38 2587325 200 ``` The result allows users to compare ranking strength and authority signals across domains. --- ## 🧩 Supported Input PageRank supports domain-based input. Valid examples: ```text cloudflare.com ``` ```text itstep.org ``` ```text mirohost.net ``` ```text github.com, google.com ``` Line-separated input is also supported: ```text cloudflare.com itstep.org mirohost.net ``` URLs may be automatically cleaned to domains. Example submitted URL: ```text https://www.cloudflare.com/products/ ``` Possible normalized domain: ```text cloudflare.com ``` Unsupported or poor input examples: ```text not a domain ``` ```text user@example.com ``` ```text localhost ``` ```text 192.168.1.1 ``` ```text https:// ``` Recommended input format: ```text domain.com ``` or: ```text domain1.com, domain2.org, domain3.net ``` --- ## ⚙️ Main Function: Check Domains The main panel allows users to submit domains for PageRank lookup. Example: ```text Check domains Domains: cloudflare.com, itstep.org, mirohost.net ``` The tool supports up to 50 domains per request. Interface note: ```text Up to 50 domains per request. URLs will be auto-cleaned to domains. ``` This makes the tool suitable for quick comparisons, bulk checks, and domain list analysis. --- ## ⚡ Quick Input The Quick Input field allows users to quickly append domains to the main input. Example: ```text github.com, google.com ``` Interface note: ```text Optional: quickly append domains ``` Quick input is useful when users already have a main list but want to add commonly checked domains or comparison benchmarks without rewriting the entire input. Example workflow: ```text Main input: cloudflare.com, itstep.org, mirohost.net Quick input: github.com, google.com Final checked set: cloudflare.com, itstep.org, mirohost.net, github.com, google.com ``` --- ## 🚦 Plan Limits and Usage PageRank uses plan-based query limits. Example: ```text 1249 / 1250 Queries remaining / total Plan: Sentinel ``` Important points: - Server-side plan limits are enforced. - Each request may consume plan quota. - Bulk requests may count according to platform rules. - Up to 50 domains can be submitted per request. - If plan limits are exceeded, new requests may be blocked. - Previous results may remain visible after a failed request. - Users should monitor remaining queries when running repeated checks. Interface note: ```text Plan limits are enforced server-side. ``` --- ## 📊 Results Summary After a successful lookup, PageRank displays a result summary. Example: ```text Results for 3 domain(s) Last updated: 28th Mar 2026 · 17.06.2026, 23:07:47 Requested: 3 Resolved: 3 Not found: 0 Max PR: 5.11 Avg PR: 3.77 Top domain: cloudflare.com ``` Typical summary fields include:
FieldDescription
Results forNumber of domains included in the displayed result
Last updatedDate of the ranking dataset or source update
RequestedNumber of submitted domains
ResolvedNumber of domains successfully found or processed
Not foundNumber of domains without available ranking data
Max PRHighest PageRank score in the result set
Avg PRAverage PageRank score across resolved domains
Top domainDomain with the highest PageRank score in the submitted set
The summary helps users quickly understand the overall strength of the checked domain group. --- ## 🧾 Results Table The results table displays ranking data for each domain. Example: ```text cloudflare.com 5 5.11 3196 200 itstep.org 3 2.82 6758275 200 mirohost.net 3 3.38 2587325 200 ``` A typical table may include:
ColumnDescription
DomainChecked domain
RankRounded or categorized PageRank value
PageRank ScoreMore precise PageRank score
PositionInternational ranking position
StatusHTTP or API response status
Example interpretation: ```text cloudflare.com Rank: 5 PageRank Score: 5.11 Position: 3196 Status: 200 ``` This means the domain was found, returned successfully, and has the strongest PageRank score among the checked examples. --- ## 🏷️ Domain Column The Domain column shows the normalized domain checked by the tool. Example: ```text cloudflare.com ``` The tool may clean URLs and reduce them to domains before lookup. Example: ```text Input: https://www.cloudflare.com/products/ Normalized: cloudflare.com ``` This helps users paste mixed URL lists without manually cleaning each entry. --- ## 📈 Rank Column The Rank column shows a simplified PageRank value. Example: ```text Rank: 5 ``` This value provides a quick category-like view of domain authority. A higher value generally indicates stronger ranking authority or broader visibility in the ranking dataset. Example comparison: ```text cloudflare.com → Rank 5 itstep.org → Rank 3 mirohost.net → Rank 3 ``` In this example, `cloudflare.com` has a stronger rank than the other two domains. --- ## 📊 PageRank Score The PageRank Score column shows a more precise score. Example: ```text PageRank Score: 5.11 ``` This score allows more detailed comparison than the rounded rank. Example: ```text itstep.org: 2.82 mirohost.net: 3.38 ``` Although both domains may have Rank `3`, the PageRank score shows that `mirohost.net` has a higher score than `itstep.org` in this result set. --- ## 🌍 Position Ranking The Position column shows the domain’s international ranking position. Example: ```text Position: 3196 ``` A lower position number generally indicates a stronger or more prominent domain in the ranking dataset. Example comparison: ```text cloudflare.com → 3196 mirohost.net → 2587325 itstep.org → 6758275 ``` In this example, `cloudflare.com` has a significantly stronger international position. Position rankings are useful for: - competitive comparison; - domain authority review; - SEO research; - domain reputation analysis; - prioritizing investigation targets; - comparing partner or vendor domains; - evaluating digital footprint strength. --- ## ✅ Status Column The Status column shows the response status for each checked domain. Example: ```text Status: 200 ``` A status of `200` usually indicates that the ranking lookup completed successfully for that domain. Possible status meanings may include:
StatusGeneral Meaning
200Successfully resolved or returned
404Domain not found in the ranking dataset
400Invalid or malformed request
429Rate limit or quota issue
500Server-side processing error
Exact status behavior depends on backend implementation and upstream source responses. --- ## 🔃 Sorting Results The table supports sorting by column headers. Interface note: ```text Click column headers to sort ``` Sorting helps users quickly identify: - highest PageRank score; - lowest PageRank score; - best international ranking position; - domains that were not found; - domains with successful or failed status; - strongest domains in a bulk list; - weakest domains in a comparison set. Recommended sorting workflows:
GoalSort By
Find strongest domainPageRank Score descending
Find weakest domainPageRank Score ascending
Find best international rankPosition ascending
Find missing domainsStatus or Not Found
Compare bulk listPageRank Score descending
Identify outliersPosition or PR score
--- ## 📤 Export Options PageRank supports exporting normalized results. Interface note: ```text Export normalized results to CSV/TXT ``` Export options are useful for: - SEO reports; - competitor analysis; - domain portfolio review; - spreadsheet analysis; - client reports; - OSINT case notes; - brand protection documentation; - threat intelligence enrichment; - compliance evidence; - historical comparison. --- ## 📄 CSV Export CSV export is useful when users want to analyze results in spreadsheet tools. Example CSV-style output: ```text Domain,Rank,PageRank Score,Position,Status cloudflare.com,5,5.11,3196,200 itstep.org,3,2.82,6758275,200 mirohost.net,3,3.38,2587325,200 ``` CSV is recommended for: - Excel or Google Sheets; - reporting dashboards; - ranking comparison; - data enrichment; - client deliverables; - domain portfolio analysis. --- ## 📄 TXT Export TXT export is useful for simple lists or plain-text reports. Example TXT-style output: ```text cloudflare.com | Rank: 5 | PR: 5.11 | Position: 3196 | Status: 200 itstep.org | Rank: 3 | PR: 2.82 | Position: 6758275 | Status: 200 mirohost.net | Rank: 3 | PR: 3.38 | Position: 2587325 | Status: 200 ``` TXT export is useful for: - quick notes; - internal documentation; - chat sharing; - case summaries; - Markdown reports; - simple evidence logs. --- ## 🕓 Request History PageRank stores recent requests locally in the browser. Example interface note: ```text Request History Filter... Stores last 100 requests in your browser. ``` Example history entry: ```text cloudflare.com, itstep.org, mirohost.net Count: 3 17.06.2026, 23:07:47 ``` The history helps users: - repeat previous checks; - review recent domain lists; - compare past requests; - continue research sessions; - filter old lookups; - preserve local workflow context. Because request history is stored in the browser, it may be deleted when browser data is cleared or when the user changes devices, profiles, or private browsing sessions. On shared or untrusted devices, users should clear history after checking sensitive domain lists, client portfolios, investigation targets, or confidential research sets. --- ## 🧠 Understanding PageRank Metrics PageRank-style metrics are designed to estimate the relative importance, authority, or ranking strength of a domain. A higher PageRank score may indicate that the domain has stronger web visibility, authority signals, or link-based importance in the ranking dataset. However, PageRank should be interpreted carefully. Important notes: - PageRank is not the same as traffic. - PageRank is not a guarantee of trustworthiness. - A high score does not mean a domain is safe. - A low score does not automatically mean a domain is malicious. - Ranking data may be updated periodically. - Some domains may not be found in the dataset. - Scores should be compared within context. - Domain authority can change over time. - Different ranking providers may produce different values. PageRank is best used as one signal among many. --- ## 🔎 Common Use Cases ### SEO Research Compare domain authority signals across competitors, partners, publishers, or content targets. ### Competitive Analysis Check which domains in a group have stronger ranking positions and higher PageRank scores. ### OSINT Research Enrich domain investigations with authority and ranking context. ### Domain Reputation Review Evaluate whether a domain appears to have established web presence or limited visibility. ### Brand Protection Compare suspicious domains, impersonation domains, or lookalike domains against legitimate brand domains. ### Threat Intelligence Enrichment Add ranking context to domains found in phishing kits, malware infrastructure, spam campaigns, or suspicious web activity. ### Partner and Vendor Review Check public ranking strength of vendor, partner, or customer-facing domains. ### Domain Portfolio Analysis Compare multiple owned domains to identify stronger and weaker assets. ### Content Outreach Evaluate domains before outreach, publication, partnership, or backlink analysis. ### Investigation Prioritization Use PageRank and position data to prioritize domains that may have broader reach or visibility. --- ## 🧪 Example Analysis Example checked domains: ```text cloudflare.com, itstep.org, mirohost.net ``` Example results: ```text cloudflare.com Rank: 5 PR: 5.11 Position: 3196 Status: 200 itstep.org Rank: 3 PR: 2.82 Position: 6758275 Status: 200 mirohost.net Rank: 3 PR: 3.38 Position: 2587325 Status: 200 ``` Example interpretation: ```text cloudflare.com has the strongest PageRank score and best international position in this set. mirohost.net has a higher PageRank score and better position than itstep.org, even though both have the same rounded rank value. All three domains were resolved successfully with status 200. ``` --- ## 🧠 Recommended Workflow A practical PageRank workflow should follow these steps. ### 1. Prepare a Domain List Collect domains that need to be compared. Example: ```text cloudflare.com itstep.org mirohost.net ``` The list may be comma-separated or line-separated. --- ### 2. Paste Domains Into the Tool Use the Domains field. Example: ```text cloudflare.com, itstep.org, mirohost.net ``` Do not worry if some values are full URLs. The tool can auto-clean URLs to domains. --- ### 3. Add Quick Input if Needed Use Quick Input for optional additional domains. Example: ```text github.com, google.com ``` --- ### 4. Run Open PageRank Start the lookup. Example: ```text Open PageRank ``` The tool will process the normalized domains and return ranking data. --- ### 5. Review the Summary Check the overall result metrics. Example: ```text Requested: 3 Resolved: 3 Not found: 0 Max PR: 5.11 Avg PR: 3.77 Top domain: cloudflare.com ``` --- ### 6. Sort the Table Click column headers to sort by PageRank score, position, status, or domain. Recommended first sort: ```text PageRank Score descending ``` This quickly shows the strongest domains in the list. --- ### 7. Review Not Found Results If any domains are not found, validate that the input is correct. Possible reasons: - typo in domain; - newly created domain; - low-visibility domain; - domain missing from dataset; - invalid input; - unsupported domain format. --- ### 8. Export Results Export normalized data to CSV or TXT for reporting. Recommended exports: ```text CSV for spreadsheet analysis TXT for quick documentation ``` --- ### 9. Compare With Other Signals Use PageRank as one signal and enrich with additional checks. Recommended follow-up analysis: - DNS records; - WHOIS / RDAP; - SSL / TLS certificate data; - HTTP status; - website screenshot; - malware or phishing reputation; - backlink profile; - traffic estimates; - content quality; - domain age; - passive DNS; - threat intelligence feeds. --- ## 📊 Interpreting Results Correctly PageRank results should be interpreted as comparative ranking intelligence, not as a final verdict. Important interpretation notes: - Higher PageRank suggests stronger authority signals. - Lower position number usually means stronger global ranking. - A domain with a high PageRank can still be compromised. - A domain with a low PageRank can still be legitimate. - Newly registered domains may have no ranking data. - Parked or inactive domains may be ranked inconsistently. - Domains behind redirects may still normalize correctly. - URL cleanup may remove paths and focus only on the domain. - Ranking data may reflect the last dataset update date. - Scores may change between updates. - PageRank is not a security rating by itself. - Use additional technical checks before drawing conclusions. Example: ```text A high PageRank score can indicate domain authority, but it does not prove that the current website content is safe or trustworthy. ``` --- ## 🚨 Security Review Checklist When using PageRank in security or OSINT workflows, review the following areas. ### High-Ranking Suspicious Domains A suspicious domain with a high PageRank may deserve priority review because it may have broader visibility or inherited authority. Check: - current website content; - redirects; - ownership; - DNS records; - certificate history; - passive DNS; - compromise indicators; - malware reputation. --- ### Low-Ranking Lookalike Domains A low-ranking domain that resembles a brand may still be dangerous. Check for: - typosquatting; - phishing pages; - fake login portals; - brand impersonation; - malicious redirects; - recently registered infrastructure. --- ### Not Found Domains Domains not found in ranking data may be: - newly registered; - low visibility; - inactive; - typo domains; - internal-only names; - suspicious disposable domains. Not found does not mean safe. --- ### Large Domain Lists For bulk lists, sort by PageRank score and position to prioritize review. Recommended triage: ```text 1. High PageRank + suspicious context 2. Low PageRank + brand similarity 3. Not found + recent registration 4. Unexpected domains in known infrastructure ``` --- ## 📈 Recommended Reporting Format When documenting PageRank checks, use a consistent format. Example: ```text Checked domains: cloudflare.com, itstep.org, mirohost.net Check time: 17.06.2026, 23:07:47 Dataset last updated: 28th Mar 2026 Summary: Requested: 3 Resolved: 3 Not found: 0 Max PR: 5.11 Avg PR: 3.77 Top domain: cloudflare.com Results: 1. cloudflare.com | Rank: 5 | PR: 5.11 | Position: 3196 | Status: 200 2. mirohost.net | Rank: 3 | PR: 3.38 | Position: 2587325 | Status: 200 3. itstep.org | Rank: 3 | PR: 2.82 | Position: 6758275 | Status: 200 ``` Example analyst note: ```text Observation: cloudflare.com has the highest PageRank score and strongest international ranking position in the checked set. mirohost.net ranks higher than itstep.org based on both PageRank score and position. All submitted domains were successfully resolved. ``` --- ## 🛡️ Security, Privacy & Responsible Use PageRank is intended for lawful domain analysis, SEO research, OSINT, reputation review, brand protection, compliance, and defensive cybersecurity workflows. Acceptable use cases include: - checking your own domains; - comparing competitor domains; - reviewing domain reputation signals; - enriching investigation reports; - analyzing suspicious domains; - reviewing domain portfolios; - supporting brand protection; - performing authorized OSINT research; - preparing SEO or marketing analysis; - documenting domain authority context. Users should follow responsible use principles: - Do not treat PageRank as proof of safety. - Do not treat low ranking as proof of maliciousness. - Do not use ranking data alone for attribution. - Validate security conclusions with technical evidence. - Respect authorization boundaries when investigating third-party domains. - Store exported domain lists securely when they involve customers or investigations. - Use ranking data as one supporting signal, not as a final decision. --- ## ⚙️ Technical Highlights - Open PageRank domain ranking tool - Available at `dash.niamonx.io/pagerank` - Checks international rank and PageRank score - Supports bulk domain input - Accepts comma-separated values - Accepts line-separated values - Supports up to 50 domains per request - Automatically cleans URLs to domains - Includes Quick Input for appending domains - Shows result dataset update date - Displays requested domain count - Displays resolved domain count - Displays not found count - Calculates maximum PageRank score - Calculates average PageRank score - Identifies top domain - Displays domain rank - Displays precise PageRank score - Displays international position - Displays status code - Supports sortable columns - Supports CSV export - Supports TXT export - Stores local request history - Keeps last 100 requests in the browser - Supports history filtering - Uses server-side plan limits - Suitable for SEO, OSINT, domain reputation review, brand protection, competitive analysis, and threat intelligence enrichment --- ## 📌 Usage Hints - Paste domains separated by commas or new lines. - You can submit up to 50 domains per request. - URLs are automatically cleaned to domains. - Use Quick Input to append common comparison domains. - Sort by PageRank score to find the strongest domains. - Sort by position to compare international ranking. - Check Not Found results for typos or low-visibility domains. - Export CSV for spreadsheet analysis. - Export TXT for quick notes or reports. - Use request history to repeat previous checks. - Monitor remaining plan queries. - Remember that plan limits are enforced server-side. - Treat PageRank as one signal, not a complete reputation score. - Combine results with WHOIS, DNS, TLS, HTTP, screenshot, and threat intelligence checks. - Clear local history on shared devices when checking sensitive domain lists. --- ## 📬 Contact Information For technical, legal, abuse, privacy, or support-related inquiries, users can contact the NiamonX team directly: **** — Technical Support **** — General Inquiries **** — Privacy or Data Removal Requests **** — Legal and Compliance Matters Alternative contact channel: 🔗 Helpdesk: [https://support.niamonx.io/](https://support.niamonx.io/) --- ## Summary **NiamonX PageRank** is an Open PageRank domain ranking tool for checking PageRank score, domain rank, international position, response status, and comparative authority metrics. It supports bulk input, automatic URL cleanup, quick input, sortable results, CSV/TXT export, local request history, and server-side plan limits. The tool is designed for SEO research, OSINT analysis, competitive comparison, domain reputation review, brand protection, threat intelligence enrichment, domain portfolio analysis, and reporting workflows. PageRank results should be treated as ranking and authority signals, not as final security or trust decisions, and should be combined with DNS, WHOIS, TLS, HTTP, screenshot, backlink, traffic, and threat intelligence data for deeper analysis.