dns.sb No paid content found

DNS (Domain Name System) is the internet's naming layer: it translates human-readable domain names like google.com into the IP addresses machines use to route traffic, such as 188.114.96.3 (IPv4) or 2a06:98c1:3120::3 (IPv6). You rely on it every time you open a site, send email, or connect an app to a server. Understanding it also matters if you do troubleshooting or online investigation, because DNS records and lookup tools expose who hosts a domain, where its mail goes, and how it relates to other infrastructure.

The core problem DNS solves

Computers route packets by numeric address, not by name. Humans remember names. DNS is the distributed database that maps one to the other, and it does so at internet scale without a single central server holding every record.

How a DNS lookup works

When you type a domain into a browser, resolution typically follows this path:

1. Local cache / hosts file — The browser and operating system first check whether they already know the answer from a recent lookup.
2. Recursive resolver — If not cached, your device asks a resolver (often run by your ISP or a public provider). The resolver does the legwork on your behalf.
3. Root servers — The resolver asks a root server, which points it toward the correct top-level domain (TLD), such as .com.
4. TLD servers — The TLD server points to the authoritative name servers for that specific domain.
5. Authoritative name servers — These hold the domain's actual records and return the answer.
6. Response and caching — The resolver returns the IP to your browser and caches it for a period set by the record's TTL (time to live), so future lookups are faster.

Each step is a query-and-referral chain. The resolver does the recursion; the authoritative servers give final answers.

Common DNS record types

These records are the raw material for both troubleshooting and investigation.

Why DNS matters for troubleshooting and investigation

Because DNS records are public and queryable, they reveal relationships between domains, IPs, and providers. Tools built for this purpose let you:

• Run DNS lookups to confirm what a domain currently resolves to.
• Reverse IP to see which other domains share an IP address — useful for spotting shared hosting or linked infrastructure.
• Reverse NS / Reverse MX to find domains using the same name servers or mail servers.
• WHOIS lookups to check registration details.
• Review historical data to see how records changed over time.

This is the approach behind platforms like DNSlytics, which describes itself as an online investigation tool for finding information about domains, IP addresses, and providers, and for discovering relations and historical data between them. It reports coverage of 330+ million active domains, 60+ million mail servers, 7+ million name servers, and 1+ billion PTR records, with IP/DNS data refreshed every 14 days and 10+ years of historical data. Those figures indicate the scale at which DNS data supports fraud prevention, brand protection, and digital investigation.

Practical implications: caching, propagation, and security

• Caching and TTL — Resolvers and devices cache answers. A record change won't be seen everywhere until caches expire, which is why updates appear to "propagate" gradually rather than instantly.
• Propagation delays — The TTL value controls how long stale answers persist. Short TTLs mean faster updates but more queries.
• DNS security basics — Because DNS is central to connectivity, it is also a target. Be aware that DNS responses can be spoofed or intercepted, and that TXT records often carry email authentication policy (such as SPF) that affects whether mail is trusted.

When to use a DNS investigation tool

Reach for DNS lookups and related tools when you need to:

• Verify where a domain actually points before trusting it.
• Trace shared infrastructure between suspicious domains.
• Check mail routing and email policy records.
• Compare current records against historical ones to spot changes.

For routine browsing, DNS works invisibly. For troubleshooting and investigation, its records are the evidence — and tools that aggregate lookups, reverse queries, and history turn that evidence into something you can act on.

DNS over HTTPS (DoH) sends DNS queries inside encrypted HTTPS traffic instead of plaintext DNS, so your resolver requests can't be easily read or altered in transit. You use it by enabling DoH in a browser or OS, or by pointing a device at a DoH endpoint from a resolver that supports it. The main conditions: your browser/OS must support DoH, and you must trust the resolver you choose, since that resolver still sees your queries.

How DoH works

Normally, when you type a domain, your device sends a DNS query to a resolver to get the IP address. Standard DNS is unencrypted, so anyone on the path (your network, ISP, or a Wi-Fi operator) can observe or tamper with it.

DoH changes the transport:

• The DNS query and answer are wrapped in HTTPS (the same protocol used for secure websites).
• To the network, the traffic looks like ordinary HTTPS to a web server.
• This prevents eavesdropping and manipulation of DNS data via man-in-the-middle attacks, which is the core privacy and security benefit.

