Donate
DNS Security & Privacy discussed at e-AGE18 Thumbnail
‹ Back
Deploy360 24 December 2018

DNS Security & Privacy discussed at e-AGE18

Kevin Meynell
By Kevin MeynellManager, Technical and Operational Engagements

The Internet Society continued its engagement with Middle East networking community by participating in the e-AGE18 Conference, where we took the opportunity to promote the importance of DNS Security and Privacy. The conference was held on 2-3 December 2018 at the Marriott Hotel in Amman, Jordan and was organised by the Arab States Research and Education Network (ASREN) and co-sponsored by the Internet Society.

Kevin Meynell from the Internet Society’s Middle East Bureau, highlighted the importance of implementing DNSSEC which allows DNS resolvers to authenticate the origin of data in the DNS through a verifiable chain-of-trust. This reduces the possibility of spoofing where incorrect or corrupt data is introduced into a resolver, or a man-in-the-middle attack whereby DNS queries are re-directed to a name server returning forged responses.

Unfortunately, only the Saudi Arabia ccTLD (.sa) has operationally deployed DNSSEC in the Middle East region at the present time, although Iran (.ir) and Iraq (.iq) have deployed it on an experimental basis. On the positive side, around 18% of DNS queries originated from Middle East countries are being validated compared to 12% globally, with Yemen (45.1%), Saudi Arabia (32.1%), Iraq (30.6%), Bahrain (23.2%) and Palestine (22.5%) leading the way. This is possibly because there is a greater prevalence of the use of third-party DNS resolvers (e.g. Cloudflare, Google, Quad9 in the region.

Of course, whilst DNSSEC ensures that DNS records have not been modified without the owner’s consent, it does not keep the queries themselves confidential. DNS queries reveal what site a host is communicating with, and as they are (by default) sent in clear text, they can easily be eavesdropped.

The IETF DNS Private Exchange (DPRIVE) Working Group has therefore recently developed mechanisms to encrypt queries and responses to/from resolvers and therefore provide some confidentiality of DNS transactions. These include DNS-over-TLS (DoT), DNS-over-DTLS (DoD) and DNS-over-HTTPS (DoH), and with the exception of DoD, there are already several public DNS resolvers (Cloudflare, Quad9 & CleanBrowsing) and a few clients (Stubby 1.3+, Unbound 1.6.7+, Knot 2.0+, Mozilla Firefox 62+ and Android 9 Pie) that support these mechanisms.

It should be pointed out that clients and resolvers need to be upgraded to support DoT and DoH, and all these mechanisms currently only encrypt DNS communications between client (stub-resolver) and recursive resolver, not between recursive resolver and authoritative DNS servers. Support for the latter would require all authoritative DNS servers to be upgraded to support DoT and DoH, and there are concerns about the increased computing requirements that would required on the more heavily name servers to initiate the encrypted connections.

In addition, providers of the recursive resolver are in the position to monitor and log queries and responses, so need to be trusted. Nevertheless, these are important developments towards improving the security and confidentiality of the DNS.

Last but certainly not least, attention was drawn to DNS Flag Day which is important to be aware of. DNSSEC and other extended features of the DNS require EDNS0 (Extension Mechanisms for DNS – RFC 6891), and properly implemented name servers should either reply with an EDNS0 compliant response, or provide a regular DNS response if they don’t understand.

However, a lot of name server software is not implemented properly which has meant resolvers have had to incorporate workarounds when name servers don’t respond correctly, but these cause unnecessary retries, delays, and prevent the newer features of the DNS being used. The vendors of the most commonly used DNS software (BIND, Ubound, PowerDNS and Knot) are therefore removing these workarounds as of 1 February 2019, with the consequence is that hostnames served by broken DNS implementations will no longer be resolved. So please check whether your domain is affected!

ASREN is a non-profit association of National Research and Education Networks in the Middle East that aims to connect institutes to enable access to services, applications and computing resources within the region and around the world, and to boost scientific research and cooperation amongst its members. Its mandate covers 22 countries, and it has partnered with the major regional R&E networking initiatives elsewhere in the world, including GÉANT (Europe), Internet2 (United States), CANARIE (Canada), WACREN (West Africa) and RedCLARA (Latin America). International connectivity is supported by the EU-funded EUMEDConnect3 project.

Deploy360 can also help you deploy DNSSEC, so please take a look at our Start Here page to learn more.

Further Information

‹ Back

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

CircleID: DNS Security Should Be One Of Your Priorities (including DNSSEC)
Deploy36016 January 2014

CircleID: DNS Security Should Be One Of Your Priorities (including DNSSEC)

We were very pleased to see this recent post over at the CircleID site, "Domain Name System (DNS) Security Should...

Rough Guide to IETF 103: DNSSEC, DNS Security and DNS Privacy
Rough Guide to IETF 103: DNSSEC, DNS Security and DNS Privacy
Domain Name System Security Extensions (DNSSEC)2 November 2018

Rough Guide to IETF 103: DNSSEC, DNS Security and DNS Privacy

As happened earlier this year at IETF 102 in Montreal, DNS privacy will receive a large focus in the DNSOP,...

Fedora 21 To Have DNSSEC Validation Enabled By Default
Deploy3602 May 2014

Fedora 21 To Have DNSSEC Validation Enabled By Default

By way of a recent tweet from Red Hat's Paul Wouters we learned the great news that the next release...

Join the conversation with Internet Society members around the world