标签：#DNS

The SPF redirect trap: why -all can make redirect= useless SPF records often look simple until you start combining mechanisms and modifiers. One particularly easy mistake is to write a record like this: v=spf1 include:_spf.google.com -all redirect=_spf.example.com At first glance, it seems reasonable: authorize Google, reject everything else, and use another SPF policy through redirect= . But the redirect= part will never be used. The reason is an important detail of how SPF evaluation works. redirect= is not a fallback after -all An SPF record is evaluated mechanism by mechanism. For example: v=spf1 ip4:192.0.2.10 include:_spf.google.com -all The receiver checks the mechanisms until one matches. The all mechanism is special because it always matches . That means: -all effectively says: If nothing before this matched, return SPF Fail. Now consider this record again: v=spf1 include:_spf.google.com -all redirect=_spf.example.com Once SPF reaches -all , it already has a result. There is no reason to evaluate redirect= . The redirect modifier is only used when none of the mechanisms in the record produce a match. Because all always matches, a record containing all prevents redirect= from being used. What redirect= is actually for The redirect modifier is useful when several domains should share one central SPF policy. Imagine these domains: example.com example.net example.org Instead of maintaining the same SPF configuration independently on every domain, they can redirect to a central policy. For example: example.com TXT "v=spf1 redirect=_spf.example.com" example.net TXT "v=spf1 redirect=_spf.example.com" example.org TXT "v=spf1 redirect=_spf.example.com" And the central record might contain: _spf.example.com TXT "v=spf1 ip4:192.0.2.10 include:_spf.google.com -all" Now the sending policy can be maintained in one place. This is very different from include: . redirect= vs include: These two are easy to confuse. include: Use include: when you want to authorize senders def

Nobody opens a ticket for an SPF record. There is no alert, no dashboard turning red, no user calling to say that an IP address from a provider the company stopped paying two years ago is still authorized to send email on its behalf. That is exactly what makes it dangerous. I audited the SPF record of a mid-sized manufacturing company in Brazil and found authorized senders that had not been part of the environment for years. Nothing was broken. Email was flowing normally. And that is the point — a bloated SPF record does not fail loudly. It fails quietly, on the day someone decides to use it. The problem The company had migrated its email to Microsoft 365. The migration itself went fine — mailboxes moved, mail flow worked, users were happy, project closed. What nobody revisited was DNS. The SPF record still authorized the IP ranges of the previous email security provider, alongside the current include:spf.protection.outlook.com. Those ranges had been left in place when the provider was decommissioned, and nothing in the environment depended on them anymore. The record said, in effect: these servers are allowed to send email as us. And they were no longer under our control. Two concrete risks come out of that: Spoofing surface. An SPF record is an authorization list. If infrastructure you no longer control is still on it, and that infrastructure is ever repurposed, resold, or compromised, mail from it passes SPF authentication as your domain. Receiving servers will trust it, because you told them to. The 10-lookup limit. SPF allows a maximum of 10 DNS lookups when evaluating a record. Mechanisms like include, a, mx, ptr and redirect each consume from that budget, and nested includes count too. Cross the limit and the evaluation returns permerror — which many receivers treat as a failed check. Legacy entries do not just sit there harmlessly; they consume a budget you may need the next time a business team adopts a new platform. The constraints This is the part that sh

Criminals are hacking into public Wi-Fi devices—at hotels, conference centers, and so on—around the world and changing their DNS settings. The goal is to redirect users to fake login pages and steal their credentials.

You own a domain. Your website lives on it. With Cloudflare's free plan you can make anything@yourdomain.com - any address, invented on the spot - land in your regular Gmail inbox. No Google Workspace subscription, no mail server, no changing registrars. About 30 minutes, $0. What you get: A catch-all : every address at your domain forwards to one inbox. Free disposable addresses: give netflix@yourdomain.com to Netflix and bank@yourdomain.com to your bank. When spam arrives addressed to one of them, you know who leaked your address. Your website, untouched. One limitation: this is receive-only . You can reply as you@yourdomain.com from free Gmail via "Send mail as", but the mail goes out through Google's servers without your domain's blessing, so some recipients see "via gmail.com" and strict spam filters may object. If sending from the domain matters, that's what Google Workspace is for. For receiving, read on. You need: a domain (registered anywhere; it stays there), a free Cloudflare account, and an inbox to receive the mail. Step 1: Add your domain to Cloudflare Log in at dash.cloudflare.com, click Add a domain , pick the Free plan. Cloudflare scans your existing DNS and imports what it finds. Review this list carefully - the scan is good but not guaranteed complete, and whatever it misses stops resolving after the switch. Check what your DNS really says from any terminal: dig +short A yourdomain.com dig +short MX yourdomain.com dig +short NS yourdomain.com If the MX query returns nothing, you have no existing email service and this migration is pure upside. If it returns something, understand what that mail service is before proceeding. Step 2: The gotcha - where does your DNS actually live? That NS query tells you who currently answers DNS for your domain, and it is not always your registrar. In my case the nameservers pointed at NS1 ( *.nsone.net ) - Netlify DNS . My registrar just held the registration; the DNS zone lived in Netlify, from clicking "use Netli

