{"id":19,"date":"2015-04-15T16:11:19","date_gmt":"2015-04-15T14:11:19","guid":{"rendered":"https:\/\/blog.unetresgrossebite.com\/?p=19"},"modified":"2015-04-16T13:39:53","modified_gmt":"2015-04-16T11:39:53","slug":"dns","status":"publish","type":"post","link":"https:\/\/blog.unetresgrossebite.com\/?p=19","title":{"rendered":"DNS"},"content":{"rendered":"

Wondering on wikipedia, we can learn in the early ages of the Internet, some guy at Stanford Research International maintained a file mapping alphanumeric hostnames to their numeric addresses on the ARPANET.
\nLater on, the first concepts were defined (RFC882<\/a> and RFC883<\/a>, then superseded by RFC1034<\/a> and RFC1035<\/a>), leading the the first implementation (bind, 1984).<\/p>\n

I’m not especially familiar with the history of a technology older than me, and yet DNS servers are one of the few cornerstones of networks, from your local network to Internet as we know it.
\nThe idea hasn’t changed since ARPANET: we prefer to use human-readable juxtaposed words, over a 4 digits identifier, to access a service. Thus, we’ve multiplied contributions to scale, redound, decentralize or secure a unified and standardized directory.<\/p>\n

While hosting your own DNS server could be pretty straight-forward, popular services are usually popular targets, with their flows. Taking care of defining the function that would implement your server is crucial, though usually overlooked.<\/p>\n

The most common attack targeting DNS servers is well known, exploiting poorly configured servers since over 10 years : amplification attacks.
\nAn attacker would spoof its IP to his victim’s one, querying for ? ANY isc.org (64b in), resulting in a ~3200b answer. Depending on UDP: no connection state. Spoofing only requires you to write your headers properly (without being able to answer some ACK), which makes any UDP protocol especially vulnerable.
\nAssuming your DNS server answer to such queries, our attacker would have amplified its traffic by 50, as well as hidden his address.
\nNote\u00a0while you may configure ACLs at software level, even a denied client would be answered to.\u00a0To avoid sending anything that may end up in a DDOS attempt, there’s nothing like a goodol’ firewall.<\/p>\n

While carrier-grade solution may involve reverse-route checking of inbound traffic, the only thing to do for us regular folks, is to restrict accesses to our DNS servers, to the very clients we know.
\nRenting servers in Dedibox and Leaseweb facilities, I’ve found out both management interfaces allow me to replicate my zones in their DNS servers. Thus, my split-horizon is configured to publicly announce Leaseweb and Dedibox’s NS as my masters, while these are the only public clients allowed to reach my masters.<\/p>\n

Bind \/ named<\/strong><\/p>\n

The historic implementation, most widely-spread. Its only concurrent in terms of features being PowerDNS.
\nBind implements what they call DLZ (Dynamically-Loadable Zones), allowing the storage of records in a database such as PostgreSQL or ODBC.
\nHaving tested the OpenLDAP connector for a few years, I’ld mostly complain about being forced to patch and build my own package (RFC3986, http:\/\/repository.unetresgrossebite.com\/sources\/dlz-ldap+r1-9.9.3-P2.patch), and being unable to resolve adresses containing characters such as ‘(‘. In the end, keeping my databases as plain file is easier to maintain.<\/p>\n

Its usages include authoritative zone serving, zone replication and caching, split-horizon, TSIG, IPv6 and wildcard records, records caching, DNS & DNSSEC resolution and recursion, lying DNS using RPZ, …<\/p>\n

see:<\/p>\n