DNS.SB describes DoH as "performing remote DNS resolution via the encrypted HTTPS protocol," and offers it alongside DNS over TLS (DoT), which encrypts and wraps DNS queries and answers via the TLS protocol. Both encrypt DNS; the difference is mainly the transport and how the network sees it.

DoH vs plain DNS vs DoT

If you want DNS traffic that's hard to distinguish from regular browsing, DoH is usually the better fit. If you want a clearly separated encrypted DNS channel, DoT may suit you.

Why it matters for privacy

• No plaintext exposure: Your queries aren't readable by intermediaries on the network path.
• Tamper resistance: Encrypted transport makes it harder for an attacker to redirect you by altering DNS answers.
• Resolver trust still matters: Encryption protects the path, but the resolver you use still handles your queries. DNS.SB states it is designed to protect personal DNS data with "no logs, forever," and says it has taken technical steps so it can't know what you do online. Treat that as the resolver's stated policy when deciding whether to trust it.

How to enable DoH

In a browser

1. Open the browser's settings and find the DNS or "Secure DNS" section (wording varies by browser).
2. Turn on secure DNS / DoH.
3. Either choose a provider from the list or enter a custom DoH URL from a resolver that supports DoH.
4. Save, then verify by visiting a DNS leak test page or the resolver's own check page.

Expected result: your browser resolves names over HTTPS. If pages still load but the leak test shows your old resolver, the setting didn't take effect.

On a device or OS

1. Find the network/DNS settings for your OS or device.
2. Switch DNS from automatic/manual plain DNS to an encrypted option (DoH or DoT) if supported.
3. Enter the resolver's DoH endpoint.
4. Reconnect the network and test resolution.

Expected result: system-wide DNS goes through the encrypted endpoint. If the OS only supports DoT, use that instead—both encrypt DNS.

Pointing at a resolver

Use a resolver that publishes DoH support. DNS.SB is one option: it offers DoH and DoT, runs on xTom's global anycast network across 30 locations on 6 continents, and publishes easy-to-remember addresses (for example IPv4 185.222.222.222 and 45.11.45.11, and IPv6 2a09:: and 2a11::). Check the resolver's site for its exact DoH URL before entering it.

Trade-offs to weigh

• Latency: DoH adds encryption overhead. A fast resolver on a nearby anycast network can offset this, but a distant or overloaded resolver can slow browsing.
• Resolver trust: You're shifting who sees your queries from your network/ISP to the resolver. Choose one whose logging policy you accept.
• Network compatibility: Some networks, captive portals, or parental-control systems rely on inspecting or blocking plain DNS. DoH can bypass or break those, and some networks block DoH outright.
• Enterprise/managed devices: If your organization enforces DNS, enabling DoH may conflict with policy.

Troubleshooting when DoH fails or slows down

• Nothing resolves: Temporarily switch back to automatic/plain DNS to confirm DoH is the cause, then re-check the endpoint URL.
• Slow browsing: Try a different resolver or a closer anycast location; compare load times with DoH off.
• Works in browser but not system-wide: The browser setting and OS setting are separate—enable both if you want full coverage.
• Blocked on a network: Some networks block DoH on port 443. Fall back to DoT or plain DNS there.
• Captive portal won't load: Disable DoH until you've signed in, then re-enable it.

Start by enabling DoH in your browser with a resolver you trust, verify with a leak test, then extend it to your OS if you want system-wide encryption.

DNS over TLS (DoT) encrypts your DNS queries by wrapping them in the TLS protocol, typically on port 853, so that anyone between your device and the resolver cannot read or tamper with the names you look up. You enable it by pointing your device or router at a DoT-capable resolver, such as DNS.SB, and turning on the encrypted-DNS setting for your platform. DoT is the better fit when you want a dedicated, always-encrypted DNS channel and your network allows port 853; DoH is the better fit when you need DNS to blend into normal HTTPS traffic on port 443.

How DoT works

A normal DNS query travels in plaintext, usually over UDP port 53. Anyone on the path — your ISP, a Wi-Fi operator, or an attacker on the same network — can see which domains you request and can alter the answers.

