Your caveat assumption is a very bad one. DNS is not protected from tampering nor hijacking, nor man-in-the-middle (MITM) attacks. So the best way to break into your internal networks are to redirect employee requests for internal resources to hostile servers that engage in credential stealing and/or social engineering.
Giving an attacker knowledge of server names and their (likely RFC 1918) addresses is of much less concern in comparison.
The major risk is that you go outside the network, to the Internet, for resolution of addresses.
This assume you have a local DNS server in your house. I do; most of my friends in Silicon Valley do. Admittedly, we each have on average 10 computers or so sitting behind our public IP address; I currently have about 45, but I’m running a compute cluster for COVID-19 research. I wonder if anyone has considered the cooling capacity of a backyard swimming pool, to hide this and other things, like the Cherenkov from local power generation?
Whatever.
The point for DNS is that as long as the requests are
The major risk is that you go outside the network, to the Internet, for resolution of addresses.
This assume you have a local DNS server in your house. I do; most of my friends in Silicon Valley do. Admittedly, we each have on average 10 computers or so sitting behind our public IP address; I currently have about 45, but I’m running a compute cluster for COVID-19 research. I wonder if anyone has considered the cooling capacity of a backyard swimming pool, to hide this and other things, like the Cherenkov from local power generation?
Whatever.
The point for DNS is that as long as the requests are allowed through your router, they are allowed through, and you can pick whatever authority, including a darknet one, to resolve requests.
It’s one of the protocols, like HTTP, or HTTPS, which is “automatically allowed through”. It has to be, or the Internet, and your SmartTV stop working, and people start bitching about it, loudly enough that there are political repercussions from Netflix “not happening any more”.
Which means “no more bread and circuses” style control over the population.
So DNS work, because DNS has to work.
You really need to read Nitche, Nero, Copernicus, and Orwell more.
The Domain Name System (DNS) is vital to the good functioning of the Internet, and this makes it a common target of cyberattacks.
While this is a broad question, I can think of two significant issues with DNS security—DNS vulnerabilities and the variety of DNS-related attacks that the bad guys can execute. These issues are interrelated, as some DNS attacks are made easier or even at all possible because of the vulnerabilities surrounding how an organization’s DNS infrastructure is set up.
One example of a DNS vulnerability is allowing recursive queries from any IP address. In this type of query
The Domain Name System (DNS) is vital to the good functioning of the Internet, and this makes it a common target of cyberattacks.
While this is a broad question, I can think of two significant issues with DNS security—DNS vulnerabilities and the variety of DNS-related attacks that the bad guys can execute. These issues are interrelated, as some DNS attacks are made easier or even at all possible because of the vulnerabilities surrounding how an organization’s DNS infrastructure is set up.
One example of a DNS vulnerability is allowing recursive queries from any IP address. In this type of query or lookup, a DNS server can communicate with other DNS servers on behalf of the user. For example, if the requested IP address is not found on the local DNS server, it would forward the request to the root DNS server. If the IP address is still not found, the root DNS server will communicate with the top-level domain (TLD) DNS server until the IP address is located. At some point in the communication process, cyber attackers could attempt to provide a malicious response (i.e., an IP address that may lead to deceptive or malicious content).
Other elements that can be vulnerable to attacks are DNS caches. Threat actors can poison these so requests meant for cached DNS resolutions would redirect users to malicious sites. DNS cache poisoning is a method to execute DNS spoofing, where a user who wants to access an online banking website, for example, could be given a malicious IP address instead. The IP address then resolves to a fake version of the target bank’s website where the users can be tricked into typing their login credentials. As such, DNS cache poisoning / DNS spoofing provides an entry point for attackers to steal user data.
DNS flooding, another type of DNS-based attack, is also quite common nowadays. In this case, threat actors send a massive volume of requests to a target DNS server until it gets flooded and can no longer function correctly. These requests may be of different types. For instance, attackers could also request for nonexistent domains or subdomains such that the target DNS server’s resources get spent looking for something that is not there.
In short, DNS security issues can often be traced to DNS vulnerabilities, such as allowing recursive DNS queries and not following DNS caching best practices. Those issues also stem from the fact that there are many ways in which attacks can be done. DNS spoofing and DNS flooding are just a few examples of such attacks.
It’s potentially putting you at risk for Man-in-the-middle attack that can lead to Remote Code Execution. In other words, someone may end up having access to your endpoint / device. How’s that possible? See below
- Let’s assume you want to go http://www.somewebsite.com (notice it’s HTTP and not HTTPS!), the attacker (i.e. malicious DNS server) may response that WWW.SOMEWHERE.COM IP is an IP of malicious website that looks the same but is not. In that case, you’re social engineered and while you authenticate the attacker may steal your credentials.
- Same as #1, instead of social engineering you (i.e
It’s potentially putting you at risk for Man-in-the-middle attack that can lead to Remote Code Execution. In other words, someone may end up having access to your endpoint / device. How’s that possible? See below
- Let’s assume you want to go http://www.somewebsite.com (notice it’s HTTP and not HTTPS!), the attacker (i.e. malicious DNS server) may response that WWW.SOMEWHERE.COM IP is an IP of malicious website that looks the same but is not. In that case, you’re social engineered and while you authenticate the attacker may steal your credentials.
- Same as #1, instead of social engineering you (i.e. stealing your password), the attacker will redirect you to a website that embeded in it an Exploit Kit. The Exploit Kit will try to exploit a client-side software that you may have and if successful, it will grant the attacker remote code execution on your endpoint
- An application that you already have installed is performing an upgrade in an secure manner. In other words, it will try to download an executable (i.e. updated version of itself) over HTTP, as such, an attacker may redirect it to his own controlled server and serve malicious update that in turn will run on your computer. I actually gave a talk this attack a few years ago in DEF CON conference.
As you can see, there’s too much to lose and to little to gain by using an untrusted DNS server.
There are no risks of changing default gateway, because every ISP limits their use just for its customers. You can’t just change default gateway to random IP address and expect it will work.
You must always follow network tree structure created by your ISP. ISP defines all rules how many devices (customers or routers) can be connected to its network and also defines rules who can connect and who not. For each customer also defines maximum speed according to how much customer pays. Therefore you can’t just choose gateway of another ISP and use it without paying them.
Default gateway can’t be chan
There are no risks of changing default gateway, because every ISP limits their use just for its customers. You can’t just change default gateway to random IP address and expect it will work.
You must always follow network tree structure created by your ISP. ISP defines all rules how many devices (customers or routers) can be connected to its network and also defines rules who can connect and who not. For each customer also defines maximum speed according to how much customer pays. Therefore you can’t just choose gateway of another ISP and use it without paying them.
Default gateway can’t be changed, but DNS can be changed without bigger problems, unless ISP has its own website for customers where customer can watch their bills etc. Such website might stop working if you change DNS server to other value than specific value from your ISP.
Most likely you are by default using the public DNS. Even if your DNS is on your private router, it will forward requests it doesn’t know about to a public DNS.
When you request a translation from a name to an IP address, the first DNS checks to see if it already knows the answer. If so, it will respond with a non-authoritative response. If it doesn’t know the answer, it will forward the request to one of the root servers. The root server has records for all of the tlds (top level domains) like .com, .edu,.gov, etc. assuming the response is not cached anywhere, each level in the query will be f
Most likely you are by default using the public DNS. Even if your DNS is on your private router, it will forward requests it doesn’t know about to a public DNS.
When you request a translation from a name to an IP address, the first DNS checks to see if it already knows the answer. If so, it will respond with a non-authoritative response. If it doesn’t know the answer, it will forward the request to one of the root servers. The root server has records for all of the tlds (top level domains) like .com, .edu,.gov, etc. assuming the response is not cached anywhere, each level in the query will be forwarded to the DNS that is authoritative for that level. Eventually the request will arrive at the DNS server that is authoritative for your request and you will receive the response. So if you ask for any of the public names, you will have to have used at least one of the public DNS servers.
Browsers do have a cache for storing the DNS results but the records are expired very fast. In Google Chrome, type chrome://net-internals/#dns in the address bar and it will show you the cached records and their expiry times. In case of Firefox, the default time for which the DNS results are cached is only 60 seconds. Look for the preference network.dnsCacheExpiration after typing about:config in the Firefox address bar.
In addition, the sytem resolver also has a DNS cache where the records are cached as per their TTL.
It is actually not a good idea to let browsers cache DNS records for long. Ma
Browsers do have a cache for storing the DNS results but the records are expired very fast. In Google Chrome, type chrome://net-internals/#dns in the address bar and it will show you the cached records and their expiry times. In case of Firefox, the default time for which the DNS results are cached is only 60 seconds. Look for the preference network.dnsCacheExpiration after typing about:config in the Firefox address bar.
In addition, the sytem resolver also has a DNS cache where the records are cached as per their TTL.
It is actually not a good idea to let browsers cache DNS records for long. Many of the high traffic web sites use DNS based tricks for load balancing, failover, disaster recovery and also for geographical location based routing of traffic. Also the cloud based web sites can be dynamic and the request needs to be directed to the live server at that moment.
The leading DNS providers have started spreading their DNS servers across multiple networks and operators so that any outage or attack would still keep some servers accessible.
Threats to Domain Name System (DNS) security are among the most common types of cyber threats. In fact, there have been several reports about large organizations suffering from cyber attacks that can be traced back to DNS abuse. Remember in 2016 when millions of users weren’t able to access Twitter for some time? That was a DNS security threat in action. Twitter’s DNS provider, Dyn DNS, suffered from a distributed denial-of-service (DDoS) attack that flooded its DNS servers with a massive amount of traffic, rendering them practically useless.
DNS threats can be grouped into two categories based
Threats to Domain Name System (DNS) security are among the most common types of cyber threats. In fact, there have been several reports about large organizations suffering from cyber attacks that can be traced back to DNS abuse. Remember in 2016 when millions of users weren’t able to access Twitter for some time? That was a DNS security threat in action. Twitter’s DNS provider, Dyn DNS, suffered from a distributed denial-of-service (DDoS) attack that flooded its DNS servers with a massive amount of traffic, rendering them practically useless.
DNS threats can be grouped into two categories based on the following purposes:
- Threats that aim to infiltrate a victim’s network
- Threats that seek to cripple a target network
Let’s start with DNS threats that aim to infiltrate a victim’s network. While this is the obvious goal, the underlying reason for attackers wanting to get into a network is to steal data. They do that by typically redirecting users to fake websites under their control.
Instead of the legitimate IP address of the requested domain, attackers find ways to return a malicious IP address. That can be accomplished in many ways. Below are three of the most common methods:
- DNS hijacking: Attackers use malware to run scripts that can change the infected device’s DNS configuration. In a nutshell, DNS requests are sent to the attackers instead of the DNS server, allowing them to send malicious responses.
- DNS cache poisoning: Also known as “DNS spoofing,” this type of attack requires threat actors to change or poison a victim’s local DNS cache. They would then be able to change the stored IP resolution to a malicious IP address.
- DNS tunneling: In this type of DNS attack, threat actors inject malicious data into legitimate DNS traffic. By doing so, they bypass network firewalls and can extract data from a victim’s device and possibly some parts or the whole network.
The second category of DNS threats include those that aim to render a target’s network inoperable. They do this by flooding the target’s DNS server with a massive traffic volume until it is overwhelmed and can no longer respond to legitimate requests.
Attackers usually tap a network of bots or botnets that are mostly Internet-connected devices, making this a form of DDoS attack. The owners of these devices may not know that they are already involved in the attack, hence, they can also be considered victims.
The most common types of DNS flooding attacks are:
- NXDomain attacks: Threat actors repeatedly request for invalid or nonexistent DNS records until a target’s network gets overloaded.
- Phantom domain attacks: The attackers set up phantom domains that do not respond to DNS requests. They would send requests for these phantom domains to a target server, using up its resources while it waits for responses.
- Random subdomain attacks: Attackers would flood a target network with DNS requests for random nonexistent subdomains. The root domain is valid, but the requested subdomains are not. As in phantom domain attacks, a target’s resources are spent looking for these subdomains.
There are many threats to DNS security, which is why several organizations typically implement strict DNS protection policies and strategies. Among these security measures are:
- Educating network users about the perils of phishing, as this is one of the top entry points for DNS attackers
- Setting up DDoS protection solutions
- Limiting DNS response rates
- Implementing a zero-trust approach, where all suspicious DNS traffic is blocked and investigated
There are 3 things to check.
1. Is the server secure? Scan all open ports, as if it were a regular server, and look for vulnerabilities.
2. Is the DNS service secure? There are quite a few different vulnerabilities specific to DNS implementations. CVE has a comprehensive list [ http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=resolver ]. Windows, bind, all have had issues.
3. Is the DNS service setu
There are 3 things to check.
1. Is the server secure? Scan all open ports, as if it were a regular server, and look for vulnerabilities.
2. Is the DNS service secure? There are quite a few different vulnerabilities specific to DNS implementations. CVE has a comprehensive list [ http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=resolver ]. Windows, bind, all have had issues.
3. Is the DNS service setup properly? I guess this is what you are looking for. An improperly set up DNS may allow ...
The chief risk of using DNS from a lesser-known provider is that you won’t have very good assurance of how well they secure their systems. The result is that you may get poisoned DNS query results that direct you to malicious servers instead of the ones you wanted.
No, not really. Unless, of course, they can hijack it. But if they can do that, and it's a publicly used one, like Google's 8.8.8.8 or Level 3's 4.2.2.2 or something, then there are big problems with the entire internet (because they're so broadly used.)
Most attackers who want to use a DNS attack will use some sort of DNS redirector to change your DNS server to their server. They won't even bother trying to attack a public DNS server.
Maybe.
If you are going to make a change which obsoletes a record (that name will no longer be in use), don’t delete it as part of the change. If you have to back out the change, you will need to put it back, and propagation may take some time. Wait until you are sure you won’t have to back the change out.
If it’s old junk that hasn’t been used in months, delete it if you are really sure it’s not being used for anything.
If you have two DNS records of the same type with the same name, you MUST delete an obsolete one. For example, if you have two IP addresses for your main web server, and one of t
Maybe.
If you are going to make a change which obsoletes a record (that name will no longer be in use), don’t delete it as part of the change. If you have to back out the change, you will need to put it back, and propagation may take some time. Wait until you are sure you won’t have to back the change out.
If it’s old junk that hasn’t been used in months, delete it if you are really sure it’s not being used for anything.
If you have two DNS records of the same type with the same name, you MUST delete an obsolete one. For example, if you have two IP addresses for your main web server, and one of them no longer works, then half of the visitors will go to a dead site. You might make the changes like this, if for some reason you MUST change the IP address of the web site, say, because it’s in a different location from the old one.
- www points to IP A and it’s been that way for a long time.
- Bring up site B and test it.
- Add a www A record pointing at IP B
- Continue testing the new site and make sure you don’t have to back it out. Does it handle the load?
- Delete the www A record pointing at IP A
- Wait for the change to propagate. (e.g. 48 hours)
- Take down site A
DNS monitoring is vital for maintaining the reliability and security of network services. By continuously tracking DNS traffic and resolving queries, potential issues like downtime, latency, or malicious activities can be swiftly identified. Reliability is ensured through constant performance, availability, and security monitoring, which includes detecting and mitigating DNS-based attacks. Implementing redundancy, failover mechanisms, and regular audits further solidify the resilience of DNS services, guaranteeing uninterrupted access to vital online resources.
There are two primary advantages. One is true for all users and the second for those with multiple devices on the LAN.
- Third parties can’t see what sites you are searching for. Your search history is valuable to commercial interests as it gives them a way to ‘spy’ on you and learn about you.
- If you have multiple devices on your LAN, you can set up private IP lookups for those devices, with the corresponding private IP address, which are not accessible from outside your LAN.
- This is even more important if you are operating a server to client VPN for your operation.
Using the custom DNS instead of the DNS provided by ISP provider may caused the security issues such as below:
01. Privacy concerns: DNS server can collect information about our online activities so it may cause the privacy issues.
02. Phishing: A custom DNS server cannot detect and block the phishing website as an ISP’s DNS server.
03. Spoofing: A custom DNS can redirect you to a spoofing website.
04. Outage: A custom DNS server’s are not reliable and they can cause the more downtime.
Usually a company or other organization will want to have their internal network separate from the Internet in general. So they will have “internal” DNS servers that are not accessible from the Internet but are accessible from the internal network. The internal DNS servers can answer questions about the internal hosts. The external DNS servers respond to questions from the Internet, feign ignorance about most internal hosts, but answer questions about a few hosts meant to be exposed to the internet (e.g. company web server, mail server). Note that a DNS server is a process that runs on a host.
Usually a company or other organization will want to have their internal network separate from the Internet in general. So they will have “internal” DNS servers that are not accessible from the Internet but are accessible from the internal network. The internal DNS servers can answer questions about the internal hosts. The external DNS servers respond to questions from the Internet, feign ignorance about most internal hosts, but answer questions about a few hosts meant to be exposed to the internet (e.g. company web server, mail server). Note that a DNS server is a process that runs on a host. A host is a machine that can, among other things, run server processes.
“What are the risks of changing your DNS settings on your router?”
The DNS settings on your router are probably configured to access the DNS servers of your internet provider. Changing away from these settings to a third party DNS server puts you at the mercy of that third party — they could change the IP address of their DNS server, block traffic from your provider or shut the server down completely and (unless you are paying for access) they have no obligation to tell you. Your own provider however doesn't want thousands of calls from customers asking why they can't access anywhere on the int
“What are the risks of changing your DNS settings on your router?”
The DNS settings on your router are probably configured to access the DNS servers of your internet provider. Changing away from these settings to a third party DNS server puts you at the mercy of that third party — they could change the IP address of their DNS server, block traffic from your provider or shut the server down completely and (unless you are paying for access) they have no obligation to tell you. Your own provider however doesn't want thousands of calls from customers asking why they can't access anywhere on the internet anymore and so changing IP addresses or shutting down servers is not in their interest — even if they start telling people well in advance.
Unless there is a compelling reason for such a change — I wouldn't contemplate doing so personally but it's up to you in the end.
Q: Should you delete old DNS records?
DNS records in all DNS servers apart from the one server holding the authoritative record for the domain. Records in all the secondary caching DNS servers should be deleted by those servers when the TTL (Time To Live) for the record expires. When a cache server’s record expires, the next time it is asked for the address for a specific domain, it has to go back up the chain to load a new up-to-date copy.
The authoritative records are set up by the server’s administrator. This includes the domain name, IP address, TTL and a number of other parameters, This inf
Q: Should you delete old DNS records?
DNS records in all DNS servers apart from the one server holding the authoritative record for the domain. Records in all the secondary caching DNS servers should be deleted by those servers when the TTL (Time To Live) for the record expires. When a cache server’s record expires, the next time it is asked for the address for a specific domain, it has to go back up the chain to load a new up-to-date copy.
The authoritative records are set up by the server’s administrator. This includes the domain name, IP address, TTL and a number of other parameters, This information is passed to caching servers. Caching servers can pass on information to other caching servers, but should adjust the TTL so that the expiry time of a record occurs at the same time on all cache servers that are in an effective chain.
The proper mechanism for retiring or changing the address for a domain to to set the authoritative record TTL to a low value (often around 10 minutes) then wait for the original TTL time period to ensure that all cache servers have had a chance to reload with the new shorter TTL. Once all the servers have picked up the new low TTL, then the authoritative address can be changed and the longer TTL can be restored. For up to 10 minutes (or whatever the low TTL was set to) the old IP address may be issued in response to queries; however, it will normally take longer for the website to be set up fully on its new address, so for 10 minutes, the website will be down.
If the authoritative record is deleted from its specific server, all caching servers should delete their copies of the record when the authoritative TTL value expires.
Unless you are running your own private DNS server, you will not be carrying any authoritative records, and it should not really be necessary to delete any old records as they should expire and be removed automatically.
DNS answer change - some very regularly. Also DNS is often used for traffic management purposes, either to load balance by geography (sending US requests to US servers and European request to European servers), or for resilance (send to server A, unless server A goes down, then send to server B). On top of that, even if you did cache all the answers you have recieved so far, what about new queries? They would fail As well.
In short, it might help a bit but is likely to introduce more issues than it solves.
Using local servers has the following advantages.
a) you might get the answers faster (in case they were cached already. And if your internet segment suffers from connectivity issues, you still might get the answers from cache
b) you may provide your own DNS data to your clients.
Nowadays the first point is not so important due to the fashion for extremely short DNS TTLs.
If you lose access to your DNS records, it could cause serious disruptions to your website or online services. You would need to contact whoever is responsible for managing the domain in order to regain control of the records, which may take some time. It's important to ensure that you have a backup of all essential data related to your domain so that restoring service can be done quickly if necessary.
Your DNS is only used to translate names to IP addresses. Other internet connections will go through your ISP to the location of the server. While there is always the potential for a DNS hack, the folks at Google are among the best to detect and fix any such hack. They also have robust rules in place to prevent those hacks.
Secure DNS servers can take a number of forms. ... This kind of zero trust mentality makes it more difficult for cybercriminals, whether sophisticated or novices, to gain access to your DNS and plague it with DDoS attacks, for instance—effectively blocking others from getting responses from your domain.
Zerigo does a good job at DNS hosting at a good price. I used to use them whenever I created a new site on Heroku since it was easy and free. The downside to the free account is that you are limited to a small amount of records and, when coming from Heroku, each zone is going to be under its own account and thus you really must go through Heroku to make it manageable. The other downside is that their per month query limits on the free account are 50k (although this is more than sufficient for a low-traffic site).
Alternatives with an API include:
- DynDNS - $30 for 600k queries per month
- Amazon Rou
Zerigo does a good job at DNS hosting at a good price. I used to use them whenever I created a new site on Heroku since it was easy and free. The downside to the free account is that you are limited to a small amount of records and, when coming from Heroku, each zone is going to be under its own account and thus you really must go through Heroku to make it manageable. The other downside is that their per month query limits on the free account are 50k (although this is more than sufficient for a low-traffic site).
Alternatives with an API include:
- DynDNS - $30 for 600k queries per month
- Amazon Route 53 - $1 per month + $0.50 per 1 mil queries
- DNSimple (my service) - $3 per month, currently no query limit
Both DynDNS and DNSimple also provide domain registration, whereas Amazon Route 53 and Zerigo do not at this time.
Ya. There are a lot of ways to set up DNS so it's not a single point of failure. Which is what I think you’re asking about. Set up 2 or more DNS servers on different networks with different connections to the internet. If you don’t have a separate network get a virtual server. I’d suggest Google Cloud Services. Its a few bucks. I used to keep one for no good reason… $5/ month.
Start googling and reading.
Currently there is a global outtage at Zerigo, affecting all the services which hosts DNS there. This lasts for a good few hours already already and there is close to none response from Zerigo. All we know, this might be DDOS related, but no ETA or further explanation whatsoever.
I guess this pretty much sums up the service as a whole. Its was fine while it worked, but the reaction to the issues is horrible, so I am not even considering using it anymore.
additional layer of security. Consequence that you may end up upgrading your CF account to a paid one.
Zerigo is very competitive for the price/features. I've been a customer for a few years now, and I have all my non-critical DNS hosting with them. They have a nice API, functional web interface, good support. I started with free domains (which you can make stretch a long time if you manage your TTLs properly), and have since upgraded to one of the lower tier pay plans.
Taking a quick look at DNSimple, I like that DNSimple has an iPhone app, but I don't like their jump to $120/yr after 10 domains (Compared to 20 domains for $19/yr that I pay Zerigo)
For more critical sites, you should go with an
Zerigo is very competitive for the price/features. I've been a customer for a few years now, and I have all my non-critical DNS hosting with them. They have a nice API, functional web interface, good support. I started with free domains (which you can make stretch a long time if you manage your TTLs properly), and have since upgraded to one of the lower tier pay plans.
Taking a quick look at DNSimple, I like that DNSimple has an iPhone app, but I don't like their jump to $120/yr after 10 domains (Compared to 20 domains for $19/yr that I pay Zerigo)
For more critical sites, you should go with an AnyCast DNS provider - I use DNSMadeEasy.
See a little blog blurb I did about my DNS services I use: http://www.mikeschroll.com/blog/2011/12/07/services-i-use-and-why/#DNS
I also just did a little writeup of DNS Providers: How does zerigo compare to pointhq? - my thoughts were that Zerigo is superior.
Privacy basically. Google can know which sites you are visiting and then can keep tracks and using for the advertising.
Custom DNS servers can pose security risks as they might not have robust security measures or reliable maintenance compared to ISP DNS servers. Potential risks include exposure to malicious websites, data interception, and susceptibility to DNS hijacking or spoofing attacks, leading to compromised privacy and security.
Your local computer caches DNS for a short while. But many features of the modern Web depend on dynamic variation. People start and stop server farms as load shifts, to save energy. “Sticky” DNS would make the Web flakey even when not being attacked.