Categories
Deploy360 DNS Privacy Domain Name System (DNS) Improving Technical Security Security

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions, and mentioned some of the protocols that have been recently developed to improve user privacy.

To complement this, we are publishing our DNS Privacy Frequently Asked Questions (FAQ). This highlights and provides answers to the most important aspects of DNS privacy.

Please also check our DNS Privacy page for more information!

Further Information

Categories
Deploy360 DNS Privacy Improving Technical Security

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map a human-friendly domain name to a set of IP addresses that can be used to deliver packets over the Internet. DNS transactions can therefore be correlated to the applications we use, the websites we visit, and sometimes even the people we communicate with.

While the domain name information itself is public, the transactions performed by the hosts are not. Unfortunately, the DNS does not inherently employ any mechanisms to provide confidentiality for these transactions, and the corresponding information can therefore easily be logged by the operators of DNS resolvers and name servers, as well as be eavesdropped by others.

So we are publishing our Introduction to DNS Privacy to raise awareness of the privacy implications of the DNS, and the mechanisms that have been recently developed to improve user privacy.

Please also check our DNS Privacy page for more information!

Further Information

Categories
Deploy360 Improving Technical Security IPv6 Security Security

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a different protocol! But we think years of IPv4 operational experience should be leveraged as much as possible.

So we are publishing IPv6 Security for IPv4 Engineers as a roadmap to IPv6 security that is specifically aimed at IPv4 engineers and operators.

Rather than describing IPv6 in an isolated manner, it aims to re-use as much of the existing IPv4 knowledge and experience as possible, by highlighting the security issues that affect both protocols in the same manner, and those that are new or different for the IPv6 protocol suite. Additionally, it discusses the security implications arising from the co-existence of the IPv6 and IPv4 protocols.

Be sure also to check our IPv6 Security page as well!

Further Information

Categories
Deploy360 Improving Technical Security IPv6

IPv6 Security Frequently Asked Questions (FAQ)

The Internet Society recognises that global deployment of the IPv6 protocol is paramount to accommodating the growth of the Internet. Given the scale at which IPv6 must be deployed, it is also important that the possible security implications of IPv6 are well understood and considered during the design and deployment of IPv6 networks, rather than as an afterthought.

We are therefore publishing our IPv6 Security Frequently Asked Questions (FAQ), which highlights and provides answers to the most important aspects of IPv6 security.

Be sure also to check our IPv6 Security page as well!

Further Information

Categories
Deploy360 IETF IPv6

How IPv6 SLAAC Responds to Renumbering Events

If you follow the IPv6 Maintenance (6man) Working Group of the Internet Engineering Task Force (IETF), you may have noticed the 300+ message email thread on an Internet Draft that was recently published on the “Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events”. This was prompted by the experiences of developing Best Current Operational Practice on IPv6 prefix assignment for end-users, an activity led by ISOC’s Jan Žorž and published as ripe-690.

SLAAC is used to automatically assign an IPv6 address to a host, but there are a number of scenario where hosts may end up using stale configuration information and thereby leading to interoperability problems.

For example, a typical IPv6 deployment scenario is when a CPE (Customer Premises Equipment) router requests an IPv6 prefix to an ISP via DHCPv6-PD, and advertises a sub-prefix of the leased prefix on the LAN-side via SLAAC.

In such scenarios, if the CPE router crashes and reboots, it may lose all information about the previously leased prefix. Upon reboot, the CPE router may be leased a new prefix that will result in a new sub-prefix being advertised on the LAN-side of the CPE router. As a result, hosts will normally configure addresses for the newly-advertised prefix, but will normally also keep (and use) the previously-configured (and now stale!) IPv6 addresses, leading to interoperability problems.

ripe-690 had tried to address this problem by recommending that operators lease stable IPv6 prefixes to CPE routers, but for various reasons, ISP may not be able or willing to do this, and may instead lease dynamic prefixes. In fact, a recent survey of ISPs indicates that 37% of the surveyed ISPs lease dynamic IPv6 prefixes to their customers, as opposed to the stable prefixes recommended by ripe-690.