DoT changes that in three ways:

• Encryption: the DNS query and response are carried inside a TLS session, the same protocol that protects HTTPS.
• Dedicated port: DoT uses TCP port 853, so it is a separate, clearly identified encrypted channel rather than a tunnel hidden inside web traffic.
• Authentication: the TLS handshake verifies the resolver's certificate, which makes man-in-the-middle manipulation of DNS answers much harder.

DNS.SB describes its service as encrypting DNS queries and answers via the TLS protocol, with the stated goal of preventing eavesdropping and manipulation of DNS data through man-in-the-middle attacks. It also states that it keeps no logs.

DoT vs DoH: which should you pick?

Both encrypt DNS. The practical difference is the port and how the traffic looks on the network.

Choose DoT when your platform exposes a native "Private DNS" or encrypted-DNS setting and port 853 is reachable. Choose DoH when DoT fails because the network blocks port 853, or when you specifically want DNS to be indistinguishable from other HTTPS traffic.

How to enable DoT

The exact menu names vary by vendor and OS version, so treat the steps below as the pattern rather than a fixed map. The input is always the same: a DoT hostname from a resolver that supports it.

Android (Private DNS)

1. Open Settings → Network & internet → Private DNS (on some versions it is under Connections).
2. Select Private DNS provider hostname.
3. Enter the DoT hostname of your resolver, for example dns.sb.
4. Save. Android will now resolve names over DoT and will show a warning if it cannot connect.

Expected result: DNS queries leave the device encrypted on port 853. If the hostname is wrong or port 853 is blocked, Android falls back to the network's plain DNS and may display a "couldn't connect" notice.

Windows

Windows does not expose a single built-in DoT toggle in all versions. The common approaches are:

• Use a browser that supports secure DNS, or a resolver client that manages DoT for the system.
• Configure DoT through a supported client or a router that handles DNS for the whole network.

Because availability depends on your Windows build, verify that your chosen method actually reports an encrypted connection before relying on it.

Routers

Many routers let you set an upstream DNS server and, on supported firmware, enable DoT for all devices on the network.

1. Open the router admin page and find the DNS or encrypted-DNS section.
2. Enable DNS over TLS if the firmware offers it.
3. Enter the DoT hostname of your resolver.
4. Save and reboot if required.

Expected result: every device behind the router uses encrypted DNS without per-device configuration. This is the most efficient option for a home or small office.

Public DoT resolvers

Use the resolver's official DoT hostname, not a guessed one. DNS.SB publishes its resolver addresses and states that it supports DNS over TLS alongside DNS over HTTPS.

Always confirm the hostname and any required port from the provider's own documentation before entering it, since these details can change.

How to verify DoT is working

Enabling the setting is not proof that encryption is active. Check it:

• Look for a status indicator. Android's Private DNS shows whether the connection succeeded.
• Test for plaintext DNS. Use a DNS leak test that reports whether queries are encrypted.
• Check the port. A working DoT connection uses TCP port 853 to the resolver.
• Compare results. If a domain resolves the same way with DoT on and off, and no error appears, the setting is likely active — but confirm with a leak test rather than assuming.

Troubleshooting common DoT failures

Port 853 is blocked. Many corporate, hotel, and public networks block non-standard ports. If DoT will not connect, switch to DoH on port 443, which is usually allowed.

Silent fallback to plain DNS. Some devices quietly revert to unencrypted DNS when DoT fails, so you keep browsing but lose the protection. Watch for a warning indicator and re-test after changing networks.

Wrong hostname. A typo in the DoT hostname prevents the TLS handshake. Copy the hostname from the provider's documentation.

Certificate errors. If the resolver's certificate cannot be validated, the connection fails by design. Do not disable certificate checking to force it through — that removes the protection DoT is meant to provide.

Router firmware lacks DoT. If your router has no encrypted-DNS option, configure DoT per device, or use a router that supports it.

FAQ

Does DoT hide which sites I visit? It hides your DNS queries from anyone between you and the resolver. It does not hide the destinations you actually connect to, and the resolver itself can still see your queries unless it commits to not logging them. DNS.SB states that it keeps no logs.

