DNS & Port Lookup Helper

Diagnose network ports and DNS records instantly in your browser. Look up standard port assignments, evaluate security exposure risks, validate DNS record syntax (including SPF and DMARC), and generate ready-to-run terminal commands for dig, PowerShell, and netcat. Zero data leaves your machine.

# Enter a port or hostname above to generate ready-to-run terminal commands.

Understanding Network Ports and the DNS Architecture

Every network service connecting to the internet relies on two foundational pillars: the Domain Name System (DNS) to resolve human-memorable names into IP addresses, and transport-layer port numbers to direct incoming packets to the exact operating system process listening on that machine. Whether loading a web page, routing a high-volume transactional email, or connecting to a PostgreSQL cluster, mastering port security and DNS record hygiene is essential for maintaining application availability, compliance, and cyber resilience.

Operating systems reserve a 16-bit unsigned integer space for TCP and UDP communication, yielding 65,535 possible ports. These are partitioned into three globally recognized IANA tiers:

• Well-Known System Ports (1–1023): Reserved for foundational internet infrastructure, including HTTP (80), HTTPS (443), SSH (22), DNS (53), and SMTP (25). On Unix and Linux servers, binding to these low numbers strictly requires root privileges or the CAP_NET_BIND_SERVICE capability.
• Registered User Ports (1024–49151): Designated by IANA for specific vendor applications, relational databases, and enterprise services such as MySQL (3306), PostgreSQL (5432), Redis (6379), MongoDB (27017), and Microsoft Remote Desktop (3389).
• Dynamic, Private, or Ephemeral Ports (49152–65535): Allocated temporarily by client operating systems as outgoing source sockets when making requests to remote servers. They should never have static inbound listeners facing the open web.

Why Database and Remote Admin Ports Must Never Face the Public Internet

One of the most dangerous and persistent security mistakes in cloud infrastructure is opening internal database ports or unauthenticated services directly to the public internet (listening on 0.0.0.0 rather than 127.0.0.1 or a private VPC subnet). Global internet scanners and automated criminal botnets probe every IPv4 address continuously, testing default credentials and remote code execution vulnerabilities.

The Complete DNS Record Cheat Sheet

While ports control where packets flow inside an operating system, the Domain Name System directs clients to the authoritative network locations of those services. Misconfiguring DNS records leads to broken websites, dead email routing, and vulnerability to subdomain hijacking.

1. Address Records: A and AAAA

An A record maps a domain or subdomain to a 32-bit IPv4 address (e.g., 93.184.216.34), defined in RFC 1035. An AAAA record (RFC 3596) maps a hostname to a 128-bit IPv6 address (e.g., 2606:2800:220:1:248:1893:25c8:1946). In modern dual-stack environments, both should be published simultaneously to ensure seamless routing for IPv6-only mobile carriers.

2. Canonical Name Records: CNAME

A CNAME record aliases one hostname to another canonical domain name (e.g., pointing www.example.com to example.com). According to RFC 1912 and RFC 2181, a CNAME record cannot coexist with any other record of the same name. Crucially, this means you cannot place a CNAME record at your root or zone apex (e.g., example.com), because the apex already contains required SOA and NS records. Modern DNS hosting providers solve this via proprietary ALIAS or ANAME record flattening.

3. Mail Exchanger Records: MX

An MX record designates the Mail Transfer Agent (MTA) servers responsible for receiving email sent to your domain name (RFC 5321). MX records feature an integer priority number (precedence) alongside the destination hostname. The lower the priority integer, the higher the precedence. For example, an MX record with priority 10 will receive all mail traffic first, falling back to priority 20 only if the primary mail host is unreachable. Under RFC 2181, an MX record must always point to an A or AAAA hostname—never to an IP address directly, and never to a CNAME alias.

4. Reverse Pointer Records: PTR

A PTR record maps an IP address back to a canonical hostname, the exact inverse of an A record. Reverse DNS operates under the special top-level domains .in-addr.arpa (for IPv4) and .ip6.arpa (for IPv6). Major mailbox providers like Google Gmail, Yahoo, and Microsoft Outlook immediately reject incoming email if the sending server's IP address lacks a valid PTR record matching its Forward-Confirmed Reverse DNS (FCrDNS) hostname.

5. Certification Authority Authorization: CAA

A CAA record (RFC 8659) gives domain owners cryptographic control over which Certificate Authorities are allowed to generate SSL/TLS certificates for their hostnames. If an unauthorized party attempts to trick a rogue CA into issuing a certificate for your domain, compliant CAs must check CAA records and deny issuance. A typical CAA policy restricts issuance to Let's Encrypt and Cloudflare while routing violation alerts to a security email inbox:

example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild "letsencrypt.org"
example.com. IN CAA 0 iodef "mailto:[email protected]"

The Email Authentication Trinity: SPF, DKIM, and DMARC