You published a DMARC record months ago. Every checker says it's valid. No reports have ever arrived, and at some point you stopped thinking about it and quietly concluded nobody's forging your domain. You don't know that. You just can't see. Two causes account for almost all of it, and both leave the DMARC record itself looking perfect. 1. Your reporting address never agreed to receive them This is in the spec and almost nobody knows about it. If your rua= address is on a different organisational domain from the domain publishing the record, RFC 7489 section 7.1 requires the destination to explicitly consent. The reason is obvious once you see it: otherwise anyone could point rua= at your mailbox and use the world's mail infrastructure as a free DDoS. Consent is a DNS record, published by the receiving domain: <your-domain>._report._dmarc.<their-domain>. TXT "v=DMARC1" So if example.com sends reports to dmarc@reports.vendor.com , then vendor.com has to publish: example.com._report._dmarc.reports.vendor.com. TXT "v=DMARC1" Without it, conforming reporters send nothing at all. That includes Google, which is most of your report volume. You can watch this working in production. PayPal sends aggregate reports to a third party, and the authorisation record exists: paypal.com._report._dmarc.rua.agari.com. TXT "v=DMARC1;" The practical consequence: not a Gmail address You cannot put a Gmail address in rua= . Google is not going to publish yourdomain.com._report._dmarc.gmail.com on your behalf, and you can't create records in their zone. Same for Outlook, Yahoo, or any address at a domain you don't control. This is a common first move — publish DMARC, point reports at your personal inbox, wait. Nothing arrives, and nothing is wrong with the record. If you use a commercial DMARC service they normally publish these records during onboarding, often via a wildcard. If reports never start after you sign up, check this before anything else. When it doesn't apply: reporting to you

There's a failure mode in SPF that produces no error anywhere you'd think to look. Your record is syntactically valid. dig returns it. Your DNS provider is happy. Your own test mail arrives fine. And yet some of your mail is failing authentication at the receiver, and nothing in your infrastructure will tell you. The cause is usually that you've gone past ten DNS lookups. Ten is a hard ceiling, not a guideline RFC 7208 section 4.6.4 requires evaluators to cap DNS-querying terms at ten. Go past it and the result is PermError — a permanent failure. The important part: receivers don't degrade gracefully. They don't evaluate the first ten and shrug at the rest. They treat the entire record as unusable. You go from "SPF configured" to "SPF absent" in one step, and the only place that's visible is in DMARC aggregate reports, which most people aren't reading yet. Six terms cost a lookup. Four are free. Costs a lookup Free include: ip4: a ip6: mx all ptr exp= exists: redirect= The count isn't yours to control This is what catches people out. The limit applies to the whole resolution tree, not just your record. You publish four includes. One of those vendors publishes six includes of their own. You're at eleven, and your record lists four things. Nothing changed on your side. A vendor updated their record and broke yours. There is no notification for this, from anyone, ever. Counting it by hand You can walk the tree with dig if you want to see it directly: dig +short TXT example.com | grep spf1 Then for every include: you find, recurse: dig +short TXT _spf.vendor.com | grep spf1 Keep going until you bottom out, counting every include: , a , mx , ptr , exists: and redirect= along the way. It's tedious but instructive — you'll usually find one vendor accounting for half your budget. Three traps that make tools lie to you Doing this by hand or with a naive script, there are three places to go wrong. I've seen all three produce confidently incorrect output. 1. redirect= uses = ,