Is DoT faster than plain DNS? Not inherently. Speed depends on the resolver's network. DNS.SB says it runs on a global anycast network across 30 locations on 6 continents, which is the kind of infrastructure that reduces lookup latency.

Can I use DoT and DoH at the same time? You can, but there is usually no benefit. Pick one per device or network to keep behavior predictable.

What happens if I enter the wrong DoT hostname? The TLS handshake fails, and the device either reports an error or falls back to plain DNS. Always verify with a leak test after setup.

A DNS resolver is the service that takes the domain name you type (like example.com) and finds the matching IP address so your device can connect. When people talk about "changing your DNS" or "using a private DNS," they usually mean switching the recursive resolver your device queries — not the authoritative nameservers that publish a domain's records. Choosing a resolver comes down to three checkable things: its logging policy, its network speed and coverage, and whether it supports encrypted DNS (DoH or DoT). This article explains the roles, the encryption options, and how to switch and verify.

The three DNS roles people mix up

DNS involves several distinct components. Confusing them leads to the wrong expectations when you "change your DNS."

When you switch to a "private DNS," you are changing the recursive resolver — the one that sees every domain you look up. That's why its logging policy matters: it sits in a position to observe your browsing destinations.

Why encryption (DoH/DoT) changes the privacy picture

Traditional DNS queries travel in plaintext over UDP port 53, which means anyone on the path — your network operator, a Wi-Fi provider, an intermediary — can potentially observe or manipulate them. Encrypted DNS closes that gap.

• DNS over HTTPS (DoH): performs remote DNS resolution inside the encrypted HTTPS protocol. It blends with normal web traffic on port 443.
• DNS over TLS (DoT): wraps DNS queries and answers in the TLS protocol on a dedicated port.

Both prevent eavesdropping and man-in-the-middle manipulation of DNS data. The practical difference is mostly about how the traffic looks on the network and how your device/OS configures it — DoH is often easier to enable in browsers and apps, while DoT is commonly used at the OS or router level.

Encryption protects the query in transit. It does not by itself guarantee the resolver keeps no logs — that's a separate policy question you have to check.

How to compare public resolvers

Use the same dimensions for every candidate so the comparison is fair:

1. Logging policy. Look for an explicit statement about what is retained and for how long. DNS.SB, for example, states it is designed to protect personal DNS data with "no logs, forever" and describes taking technical steps so it cannot know what you do online. Treat any claim as a policy to read, not an assumption.
2. Encrypted DNS support. Confirm the resolver offers DoH and/or DoT, not just plaintext. DNS.SB lists both DoH and DoT.
3. Network speed and coverage. Since almost everything online starts with a DNS request, a faster resolver can speed up the first step of most connections. DNS.SB says it runs on xTom's global anycast network across 30 locations on 6 continents, resolving queries worldwide.
4. Easy-to-remember addresses. Handy if you configure devices manually. DNS.SB publishes short addresses: IPv4 185.222.222.222 and 45.11.45.11, and IPv6 2a09:: and 2a11:: (it describes these as among the shortest IPv6 addresses).

A resolver that scores well on policy but has no nearby presence may still feel slow; one that's fast but vague about logging may not match your privacy goal. Weigh both.

How to switch your device or router

The exact menus differ by OS and firmware, but the inputs and expected result are the same everywhere: you replace the resolver addresses your device uses.

On a single device (computer or phone):

1. Open network settings and find the DNS configuration for the active connection.
2. Replace the existing resolver addresses with your chosen resolver's IPs (for DNS.SB: 185.222.222.222 and 45.11.45.11, or the IPv6 equivalents).
3. Save and reconnect if prompted.
4. Expected result: new lookups go to the new resolver.

On a router (applies to every device on the network):

1. Log into the router admin page.
2. Find the WAN/DHCP DNS settings.
3. Enter the resolver IPs and save.
4. Expected result: devices that use the router's DNS automatically inherit the change.

For encrypted DNS: enable DoH or DoT in the OS, browser, or app that supports it, and enter the resolver's DoH/DoT endpoint. This is separate from setting plain IP addresses — a device can have the right IPs but still send unencrypted queries if encryption isn't turned on.

Troubleshooting after you switch

