Recently, I helped a friend deal with a DNS hijacking incident and found that a lot of people are still using a bare-bones domain name resolution service. The attacker directly led the traffic to the phishing site, user complaints like snowflakes flying over. These days, even CDNs have to “prevent teammates”, let alone public DNS.
You may think that with a high-defense CDN everything will be fine, but do not forget: DNS is the first gate of the traffic entrance. If the gate is pried, the back of the wall is no use to build a high wall. I have tested a number of cases, 90% “traffic anomaly” is not a CC attack, but the DNS level has long been pierced.
DNS hijacking has long been more than just changing a resolution.The “man-in-the-middle package” is now in vogue. Now popular is the "man in the middle package": first pollute the local DNS cache, and then with the ISP level response to tampering, and even directly against the registrar to launch attacks. Last year, the domain name of a well-known e-commerce company was pointed to a malicious IP, the root cause is the registrar's account was social worker, and the CDN has nothing to do with - but the user will only feel that your site collapsed.
This is the time to bring out the old warhorse DNSSEC. Don't be scared by this word, to put it bluntly, it is to make a digital signature for DNS records. Like you go to the bank to withdraw money, the teller not only to check the ID card (domain name resolution), but also to check the fingerprints (digital signature). Forgery would have to smash through the cryptography foundation, the cost of direct pull full.
However, many people step on more potholes than problems when configuring DNSSEC. For example, they use some foreign registrars but forget to turn on DS record synchronization, or the TTL is set to a huge length, resulting in a slow rollback like a snail in case of failure. The most painful lesson I learned was when I deployed it to a financial platform, because the NS server didn't support EDNS0, which directly led to the resolution timeout for users in the Asia-Pacific region - the history of blood and tears tells us that:Test before you go live, and don't trust vendors“ ”default compatibility".”。
Here to post a real test usable DNSSEC check script (can not run you to hit me):
DNSSEC alone is not enough. Domestic network environment is too complex, telecom users go Unicom line delay soared to 300ms is common. This time we have to offer up the magic weapon of multi-line resolution. But don't be silly with the geographic division - now users are hanging VPN, you IP geographic location routing is not as reliable as throwing darts.
My current program isthree-tier diversion strategyThe first step is to identify the carrier's backbone network by ASN (Autonomous System Number), then dynamically adjust the weights according to the real-time delay, and finally use Anycast to guarantee the bottom. In particular, service providers with BGP Anycast like CDN07, together with multi-line parsing, can harden the parsing latency to within 50ms.
Take the case of our migration to 08Host last year: the original telecom users are always routed to Unicom nodes, and then in the DNS level to do ASN identification + delay detection, directly let the resolution hit rate increased by 40%. the configuration is long like this:
But don't think you can rest easy with DNSSEC+Multiline on your sleeve.DNS cache poisoning, NS server DDoS, and even certificate transparency log forgery...... attackers play more tricks than you think. I once bumped into a team planting a Trojan specifically targeting small carriers with recursive DNS poisoning because their DNS software version was still stuck in 2014.
The real value of a high-defense CDN is in the pockets. Nodes like CDN5 will verify the DNS resolution results twice: if it detects that the resolved IP matches the threat intelligence database, it directly triggers the cleaning process. This is equivalent to adding double insurance to the DNS - even if the front-end resolution is tampered with, the traffic to the edge node there is a last chance to correct the error.
Throw in a final storm theory:Daring to not use DNSSEC's team in 2024 is the equivalent of running the highway in a cash truck without a safe!But don't overdo it. But don't overdo it - I've seen a company to internal testing domains also on a full set of DNSSEC, every time you change the record to wait for the signature synchronization, the developers almost put the operation and maintenance sacrifice.
The real reliable architecture has to be nested like an onion: DNSSEC tube authentication, multi-line parsing tube performance optimization, high-defense CDN tube traffic cleaning. By the way, Amway a riotous operation: CNAME flattening the CDN vendor's alias record flattening, both to enjoy the accelerating effect of CDN, but also to avoid the resolution of the chain is too long leading to failure points.
Let's get this straight: many organizations are still focusing on firewalls and WAFs for their security investments, and DNS security is all on the go. But look at the major security incidents of recent years, from the GitHub hijacking to the Brazilian bank paralysis, which is not torn from the DNS level?Domain name resolution is the two veins of the Internet, if it is pinched here, all subsequent defenses are just for show.。
By the way, if you're in the process of selecting a model, remember to test the vendor's DNSSEC compatibility. Some of the old vendors (not to be named) EDNS support sucks like a sieve, it would be better to use 08Host this kind of emerging service providers - at least people from the first day of the birth of the full-stack support DoH/DoT. measured data here: the same node to open the DoH, the resolution latency fluctuations from 200ms down to less than 30ms! The reason for this is that the local ISP's DNS contamination chain has been skipped.
This thing of technology is most afraid of half-assed. Either like the next door to Mr. Wang's team to completely lay flat with public DNS, or honestly DNSSEC + multi-line + CDN three-piece suit with all. The most afraid of the kind of spending millions to buy high defense, the result is to save a few thousand dollars DNS professional version of the service - the same as to the vault to install iris locks, but the key is inserted in the door.
The next time you encounter a “site can not be opened but ping through” psychic event, first take out the hand of the DNS diagnostic three axes: check the DS record, check the RRSIG signature, measure the line routing. Guaranteed eighty percent of the problem can be located on the spot - the remaining two percent? That is the operator backbone network bombed, hurry to soak noodles and other repair it.