If you have ever bought a domain on Namecheap to redirect traffic to your main web app, you might have hit a frustrating wall: Namecheap's free "Domain Redirect" feature works fine for plain http:// requests, but it completely falls flat when someone hits https:// . Browsers try to perform an SSL/TLS handshake before following the HTTP redirect header. Because Namecheap does not issue a free SSL certificate for basic domain forwarding, your users end up seeing a scary "Your connection is not private" error. Here is how to set up a full, seamless redirect from an old domain ( snapseek.co ) to a new domain ( snapseek.app ) using Cloudflare's free tier. This approach handles both HTTP and HTTPS, while preserving all incoming URL paths and query parameters. The Big Picture Instead of serving traffic through Namecheap's basic forwarding servers, we hand off DNS management to Cloudflare. Cloudflare acts as a reverse proxy, provides a free universal SSL/TLS certificate, and handles the redirection right at the edge using its modern Single Redirect Rules engine. Step 1: Add Your Domain to Cloudflare Log into your free Cloudflare account (or sign up if you do not have one). On your dashboard under the Home tab, click Add a domain . Type in your source domain (e.g., snapseek.co ) and choose Quick scan for DNS records . When prompted to select a plan, scroll down to the bottom and pick the Free plan. Cloudflare will scan your existing DNS setup. Scroll down and click Continue to activation . Cloudflare will display a pair of custom nameservers (for example: ada.ns.cloudflare.com and sam.ns.cloudflare.com ). Copy these down. Step 2: Update Nameservers in Namecheap Log into your Namecheap account and go to your Domain List . Click Manage next to your domain ( snapseek.co ). Find the Nameservers dropdown section. Switch it from Namecheap BasicDNS to Custom DNS . Paste the two Cloudflare nameservers into the fields and click the green checkmark to save. Note: DNS propagation usual

Cloudflare has launched its Internal DNS service, providing authoritative and recursive DNS for private networks. This service simplifies DNS management by consolidating private and public DNS operations on a single platform. By Gianmarco Nalin

I run HydraDNS, an open-source DNS security gateway in Go. Last month I sat down to find out what one box could actually handle before I put it on anyone else's network. The plan had a rule I'd written for myself: every number we discover becomes either a sales claim or a fix ticket. No number, no claim. I expected to find one bottleneck. I found two, stacked on top of each other, and a third thing I wasn't looking for: a data structure in our own documentation that had never existed in the code. Everything below was measured on a 22-core dev machine with load generated inside the container, using dnspyre, so docker-proxy and host networking stay out of the numbers. It's not appliance hardware and I'm not making appliance claims. The shapes are what matter. The first ceiling: ~500 QPS, and it didn't care what I threw at it The first redline run capped at roughly 500 queries per second. Fine, servers have limits. What made it interesting was that the cap didn't move. Blocked queries: ~500. Cached queries that never touch upstream: ~500. Two code paths that do completely different work, hitting the same wall, with the CPU sitting under 30% of 22 cores. That signature is worth memorizing. When two very different paths hit the same ceiling and the CPU is bored, the bottleneck isn't in either path. It's in something they share, or something upstream of both. Ours was in the blocklist check. IsBlocked ran a SQL COUNT against a 92k-row blocklist_entries table on every query . Not just candidate blocks, every query, because the check sits in front of the cache, so even cache hits paid for it. And all of those reads were serialized through a single SQLite connection, MaxOpenConns=1 , which was also absorbing the async write traffic from query logging. The engine's self-measured latency under load: p50 of 50ms, p99 of 5000ms. Five full seconds at the tail, for DNS, which is supposed to be the fast part of the internet. The part where I found out our docs were lying Here's the

If your app sends email — transactional or marketing — three DNS records decide whether it lands in the inbox or the spam folder: SPF , DKIM , and DMARC . Here's how to look them up and sanity-check them in Python, no third-party API required. Install the one dependency: pip install dnspython SPF: who is allowed to send SPF lives in a TXT record on the domain itself and starts with v=spf1 . import dns.resolver def get_spf ( domain ): for rec in dns . resolver . resolve ( domain , " TXT " ): txt = b "" . join ( rec . strings ). decode () if txt . startswith ( " v=spf1 " ): return txt return None print ( get_spf ( " github.com " )) # v=spf1 ip4:... include:_spf.google.com ~all A quick gotcha worth checking: SPF allows at most 10 DNS-querying mechanisms ( include , a , mx , ptr , exists , redirect ). Go over and receivers return permerror , which quietly breaks authentication: def spf_lookup_count ( spf ): return sum ( spf . count ( m ) for m in ( " include: " , " a: " , " mx: " , " ptr " , " exists: " , " redirect= " )) spf = get_spf ( " example.com " ) if spf and spf_lookup_count ( spf ) > 10 : print ( " ⚠️ SPF exceeds the 10-lookup limit " ) DMARC: the policy that ties it together DMARC is a TXT record on the _dmarc. subdomain and starts with v=DMARC1 . def get_dmarc ( domain ): try : for rec in dns . resolver . resolve ( f " _dmarc. { domain } " , " TXT " ): txt = b "" . join ( rec . strings ). decode () if txt . startswith ( " v=DMARC1 " ): return dict ( kv . strip (). split ( " = " , 1 ) for kv in txt . split ( " ; " ) if " = " in kv ) except dns . resolver . NXDOMAIN : return None print ( get_dmarc ( " github.com " )) # {'v': 'DMARC1', 'p': 'reject', 'rua': 'mailto:...'} The key field is p : none (monitor only), quarantine (spam folder), or reject (bounce). If a domain sends real mail but has p=none , it's not protected against spoofing yet. DKIM: the signature key DKIM is trickier because you need the selector — a label chosen by the sender that lives at SELECT