• Slow lookups. The resolver may be far from you or its anycast routing isn't optimal for your location. Test another resolver or revert and compare.
• DNS leaks. If you enabled encrypted DNS in one app but the OS still uses plaintext elsewhere, some queries can bypass encryption. Check whether encryption is set at the OS or router level, not just in a browser.
• Sites not resolving. A typo in the IP addresses, or a resolver that doesn't answer a particular query, will break lookups. Re-verify the addresses and test with a known-good domain.
• Changes not taking effect. Cached settings or a still-connected old session can mask the switch. Reconnect the network or restart the device.

The short version

A DNS resolver translates names to IPs and, if it's your recursive resolver, sees your lookups. Pick one by reading its logging policy, confirming DoH/DoT support, and checking speed and coverage — then switch at the device or router level and verify that encryption is actually on. DNS.SB is one option that documents no-log intent, DoH and DoT, and a 30-location anycast network; evaluate it against the same criteria you'd apply to any other resolver.

DNSSEC (Domain Name System Security Extensions) is a set of DNS protocol extensions that cryptographically sign DNS data so a resolver can verify that an answer is authentic and unmodified. It protects integrity and authenticity, not confidentiality: queries and answers still travel in cleartext unless a separate protocol such as DoT or DoH encrypts the transport. You need DNSSEC if you want to prevent forged or tampered DNS answers from being accepted; you do not need it to hide which names are being queried.

What DNSSEC actually guarantees

A validating resolver checks two things about a signed answer:

• Authenticity — the answer came from the zone that is authoritative for the name.
• Integrity — the answer was not altered in transit or in a cache.

It does not provide:

• Encryption of queries or responses.
• Hiding of domain names (the query name is still visible on the wire).
• Protection against a compromised authoritative server that signs bad data with its own valid key.

The chain of trust

DNSSEC works as a hierarchy of signatures anchored at the DNS root.

1. The root zone is signed, and its public key (the trust anchor) is distributed with validating software.
2. Each signed child zone publishes a DS record in its parent, which commits to the child's key.
3. The child zone publishes its public key as a DNSKEY and signs its records with the matching private key.
4. A validator walks from the root down, verifying each DS/DNSKEY link, until it can validate the answer for the name it was asked about.

If any link is missing or invalid, the validator treats the data as bogus and returns a failure (typically SERVFAIL) rather than accepting it.

Signing vs. validation: two separate jobs

DNSSEC requires action on both sides, and they are independent.

A zone can be signed without your resolver validating, and a resolver can validate without the zones you query being signed. For end-to-end protection, both must be in place.

Common failure modes

• Expired signatures — RRSIG records have validity windows; if re-signing fails, validating resolvers reject the zone.
• Broken delegation — a DS record at the parent that does not match the child's DNSKEY makes the whole subtree bogus.
• Missing DS — a signed child with no DS at the parent is treated as unsigned, so validation silently does not apply.
• Clock skew — validators with wrong time may reject valid signatures.
• Algorithm mismatch — parent DS and child DNSKEY must use compatible algorithms.

Diagnosis usually starts by querying with a validating resolver and checking whether the response is secure, insecure, or bogus, then inspecting DS, DNSKEY, and RRSIG records along the delegation path.

Tooling and implementations

DNSSEC is implemented across many open-source and commercial systems. NLnet Labs, a nonprofit foundation focused on DNS and routing, maintains several relevant components:

• Cascade — described as a purpose-built DNSSEC signing solution.
• NSD — a fast, robust authoritative DNS nameserver.
• Unbound — a lean, versatile recursive DNS resolver (validation happens on the resolver side).
• Krill — RPKI Certificate Authority software (routing security, not DNSSEC).
• Routinator — RPKI Relying Party software.

For a zone owner, the practical path is: choose a signer (such as Cascade or another DNSSEC-capable authoritative server), publish the DS record at your registrar or parent zone, and confirm that a public validating resolver returns validated answers. For a resolver operator, enable validation in software such as Unbound and verify the root trust anchor is current.

Deciding whether to enable it

Enable DNSSEC if you want to reduce the risk of cache poisoning and forged answers reaching your users, and you can commit to key management and timely re-signing. Skip it only if you have a specific reason — for example, an internal-only zone where validation is not enforced end to end — and understand that unsigned zones gain no integrity protection.