**This is a very rough draft. I will be editing it again tomorrow, and likely be moving much of the content to other pages** ==== Load Distribution, DNS Caching & Remote Resolvers ==== The DNS System can be a choke point of the internet. October 21st 2016 Marked what some sites (e.g. zednet [1] & teckcruch [2]) called the largest DoS attack in History. It exposed to a much wider audience than tech enthusiasts -- which were already away of the risks -- the security risks in the internet of things and how they could be leveraged for a distributed denial of service attack. The poor security of these devices makes them vulnerable to malware (such as the Mirai Malware, involved in the Oct 2016 attack) and these devices are often difficult to patch with security updates. Moreover, the malware could exploit intentional back doors, which could possibly be built into in the devicefor corporate or government espionage (Note I). DNS servers are necessary to find the IP Address of the service that you are trying to reach. If you already know the destination IP address then an external party doing a DoS attack on an DNS server will not inhibit your communication with the host that you are trying to reach. One way a machine may already know the destination IP Address is if is is using a local DNS caching application, typically IP Address are also cached in the router. Another way a machine may know an IP address, is if someone has hard coded the IP Address into the host file. The standard order of precedence of DNS Resolving is: %%specified>Cached>local machine(HOSTS)> network card> router > isp > dns server > and on.%% http://murga-linux.com/puppy/viewtopic.php?p=922756&search_id=1651434513#922756 === DNS Caching & DNSCrypt === DNSCrypt is not a DNS caching application but the remote resolver that it connects to will likely be caching DNS addresses. You can speed up DNSCrypt by running a DNS Caching resolver on your local computer. === Load Balancing === DNS Caching works while when the TTL (time to life) of a DNS record is long enough that it will be looked up many times before the DNS record expires. Static sites, which have a single ip address for connecting to the server can have long TTL periods. However, when connection traffic [Note II] to a site exceeds the amount that can be handled by a single server then the static IP approach becomes unfeasible. Assuming that the client only knows one address for the service (Note III) an alternative approach to load balancing is to use the DNS System to do the load balancing. Different clients connecting to the same site will receive different IP Addresses for connecting to the site. These IP Addresses will be based on server load and geographic location. If A DNS resolver obtains an IP address it can reduce the load on the DNS server if many people-loop up the address via the DNS remote resolver before the DNS record expires. This shifting of load away from the DNS server and related increase in redundancy can help add robustness to the DNS System. === TTL Periods & CDNs=== Aside from DNS load balancing across several servers from the same site, a site my use external servers such as CDNs (Content Deliver Networks) to deliver parts of the sites content to clients. These services may have short TTLs if either the content is dynamic or if several different sites share servers to deliver their sites content. === TTL Periods & Dynamic IP assignment === Another obstacle to caching IP addresses is dynamic IP assignment. This is partly motivated by the limited number of addresses in IPv4. IPv6 will for the time being solve the address limitation problem and restore the "end point principle" of the internet. === Other Reasons for short TTL Periods === Other reasons for short TTL periods include include the requirements of a disaster recovery system and the prevention of censorship. Rotating the address of a server means that it is difficult to block the server based on IP Address. One might take such approach if they are serving spam, trying to get around geo-fencing (e.g. blocking people from using American Netflix) or trying to distribute illicit content. === Persistent DNS Caching === Persistent DNS Caching keeps cached DNS addresses around longer then a typical DNS Caching Resolver. For instance the DNS Cache is not cleared after a re-boot and also a minimum TTL maybe be set in the DNS Caching resolver that is longer then the TTL of the DNS record. pdnsd is one such application. pdnsd can be configured to be used with DNSCrypt. Information about this is available on arch wiki: https://wiki.archlinux.org/index.php/pdnsd#DNSCrypt == Further Reading == https://en.wikipedia.org/wiki/October_2016_Dyn_cyberattack https://en.wikipedia.org/wiki/Mirai_(malware) === Pet Download and Forum Thread === The most recent version of the DNSCrypt pet is available in the following thread: http://murga-linux.com/puppy/viewtopic.php?t=101068 == Notes == I. To what extent devices have deliberate backdoors is difficult to know but their are well, known cases (e.g. superfish) II. In server side load balancing a server listens to a port for external clients and then forwards the request to a backend server which replies to the request. (Wikipedia: Loadbalancing_(Computing)#Server-Side_Load_Balancing [[https://en.wikipedia.org/w/index.php?title=Load_balancing_(computing)&oldid=745387168#Server-Side_Load_Balancers|20 Oct 2016]]) III. If more than one address is known for a site then Load balancing could be done on the client side. Typical though a DNS server returns one ip address for a given serve to each client. == References == 1 - http://www.zdnet.com/article/the-dyn-report-what-we-know-so-far-about-the-worlds-biggest-ddos-attack/ 2 - https://techcrunch.com/2016/10/21/many-sites-including-twitter-and-spotify-suffering-outage/ ---- ==Categories== CategoryNetworking CategoryDNS