Email authentication has been "solved" on paper for years. SPF, DKIM, and DMARC are old standards, every deliverability guide repeats them, and Google and Yahoo made DMARC effectively mandatory for bulk senders in 2024. So I expected the top of the web to be in good shape. In June 2026 I ran SPF, DKIM, DMARC, and MTA-STS checks across the Tranco top 10,000 domains, using public resolvers (1.1.1.1 and 8.8.8.8) and the same checks my own tool runs. The records are public DNS, so anyone can reproduce this. The picture is worse than the "solved problem" framing suggests, and the interesting part is not adoption, it is where people stop. A third of the top 10k still have no DMARC 3,318 of the 9,937 domains that resolved (33.4%) publish no DMARC record at all. These are not obscure sites, they are the most-visited domains on the web. Without DMARC a receiver has no published instruction for what to do when SPF and DKIM fail, and you get none of the aggregate reporting that tells you who is sending as you. It does get better at the very top. Among the top 1,000 domains, 28.4% have no DMARC, versus 34% across the rest of the 10k. Better, not good. The real problem is p=none, not missing records This is the number that actually matters. Of the 6,619 domains that do publish DMARC, only 46.5% are at p=reject . About a quarter (26%) are still sitting at p=none . p=none is monitor-only. It asks receivers to report what they see and to enforce nothing. It is the correct first step: publish p=none , collect aggregate reports, fix the sources that should be passing, then tighten the policy. The trouble is that p=none is also where most deployments quietly stop. The reports start arriving, nobody reads them, and the domain sits unprotected behind a policy that does nothing while looking like progress. Moving from p=none to p=reject is the step that turns DMARC from a dashboard into a defense, and it is the step most people never finish. I wrote up the safe way to make that move , si

You type www.google.com into your browser and hit Enter. The page loads in under a second. But stop and think about what just happened. Your browser didn't know where Google lives on the internet. It had to ask. And in that fraction of a second, a surprisingly elegant chain of lookups took place behind the scenes. That system is called DNS — the Domain Name System. Think of it as the internet's phonebook: it translates human-friendly names like www.google.com into machine-friendly IP addresses like 142.250.80.46 . Without it, you'd have to memorise numbers to visit any website. Let's walk through exactly what happens, step by step. Step 1: You Type a URL — But What Does It Mean? When you type www.bing.com , you're entering a domain name . Domain names have a structure — and reading them right-to-left tells you a lot: www . bing . com │ │ │ │ │ └── Top-Level Domain (TLD): category or country │ └──────── Second-Level Domain (SLD): the brand/org name └─────────────── Subdomain: a section of the site (optional) Some real examples: Domain TLD SLD Subdomain www.bing.com .com bing www news.bbc.co.uk .uk bbc news docs.github.com .com github docs TLDs indicate the type or origin of a site — .com for commercial, .edu for education, .in for India, and so on. Step 2: Your Browser Checks Locally First Before going anywhere on the internet, your browser does a quick local check — two of them, actually. 1. Browser cache Modern browsers cache DNS results from previous lookups. If you visited bing.com five minutes ago, the browser already knows its IP and skips the entire lookup process. 2. The hosts file Your operating system has a plain text file that maps domain names to IPs manually. On most systems it lives at: Windows: C:\Windows\System32\drivers\etc\hosts Mac/Linux: /etc/hosts It looks like this: 127 . 0 . 0 . 1 localhost 192 . 168 . 1 . 10 mydevserver . local Developers use this all the time for local testing — mapping a production domain name to a local IP to test before go