Because the original Simple Mail Transfer Protocol (RFC 821) was created without built-in sender verification, spoofing the "From:" header in an email was historically trivial. To protect deliverability and defeat phishing, modern domains require three interconnected DNS records:

1. Sender Policy Framework (SPF, RFC 7208): Published as a TXT record at your domain apex (v=spf1 ...). It enumerates authorized sending IPs and third-party services (such as Google Workspace, Microsoft 365, or SendGrid). Critically, RFC 7208 imposes a strict 10 DNS lookup limit for mechanisms like include:, a, mx, and redirect=. If your SPF record requires more than 10 DNS queries to resolve, receiving mail servers trigger a PermError and may mark your legitimate emails as spam. Always conclude with ~all (SoftFail) or -all (HardFail); never use +all, which allows anyone to send mail as your domain.
2. DomainKeys Identified Mail (DKIM, RFC 6376): Uses asymmetric public-key cryptography to digitally sign outbound email messages. The public key is stored in a DNS TXT record under a designated selector (e.g., google._domainkey.example.com). Receiving servers verify that the email's cryptographic signature matches the public key, proving the email body and headers were not tampered with in transit.
3. Domain-based Message Authentication, Reporting, and Conformance (DMARC, RFC 7489): Published at _dmarc.yourdomain.com. DMARC tells recipient mailboxes what to do when an incoming message fails SPF or DKIM checks. Policies include p=none (monitoring only, collect reports), p=quarantine (route failing emails to spam), and p=reject (outright drop spoofed emails). Deploying DMARC with an aggregate reporting address (rua=mailto:[email protected]) gives you complete visibility over who is sending email using your brand.

Diagnostic CLI Terminal Cheat Sheet

When diagnosing DNS resolution latency or port reachability issues, command-line utilities provide raw, authoritative data without browser proxy interference:

Frequently Asked Questions

Why does my ISP block outbound port 25?

Simple Mail Transfer Protocol (SMTP) on port 25 was designed for unauthenticated server-to-server mail relays. In the early 2000s, malware-infected residential computers were routinely commandeered by botnets to blast billions of spam messages. To protect internet email infrastructure, nearly all residential and cloud service providers (including AWS EC2, DigitalOcean, and Comcast) block outbound TCP port 25 by default. Legitimate email client software should submit outbound email via port 587 (with mandatory STARTTLS authentication) or port 465 (implicit TLS), which are not blocked.

What is the difference between email port 465 and port 587?

Port 587 is the standard submission port defined in RFC 6409. It initiates an unencrypted TCP handshake and immediately upgrades the connection to encrypted TLS via the STARTTLS command before authentication credentials are exchanged. Port 465, formalized in RFC 8314, uses "Implicit TLS" where the TLS handshake happens immediately upon connection, before any SMTP commands are transmitted. RFC 8314 now recommends port 465 with implicit TLS as the modern industry best practice because it eliminates opportunistic STARTTLS stripping attacks.

Can I host a secure HTTPS website on a non-standard port?

Yes. Any TCP port between 1 and 65535 can serve TLS-encrypted HTTPS web traffic. For instance, port 8443 is frequently used for staging APIs, secondary web services, or administration consoles (e.g., https://example.com:8443/). However, standard web browsers assume port 443 by default; if you run on an alternate port, users and API clients must explicitly append the port number to the URL.

What happens if an SPF record exceeds the 10 DNS lookup limit?

RFC 7208 specifies that evaluating an SPF record must not require more than 10 DNS lookups across all include:, a, mx, ptr, exists:, and redirect= mechanisms. If your record requires an 11th query, recipient mail transfer agents stop processing immediately and return an SPF PermError (Permanent Error). Major providers like Google Workspace and Microsoft 365 treat PermErrors as an authentication failure, frequently rerouting your business communications directly into spam folders. To fix this, domain owners use "SPF flattening" tools that pre-resolve third-party domains into static ip4: and ip6: CIDR blocks.

Why cannot this browser tool probe open ports directly across the web?

Web browsers operate within a strict client-side security sandbox designed to prevent malicious websites from port-scanning your local home router, intranet devices, or third-party servers. Web browsers cannot emit raw TCP SYN packets or listen on raw UDP sockets. This tool provides offline RFC parsing, risk scoring, vulnerability explanations, and pre-formatted terminal commands (such as nc, dig, and Test-NetConnection) that you can execute safely in your native command shell.

How long does DNS propagation actually take?

DNS propagation is not an arbitrary internet delay; it is governed strictly by the Time-To-Live (TTL) integer configured on your DNS records. The TTL tells recursive resolvers how many seconds they are permitted to cache a record before querying authoritative name servers again. If your record has a TTL of 300 seconds (5 minutes), changes propagate globally within 5 minutes. If your TTL is set to 86400 seconds (24 hours), caching resolvers around the world will continue serving the old IP address until that 24-hour window expires. When preparing for server migrations, always reduce your TTL values days in advance.