Most of the input on the 6man mailing list fell into one of the following camps:

  • “ISPs should be leasing stable prefixes — if they don’t, they are asking for trouble!”
  • “CPE routers should record leased prefixes on stable storage, such that they can deprecate such prefixes upon restart — if they don’t, they are asking for trouble!”
  • “No matter whose fault is this (if there is any single party to blame in the first place), we should improve the robustness of IPv6 deployments”

This Internet Draft therefore tries to improve the current state of affairs through the following improvements:

  • Allow hosts to gracefully recover from stale network configuration information — i.e. detect and discard stale network configuration information.
  • Have SLAAC routers employ more appropriate timers, such that information is phased-out in a timelier manner; unless it is actively refreshed by Router Advertisement messages.
  • Specify the interaction between DHCPv6-PD and SLAAC — which was rather under-specified.
  • Require CPE routers to store leased prefixes on stable storage, and deprecate stale prefixes (if necessary) upon restart.

Based on the mailing list discussions, there would seem to be consensus this is a problem that needs to be addressed by the 6man Working Group.

The topic is therefore likely to be on the working group agenda at the IETF 104 Meeting at the end of this month in Prague, Czech Republic. So if you’re a network operator, vendor or otherwise have operational experience of this issue, you’re strongly encouraged to contribute to the discussion.

Further Information

Categories
Deploy360 Improving Technical Security Mutually Agreed Norms for Routing Security (MANRS) Securing Border Gateway Protocol (BGP)

RIRs Enhance Support for Routing Security

BGP hijacking and route leaks represent significant problems in the global Internet routing systems, along with source address spoofing. BGP hijacks are where allocated or unallocated address space is announced by entities who are not holders and are not authorized to use it.

The announcement of allocated address space often creates big news, such as when 53 route prefixes of Amazon were hijacked, but the announcement of unallocated address space (whether IPv4, IPv6 or AS numbers) which are also known as ‘bogons’ often does not generate much publicity as it does not cause immediate disruptions to service or business. With depletion of the IPv4 address space though, the announcement of bogons are on the rise with miscreants scraping the unallocated address space from all RIRs and abusing it.

Resource Public Key Infrastructure (RPKI) was therefore developed to try to solve these problems, and APNIC (the Routing Internet Registry for the Asia-Pacific region) recently announced it will honour the creation of AS0 ROA objects. They join ARIN, AfriNIC and the RIPE NCC in supporting AS0 ROA objects, with only LACNIC yet to implement this.

APNIC members can create AS0 ROAs for the prefixes they manage using the MyAPNIC platform.

So, what is the significance of AS0 ROAs? A quick overview of ROA is in order before explaining the importance of AS0 ROA. According to RFC6483:

A “route” is a unit of information that associates a set of destinations described by an IP address prefix with a set of attributes of a path to those destinations.

The Border Gateway Protocol (BGP) relies on the assumption that the Autonomous System (AS) that originates routes for a particular prefix, is authorized to do so by the holder of that prefix. A Route Origination Authorization (ROA) is used to verifiably assert that the holder of IP address space is authorized to originate routes from a given set of prefixes.

A ROA identifies a single AS that has been authorized by the address space holder to originate routes, and provides a list of one or more IP address prefixes that will be advertised. If the address space holder needs to authorize multiple ASes to advertise the same set of address prefixes, the holder issues multiple ROAs, one per AS number.

The information in the ROAs can be used by networks using BGPto perform Route Origin Validation (ROV) on incoming BGP advertisements. ROV allows BGP speakers to determine if they should accept the routes being advertised to them as real, and is based on the state of a received announcement which can be Valid, NotFound, or Invalid.

  • Valid – The announcement is covered by at least one ROA
  • NotFound – The announcement is not covered by any ROA
  • Invalid – Announcement that contradicts ROA information. It can be an AS of unauthorised origin AS, or that the announcement is more specific than is allowed by the maximum length set even if it originates from a valid AS number.

