How Codynet Works

The short version

Codynet talks to each network protocol directly and hands back the raw, structured answer. There is no account, no tracking cookie, and the domains and addresses you look up are subject to limited, disclosed operational analytics. This page explains, tool by tool, where each answer comes from and exactly what is and is not stored. You can jump straight to all tools, or read on for the details.

DNS, DIG, MX, TXT, PTR, and resolver compare

When you run a DNS lookup, Codynet sends a live query to a public recursive resolver you choose — Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9 (9.9.9.9), or OpenDNS — and shows you exactly what came back: the records, their TTLs, and the response status (including NOERROR, NXDOMAIN, and SERVFAIL). The supported record types are A, AAAA, CNAME, MX, NS, SOA, TXT, and CAA, with focused views for MX records and TXT records.

The DIG view shows the same query at the protocol level — header flags and the question, answer, authority, and additional sections, with a TTL on every record. Reverse DNS (PTR) maps an IP address back to a name, and nslookup gives a quick status-and-answer view. Multi-resolver compare runs one query against all four resolvers at once, so you can watch a change propagate or catch a resolver still serving a stale answer.

RDAP — domain and IP registration

For registration data, Codynet uses RDAP, the modern JSON replacement for legacy WHOIS. Whether you look up a domain's registration or an IP address's registration, it first consults the IANA bootstrap registry to find the authoritative RDAP endpoint for that TLD or IP block, then queries that registry or Regional Internet Registry directly. You get structured registration data — registrar, statuses, key dates, and nameservers — instead of a scraped free-text WHOIS blob.

TLS certificate inspection

The TLS checker opens a live TLS connection to the host and port you specify and reads the certificate chain the server actually presents. It reports each certificate's role (leaf or intermediate), issuer, validity dates, days until expiry, and the Subject Alternative Names — so you can confirm what a real client would see, including a missing intermediate or an already-expired leaf.

HTTP security headers

The HTTP header checker sends a request to the URL you enter, follows redirects, and reports the response status and headers only — never the page body. It surfaces the security-relevant headers (such as HSTS, Content-Security-Policy, and X-Content-Type-Options) so you can review a site's header posture at a glance.

Subnet calculator and bulk lookups

The subnet/CIDR calculator runs entirely in your browser — it is pure math on the CIDR you enter, with no server request at all. Bulk mode takes up to 200 inputs at once, runs them with a capped number of requests in flight to stay within public-resolver limits, and lets you export the results as CSV. Codynet does not store the batch as a reusable list or retain full result payloads; each validated row may create limited 90-day operational analytics.

How server-side requests are kept safe

Because several tools reach out on your behalf (DNS, RDAP, TLS, HTTP), every server-side request is guarded so it can only target public internet hosts. Requests aimed at private, loopback, or link-local addresses are refused, which keeps the tools from being used to probe internal networks.

What Codynet stores — and what it doesn't

Codynet keeps its operational analytics deliberately narrow:

• Your lookup history is saved only in your browser's local storage, on your device. Clearing it removes that local History drawer. It is separate from server-side operational analytics.
• Analytics are cookie-free and may retain a validated normalized query target, tool and operation, outcome, timing, and anonymous per-tab session ID for 90 days. Server-side query events exclude the client IP and derived geography.
• Full result payloads are not retained in query analytics. HTTP paths, query strings, fragments, credentials, raw User-Agent strings, and malformed input are excluded.

The full privacy policy spells this out in detail.

Limitations worth knowing

A few honest caveats. DNS answers can be cached, so a freshly changed record may take up to its TTL to appear. Different resolvers can legitimately disagree while a change propagates — that is a feature of the compare tool, not a bug. And every live lookup depends on the target servers being reachable, so a transient network failure or an unreachable nameserver shows up as a timeout or SERVFAIL rather than a Codynet error.