# 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.