What must be remembered is that RPKI validation relies on the availability of RPKI data, and therefore RPKI caches should be located close to routers that require this data (we are not going to discuss Relying Party-RP or RTR Protocol here).

Up until September 2012, AS0 was listed in the IANA Autonomous System Number Registry as “Reserved – May be used to identifying non-routed networks”. This status was updated with RFC7607 which redefined AS0 in line with RFC6491 “Resource Public Key Infrastructure (RPKI) Objects Issued by IANA”:

AS0 ROA: A ROA containing a value of 0 in the ASID field. “Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origination Authorizations (ROAs)”

Whereas, RFC6483 defines the term “Disavowal of Routing Origination”.

“A ROA is a positive attestation that a prefix holder has authorized an AS to originate a route for this prefix into the inter-domain routing system.  It is possible for a prefix holder to construct an authorization where no valid AS has been granted any such authority to originate a route for an address prefix.  This is achieved by using a ROA where the ROA’s subject AS is one that must not be used in any routing context.  Specifically, AS0 is reserved by the IANA such that it may be used to identify non-routed networks

A ROA with a subject of AS0 (AS0 ROA) is an attestation by the holder of a prefix that the prefix described in the ROA, and any more specific prefix, should not be used in a routing context. The route validation procedure will provide a “valid” outcome if any ROA matches the address prefix and origin AS even if other valid ROAs would provide an “invalid” validation outcome if used in isolation.  Consequently, an AS0 ROA has a lower relative preference than any other ROA that has a routable AS, as its subject.  This allows a prefix holder to use an AS0 ROA to declare a default condition that any route that is equal to or more specific than the prefix to be considered “invalid”, while also allowing other concurrently issued ROAs to describe valid origination authorizations for more specific prefixes.”

This means that AS0 in a ROA can be used to mark a prefix and all its more specific prefixes as Invalid and not to be used in a routing context. By publishing a ROA that lists AS0 as the only origin, it allows a resource holder to signal that a prefix (including its more specific prefixes) should not be routed. In other words, a BGP speaker should not accept or propagate routes containing AS0.

RFC7607 codifies the BGP speaker behaviour to handle AS0.

“A BGP speaker MUST NOT originate or propagate a route with an AS number of zero in the AS_PATH, AS4_PATH, AGGREGATOR, or AS4_AGGREGATOR attributes. 

An UPDATE message that contains the AS number of zero in the AS_PATH or AGGREGATOR attribute MUST be considered as malformed and be handled by the procedures specified in RFC7606 “treat-as-withdraw”

An UPDATE message that contains the AS number of zero in the AS4_PATH or AS4_AGGREGATOR attribute MUST be considered as malformed and be handled by the procedures specified in RFC6793 “attribute discard”

If a BGP speaker receives zero as the peer AS in an OPEN message, it MUST abort the connection and send a NOTIFICATION with Error Code “OPEN Message Error” and subcode “Bad Peer AS” (see Section 6 of RFC4271).  A router MUST NOT initiate a connection claiming to be AS0.”

Returning to RFC6491, this ‘Recommends’ that IANA issue an AS0 ROA for all reserved IPv4 and IPv6 resources not intended to be routed, to all Unallocated Resources – namely Resources that have not yet been allocated for special purposes to Regional Internet Registries (RIRs) – or to other resources that are not intended to be globally routed.

This measure can greatly enhance the effectiveness of RPKI and routing security in general, but network operators should also take a look at the MANRS initiative – which is supported by the Internet Society. This specifies additional actions including filtering, anti-spoofing, coordination, as well as support for global validation mechanisms such as RPKI and currently encompasses over 200 Autonomous Systems around the world, including some of the largest ISPs.

