|
Getting your Trinity Audio player ready...
|
 |
With cloud service options frantically “pumping” for almost everything we have in IT, and other services, it's easy to choose any service and simply click START and start using.
As good professionals, we know that behind this “START” there are a lot of things to make this simple deployment start working, but a resource that is widely used, even more so today, ends up being left out because it is so simple that some forget, the name resolution service, also known as DNS.
Probably 99% of what you use both on the internet and “at home” is solved by name, this blog for example, you arrived here by name address, you can't access it via IP, your email service, any website, that address in the SQL listener, etc.
Even though it is a simple UDP request on port 53, this request generates internet traffic, for every time someone checks an address, a whole magic has to happen, basically it's like this:
The application request is forwarded to the SOThis request passes to the network mini-driver and searches the cache to find out if there is anything in the cache to advance the service, if it does not have it... get the list of DNS addresses registered on the interfacerequests the registered DNS to resolve the name for the requested addressIf the registered servers have the address cached it returns it to the requester if not, ,Go to the registered Root's to start the public consultation, everything starts with the “.” then the suffix that can be “com”, “net”, “br”, “ca”, etc... Then find the intermediate name of the domain, which is the name itself, and solves the DNS master and slave and connects to the master and slave DNS and solves the SOASasks about the RR of the address in question and then the answer may vary to an A, MX, AAA, TXT, CNAME, etc.returns with the result to the DNS server registered there on the interface, caches it by TTL, and returns the name resolution to the requesting interface with the registry TTL
Basically, because it's a little more complex than that, this is the process done for each time a name resolution is requested, all in UDP and as quickly as possible.
And what does RFC 8482 have to do with it?
By default, when a DNS query is made this method is direct, an RR for a domain and that's all, but there is a query method that is ANY that basically means a bring all the available information from the requested domain.
This “all information” consists of:
Server names: DNSSerialRefresh of the Retryzone TTL expirationsResponder email name of the primary response server MXText the response IP to root
Okay, but what's the problem?
The volume travelled is larger, the DNS connection time is longer and the volume of requests can affect performance in the experience. To give DNS request time out, the service can take up to 2 seconds to resolve the address, imagine this for an application where the total time spent 2 seconds was only to solve name, where she will have to try again because there was a time-out.
There is an attack method that is DNS amplification, where a wave of ANY request overloads the service causing a DDoS and no DNS without application.
At the tip of the pencil we are talking about a direct request requesting something around 44 bytes, while an ANY request (may vary) but for an average tip at 890 bytes.
Doesn't seem like much right? now imagine that for a DNS server responding not only to your requests but to all the domains registered on it, more replicating to a secondary one, more updates coming from applications.
How to avoid ANY requests?
Basically, add an RR to the HINFO type DNS with some information.
E.g. HINFO RFC8482
who does that?
WikiPedia, CloudFront