If you’re a network operator or IXP, then please see how you can help contribute towards improving the security and resilience of the global routing system.

Further Information

Categories
Deploy360 DNS Privacy Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC) IPv6

DNS Privacy & IPv6 Security @ APTLD 75

The Internet Society will be actively contributing to the APTLD 75 meeting on 20-21 February 2019 in Dubai, United Arab Emirates.

Our colleague Jan Žorž will not only be presenting on DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH) during the DNS Operations, Security, and Privacy session (20 February, 11.30-12.30 UTC+4), but will then be presenting on IPv6 connectivity issues during the Security in IPv6-enabled TLDs session (20 February, 14.30-15.30 UTC+4).

He’ll be in good company in what’s shaping up to be a great programme featuring a number of DNS luminaries covering technical, policy, internationalisation and data protection issues, as well as abuse handling and registry and registrar training. Other sessions of particular interest include 5G mobile networks, the implications of Alternative DNS Root Servers, and emerging trends in the DNS.

The Asia-Pacific Top-Level Domain (APTLD) Association is a non-profit organisation of ccTLD (Country Code Top-Level Domains) registries in the Asia-Pacific region that was founded in 1998. It organises two meetings each year for its members, with APTLD 75 being held in conjunction with the 6th Middle East DNS Forum.

If you’re interested in attending then you can register at http://www.aptld75.ae/reg/end.php

Further Information

Categories
Deploy360 Improving Technical Security IPv6

NAT64Check Version 2 is launched!

With the New Year comes the launch of NAT64Check version 2 from the Internet Society. The first version of NAT64Check was introduced a couple of years ago and has proved very popular and successful, so for the past year we’ve been working on a number of enhancements in response to feedback and requests. And we’re very happy to be able to make the new version available as we welcome in 2019.

NAT64Check is a tool developed by the Internet Society in collaboration with Stichting IPv6 NederlandGo6, SJM Steffann, Internetbureau Max and Simply Understand. This allows you to enter the URL of a particular website, and then run tests over IPv4, IPv6 and NAT64 in order to check whether the website is actually reachable in each case, whether identical web pages are returned, and whether all the resources such as images, stylesheets and scripts load correctly. It also compares responsiveness using the different protocols, therefore  allowing network and system administrators to easily identify anything is ‘broken’, to pinpoint where any non-IPv6 compatible elements need to be fixed.

The original version of NAT64Check though, ran on two separate servers at Go6 and the IPv6 Lab which each had a limited view of the Internet from a topological perspective, and did not allow results to be easily aggregated. This was because it was put together quickly as a proof-of-concept using scripting tools, but its popularity encouraged us to develop something that was more scalable and adaptable for the future.

Version 2 therefore introduces a distributed concept that allows for different test locations, and indeed allows people to easily install their own test instances. However, results can be aggregated from any or all of these test locations and queried via a central web interface. Other improvements include better error detection and feedback when problems are experienced with particular sites, and as well as extendability for additional tests.

The new modular based design is based around three core elements. Marvin is a module based on Chromium that can run as separate instances on servers in different geographical locations for testing services over IPv4, IPv6 and NAT64. Trillian is a module that can collect, compare and output these test results based on different user profiles, whilst the Zaphod module undertakes the aggregation and provides the centralised web interface. Students of “The Hitchhiker’s Guide to the Galaxy” will of course recognise from where the codenames were derived!

The tool is very easy to use – simply go to https://www.nat64check.org, type the URL you wish to check into the box at the top of the page, and the result should be returned within a few seconds. It’s simple and easy, and will help you identify what needs to be done to make your website accessible with IPv6.

We’re also calling out for volunteers to help improve the usefulness of this tool by installing their own test instances. This requires a KVM, a VM running Ubuntu 18.04, a login, sudoers file, separate IPv4 and IPv6 addresses and a static /64 routed to the VM.

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

Acknowledgements

NAT64Check was developed by our colleague Jan Žorž, Sander Steffann, Corinne Pritchard, Max Dammers, and Musa Stephen Honlue.

Categories
Deploy360 Domain Name System (DNS) Improving Technical Security

DNS-over-TLS in Linux (systemd)

Whilst we were putting together some content about DNS privacy recently, we learned that recent distributions of Linux ship with support for making DNS queries over TLS. We therefore decided to give Ubuntu 18.10 a try on a laptop.

More recent versions of Ubuntu employ a special service for name resolution called ‘system-resolved.service(8)’. The configuration file ‘resolved.conf(5)’ specifies most of the details for name resolution, including which protocols and resolvers should be employed, whilst the ‘/etc/systemd/network/*.network’ configuration files (see ‘systemd.network(5)’ for details) of the ‘systemd-networkd.service(8)’ specify any per-link specific settings.

The default configuration of ‘systemd-resolved’ is selected at compile time, and ‘/etc/systemd/resolved.conf’ normally contains commented-out lines describing such defaults. For example, the contents of the aforementioned file on a fresh Ubuntu 18.10 installation are:

As may be inferred from the file, DNS-over-TLS (DoT) is supported, but disabled by default. At the time of  writing, only opportunistic DoT is supported according to the manual, which means that the resolver will first try resolution using DoT before falling back to traditional DNS in the event of failure – thus allowing for downgrade attacks where an attacker intentionally causes a DoT failure in order to cause name resolution to downgrade to traditional DNS.

We decided to give DoT at try by changing three configuration variables in ‘/etc/systemd/resolved.conf’:

  • Set ‘DNS’ to the IP address of the DoT server
  • Set ‘DNSOverTLS’ to ‘opportunistic’
  • Set ‘Domains’ to ‘~.’

The ‘DNS’ variable contains the list of IP addresses that correspond to the DoT recursive resolver (you can find a list of public recursive resolvers here).

Setting ‘DNSOverTLS’ to ‘opportunistic’ enables DoT in opportunistic mode – this means that DoT will be employed if possible, but the stub resolver will fall back to traditional DNS if it fails.

Finally, setting ‘Domains’ to ‘~.’ instructs ‘systemd-resolved’ to prefer the specified nameserver over any per-link DNS server that may be available. This is an important setting as otherwise a non-DoT per-link DNS resolver could take precedence over the DoT resolver.

Our resulting configuration therefore becomes:

Once these changes have been applied, you need to make them take effect by executing the command:

sudo systemctl restart systemd-resolved

With this done, we then decided to double-check that DoT rather than traditional DNS was being employed. So we simply ran a sniffer on the Ubuntu laptop, and did a DNS query for ‘fgont.go6lab.si’ which revealed:

Our query generated both traditional DNS and DoT traffic in parallel. In fact, when we later ran a sniffer on the authoritative nameserver itself, it confirmed that both the local resolver on our network (192.168.3.1) and Cloud-flare’s resolver were issuing queries for the above domain.

In response to this finding, we tried to figure out why we were seeing traditional DNS traffic in parallel, instead of just DoT traffic, or at least DoT traffic followed by traditional DNS traffic on the assumption that DoT failed? In addition, why was the local resolver being employed for DNS resolution even when the ‘Domains’ variable instructs ‘systemd-resolved’ to employ the specified DoT resolver over any other resolver.

It would seem that the ‘systemd-resolved’ implementation for opportunistic DoT does not employ traditional DNS only as a result of DoT failures, but rather in parallel to DoT queries. On the other hand, a discussion on the GitHub repository for ‘systemd’ notes that the documentation for the ‘Domains’ variable is actually incorrect and simply specifies that the DoT resolver should be employed for domains matching the specified suffix (“.”, in our case), which does not mean this resolver should be the only one employed for resolving matching domains.

Conclusion

Based on the tests we’ve carried out, we can only conclude that there is a flaw in the DoT implementation of ‘systemd-resolved’. Quite clearly using a DoT resolver only makes sense if DNS queries are sent exclusively over an encrypted channel, or at the very least, traditional DNS is only employed in response to DoT failures (and possibly after acknowledgment from the user that traditional DNS should be employed).

We therefore currently recommend that if DoT needs to be employed, alternative implementations such as Stubby should be used until this issue is resolved with ‘systemd’.

Acknowledgements

We would like to thank Sara Dickinson for her help in debugging these issues.

Further Information

Categories
Deploy360 Domain Name System (DNS) Improving Technical Security

DNS-over-HTTPS (DoH) Support in Mozilla Firefox

Recent releases of Firefox have introduced the concept of DNS privacy under the name “Trusted Recursive Resolver”. Although Firefox ships with DNS-over-HTTPS (DoH) disabled by default, there has been some discussion within the Mozilla developer community about changing the default to “enabled”.

Although DoH is somewhat controversial because it moves control plane (signalling) messages to the data plane (data forwarding), and can thereby bypass local network policies, DoH advocates argue that it makes it harder to block or monitor DNS queries which is a commonly used method for restricting access to the Internet and/or monitoring user behaviour.

But putting these arguments aside, if you want to try out DoH then the DNS privacy (or “TRR” in Firefox speak) configuration in Firefox can be accessed as follows:

  • Enter “about:config” in the address box of the browser
  • Search for “trr” (without quotes)

A sample output of DNS privacy configuration in Mozilla Firefox is as follows:

Firefox offers its technical users quite a few settings to play with, but the most important options (along with their recommended settings) for TRR are:

“network.trr.bootstrapAddress” specifies the IP address of a recursive resolver that should be employed to obtain the address of the DoH resolver specified using the “network.trr.uri” variable.

For modes other than “3”, Firefox will employ any DNS servers learned from DHCP. However, when mode “3” is selected, queries are not sent by default to any non-DoH resolver, and hence it is necessary to specify the address of a DNS resolver to be able to “bootstrap” DNS privacy.

Setting network.trr.mode to “3” sets “strict” resolution – meaning only DoH will be employed, with no fall back mechanism. This is a sensible option, since it prevents downgrade attacks.

Finally, network.trr.uri allows the selection of a DoH server/resolver.

The resulting configuration is:

In order to check whether TRR has been successfully enabled, it’s possible to use a protocol analyzer, as follows:

  • Check the network for traditional DNS traffic – this means packets destined for TCP port 53 or UDP port 53. If DoH has been successfully enabled, you should see no traffic from the local node to those ports
  • Check the network for DoH traffic – that means packets destined for TCP port 443 of the IP address(es) corresponding to the DoH resolver in the “network.trr.uri” variable. If DoH has been successfully enabled, you should probably see traffic to this port.

A more interesting way of checking the status of TRR is to employ the Firefox’ “about:networking”  experimental interface. This allows access to internal networking-related features, and can be accessed by entering the aforementioned string (without quotes) in the address box – with the DNS cache being directly available at “about:networking#dns”.

The following figure shows a sample output of the DNS cache:

The first column contains the list of cached domain names, while the second column indicates the protocol family employed (IPv4, in all of our domain names). The third column specifies whether TRR (DoH) was employed for DNS resolution, as if it has been enabled on the browser since we ran it, all of the entries in the DNS cache should have the third column set to “true”.

The fourth column specifies the addresses resulting from DNS resolution, while the fifth column specifies the current “time-to-live” of each entry (in seconds) before the entry is purged from the cache.

Firefox TRR Configuration variables

Whilst we only need to set three configuration variables to enable TRR, Firefox offers a range of other options for tuning it:

  • trr.allow-rfc1918: false (boolean)
    • Firefox will only allow RFC1981 addresses in TRR responses if this flag is set to “true”
  • trr.blacklist-duration: 60
    • Number of seconds a domain will be kept in a “blacklist” when resolution does not work with TRR, but works with a normal resolver.
  • trr.bootstrapAddress:
    • Address of a recursive resolver to obtain the address of the server specified in “network.trr.uri”
  • trr.confirmationNS: example.com
    • Firefox will try to do DNS resolution to check that TRR is working properly
  • trr.credentials:
    • Credentials to be used in the “Authorization” request header
  • trr.disable-ECS: true (boolean)
    • Disable sending EDNS Client Subnet (ECS) information to authoritative servers.
  • trr.early-AAAA: true (boolean)
    • Firefox normally sends both A and AAAA queries in paralell. It will only use AAAA records if they arrive first and this flag is set to true
  • trr.max-fails:
    • Number of times after which Firefox should give up on TRR resolution for a given domain name
  • trr.mode: 0
    • 0: Off – use normal resolver and don’t use TRR
    • 1: Race – do TRR and normal resolution in parallel, and use whatever answer comes first
    • 2: First – use TRR, and fall back to normal resolver if it fails
    • 3: Only – Only use TRR, and never use normal resolver (after initial setup)
    • 4: Shadow – Do TRR in parallel with normal resolver (for measurements) but only use results from normal resolver5: Off by choice – same as “0”, but represents explicit decision to disable TRR
  • trr.request-timeout: 3000
    • Time value in seconds after which a TRR query is considered to have failed
  • trr.uri: https://mozilla.cloudflare-dns.com/dns-query
    • URI to be employed for DNS resolution
  • trr.useGET: false (boolean)
    • Whether to use GET rather than POST method.
  • trr.wait-for-portal: true (boolean)
    • Whether to wait for captive portal detection before using DoT

 

Further Information

Categories
Deploy360 Domain Name System (DNS) IETF

DNS Security & Privacy discussed at e-AGE18

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

Categories
Building Trust Deploy360 Events IETF Internet of Things (IoT) IPv6 Transport Layer Security (TLS)

IETF 103, Day 4: Trusted Systems, IoT & IPv6

This week is IETF 103 in Bangkok, Thailand, and we’re bringing you daily blog posts highlighting the topics of interest to us in the ISOC Internet Technology Team. Thursday actually represents the last day of the meeting this time, although there’s still several sessions to draw attention to.

SUIT is meeting first thing at 09.00 UTC+9. This is considering how the firmware of IoT devices can securely updated, and the architecture and information models for this will be discussed. There are three other drafts relating to manifest formats that are the meta-data describing the firmware images.


NOTE: If you are unable to attend IETF 103 in person, there are multiple ways to participate remotely.


DMM is the first of the afternoon sessions at 13.50 UTC+7, and there are several IPv6-related drafts under consideration. Proxy Mobile IPv6 extensions for Distributed Mobility Management proposes a solution whereby mobility sessions are anchored at the last IP hop router, whilst Segment Routing IPv6 for Mobile User Plane defines segment routing behaviour and applicability to the mobile user plane behaviour and defines the functions for that. There’s also three updated drafts on 5G implementations which may interest some.

To round off the week, there’s a choice of two sessions starting at 16.10 UTC+7.

ACME will be focusing on the ACME TLS ALPN extension that allows for domain control validation using TLS, and Support for Short-Term, Automatically-Renewed (STAR) Certificates. It will also consider how ACME can support TLS certificates for end-users.

Alternatively, 6TiSCH will be focusing on the specification for a combining a high speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel hopping (TSCH). The 6top protocol that enables distributed scheduling is now heading for publication as an RFC, and there are also updates to the description of a scheduling function that defines the behavior of a node when joining a network and to define a security framework for joining a 6TiSCH network. If there’s time, a method to protect network nodes against a selective jamming attack will be discussed.

With that, IETF 103 comes to a close and we say Sà-wàd-dee to Bangkok. Many thanks for reading along this week… please do read our other IETF 103-related posts … and we’ll see you at IETF 104 which is being on 23-29 March 2019 in Prague, Czech Republic.

Relevant Working Groups