Mutually Agreed Norms for Routing Security (MANRS) Strengthening the Internet

Over 300 ISPs Now Improving Routing Security with MANRS

Today, we’re proud to announce another milestone: the number of network operators that commit to the Mutually Agreed Norms for Routing Security (MANRS) has surpassed 300.

The current number of network operator program participants stands at 322. These Internet Service Providers (ISPs) joined the initiative by showing their conformance with the actions to improve the resilience and security of the Internet’s routing infrastructure.

Launched in 2014 with a group of nine operators, the number of MANRS participants reached 100 in 2018 and has risen rapidly in the last two years, with 156 joining in 2019 alone, and 45 so far in 2020.

This includes operators in more than 60 countries across all continents; with Brazil leading the way with nearly 70 MANRS participants, followed by the US with nearly 50.

According to BGPStream, the number of reported routing incidents was on the decrease from 2017 to 2019 (see chart below), while the number of MANRS participants grew in the period. While this does not mean one caused the other, a correlation between the two can be observed.

The MANRS community has grown rapidly through its other programs, too. In 2018, the initiative expanded to include Internet Exchange Providers (IXPs), which now has 48 participants committed to the MANRS IXP Programme.

Last month, the MANRS Content Delivery Network (CDN) and Cloud Provider programme was launched with eight leading companies, including Akamai, Amazon Web Services, Azion, Cloudflare, Facebook, Google, Microsoft, and Netflix, with a number of other companies onboarding soon.

The three programs each have their own set of actions that are based on industry best practices, being developed and approved by community-driven task forces. Together, this growing community has taken concrete actions to secure more of the global Internet.

Awareness of MANRS and routing security in general has also been increasing in the wider world. In January 2020, a World Economic Forum (WEF) report recommended that ISPs should strongly consider joining MANRS to improve the security of the Internet’s global routing system.

MANRS shows that when the community comes together to create a baseline of routing security for network operators around the world, we can protect the core of the Internet. The growth of the community also shows there is an increasing sense of shared responsibility among network operators. Whilst no single operator can improve the Internet’s routing security alone, it is through collective actions like MANRS that progress is made.

Looking ahead, we aim to continue growing community adoption of MANRS by mobilizing other external communities with an awareness of MANRS, by improving monitoring and measurement of routing security, and by building capacity among network engineers around the world.

Whether you run an ISP, IXP, CDN or cloud network, please join the growing MANRS community to protect the Internet ecosystem together by signing up online.

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

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

Developing Good BGP Neighbour Relationships @ APRICOT 2019

Routing Security is featuring heavily on the APRICOT 2019 programme, which is being held on 23-28 February 2019 in Daejeon, South Korea. This helps build on the MANRS initiative being supported by the Internet Society,

On Wednesday, 27 February (09.30-13.00 UTC+9) there will be a Routing Security session that will discuss the latest problems, developments, and how routing security measures can be implemented. Speakers include Job Snijders (NTT) who’ll be discussing changes to BGP in the coming 18 months; Töma Gavrichenkov (Qrator Labs) on how BGP hijacks can be used to compromise the digital certificates used to secure online transactions; and from Anurag Bhatia (Hurricane Electric) who’ll analyse the top misused ASNs.

During the second part of the session, Tashi Puntsho (APNIC) will cover the practical issues and implications of deploying your own RPKI Certificate Authority; Tim Bruijnzeels (NLnet Labs) will discuss the use of route servers at Internet Exchange Points; whilst Ed Lewis (ICANN) will discuss the issues with using the RIR Whois databases.

Following on from this, our colleague Andrei Robachevsky will be raising awareness of the MANRS Initiative during the FIRST Technical Colloquium (16.30-18.00 UTC+9).

FIRST is the global organisation of Computer Security and Incident Teams (CSIRTs) which are often in the front line when network security incidents occur, but are also involved in implementing preventative measures and capacity building. MANRS therefore considers CSIRTs to be important partners in improving the security and resilience of the global routing system, as well as providing input and feedback on the MANRS Observatory that is being developed to provide analysis of the state of the security and resilience of the routing system.

The Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) is the largest international Internet conference in the region, drawing network engineers, operators, researchers, service providers, users and policy communities from over 50 countries to teach, present, and develop relationships. Other Asia-Pacific networking organisations also use the opportunity to meet, in order to share knowledge required to operate the Internet.

If you’re interested in attending then it’s still possible to register at

Alternatively, if you’re unable to make it in person, then the sessions can be followed via webcast.

Further Information

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

Further Information

Domain Name System (DNS) Domain Name System Security Extensions (DNSSEC)

DNS Flag Day

The 1st of February was DNS Flag Day, which is an initiative of several DNS vendors and operators to address the problems of DNS name server implementations that are not in compliance with long-established DNS standards. This is causing the DNS to not only be unnecessarily slow and inefficient, but prevent operators from deploying new functionality including mechanisms to protect against DDoS attacks.

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. These cause unnecessary retries, delays, and prevent the newer features of the DNS being used.

As a result, the vendors of the most commonly used DNS software (BIND, Ubound, PowerDNS and Knot) will no longer be supporting these workarounds in new versions of their software, whilst a number of public DNS resolver operators (CleanBrowsing, Cloudflare, Google and Quad9) will no longer resolve hostnames served by broken name server implementations.

This may mean sites become unreachable, which makes it imperative that DNS administrators and domain name holders check whether their authoritative name servers are compliant with the DNS standard from 1987 (RFC1035) or the newer EDNS standard from 1999 (RFC2671 and RFC6891).

The DNS Flag Day website has some helpful information on what DNS administrators and domain name holders need to do, and there’s also a tool to check whether your domain is affected. So if you haven’t already done so, please check your domain for compliance as soon as possible!

Further Information

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, 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.


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

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 ‘’ 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 ‘’ 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 ( 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.


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’.


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

Further Information

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:
    • 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:
    • 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

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

Growing the Internet Internet Exchange Points (IXPs)

Stakeholder Workshop Held to Discuss Tajikistan IXP

The Internet Society in conjunction with the Open Society Institute Assistance Foundation – Tajikistan and the CAREN3 project organised an IXP workshop on 25 October 2018 at the Center of Written Heritage of the Tajik Academy of Sciences, in Dushanbe, Tajikistan. This followed on from a previous workshop held in 2017, and brought together nearly 30 stakeholders from local ISPs, civil society, and academia to discuss progress on the establishment of an Internet Exchange Point in Tajikistan.

I opened the workshop by summarising the IXP Environment Assessment report for Tajikistan that was commissioned by the Internet Society in 2017. This highlighted that Internet usage was below average for the region, and partly contributed to the low levels of economic growth in the country. The number of Internet users is estimated at between 15-40% of the population, Internet services are costly, and areas outside of the main cities do not have good access to broadband.

Internet uptake and use has been constrained by a variety of different factors, some of which are related to the geographic conditions (such as the landlocked mountainous nature of the country), and these have led to high prices for international capacity, high cost of services for the public, and lack of carrier-neutral local hosting.

Other constraints include limited competition amongst transit providers, high taxes imposed on ISPs, but in particular the requirement to use a single international gateway operated by Tajiktelecom. However, there has previously also been a reluctance for local ISPs to cooperate, as this was viewed as damaging to their business models, even though there is substantial evidence from other countries around the world that IXPs reduce costs and lead to growth of the local Internet.

There was further input from Robert Janz (University of Groningen & CAREN) who highlighted how the expense and technical constraints imposed upon CAREN and the National Research and Education Network TARENA was significantly hampering some of the excellent research that was happening in Tajikistan, but which also relied on international cooperation.

Tarik Sahovic (World Bank) then outlined the Digital CASA project which aims to implement cross-border connections to improve broadband internet connectivity in the landlocked countries of Central Asia and parts of South Asia by encouraging private sector investment in infrastructure. The implementation of IXPs are seen as a key aspect of this to reduce transit costs, improve transmission latencies, and encourage local content provision, but the regulatory regime within Tajikistan was currently hampering the opportunities this offered.

The keynote speaker was Aziz Soltobaev (ISOC Kyrgyzstan) who discussed the challenges of setting-up the KG-IX Internet Exchange in Bishkek, but also the soon-to-be deployed Ferghana Valley Internet Exchange Point (FVIXP) that will be based in Osh and will improve connectivity in the south of Kyrgyzstan. He explained there had been inflexible regulatory regime within their country as well, but a collective and sustained lobbying effort from the Internet community had encouraged changes that had achieved substantially improved connectivity and much cheaper prices.

This was followed by round table discussions amongst the IXPs and other stakeholders present, who agreed that an IXP was needed in Tajikistan, and felt the location and technical implementation would be quickly agreed if the regulatory environments were conducive to this. It was recognised there were significant issues with the regulatory regime and incumbent operator, but there are officials sympathetic to improving the Internet connectivity issues, and there were also government targets with respect to this and implementation of e-government initiatives.

There was enthusiasm amongst the stakeholders for putting together a unified and coherent plan for the IXP, followed by some collective lobbying to explain that Tajikistan is falling behind the rest of Central Asia, how costs are inhibiting growth of its Internet, and how an IXP could dramatically improve the situation. The Internet Society was also asked whether it could help through provision of fact and figures illustrating this, along with some case studies on how IXPs have facilitated growth of the Internet in countries.

The 3rd CAREN Regional Networking Conference (CRNC2018) was also held during the preceding two days at the Tajik Academy of Sciences. This is the annual conference of the Central Asian research and education networking community, supported by the EU-funded CAREN3 project, and I took the opportunity to give a presentation on why DNS Security and Privacy is important.

The Internet Society would like to thank the Open Society Institute Assistance Foundation – Tajikistan, the CAREN3 project, and the Internet Society Kyrgyzstan Chapter for supporting this workshop, and would also like to thank the Tajik Academy of Sciences for hosting it.

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

U.S. R&E Community Embraces Routing Security

The Internet Society participated in a Routing Security Workshop that was held during the Internet2 Technology Exchange 2018 on 15 October 2018 in Orlando, United States. The research and education networking community has been one of the key targets of the MANRS initiative that is promoting adoption of best practices to reduce threats to the global routing system, and this community workshop followed on from a previous engagement we had with Internet2 and a number of other R&E networks in the US earlier in the year.

Internet2 interconnects R&E institutes across the United States in conjunction with regional and state networks, so we see them as a key partner in raising awareness of the routing security issues, as well as encouraging the adoption of the four MANRS principles. Indeed, one of the aims of MANRS is for network operator communities to take ownership of this process by generating awareness and disseminating best practices, along with making recommendations for improvement. So this workshop was a fantastic step in this direction.

Another positive step was Internet2 formally becoming a MANRS participant shortly before the workshop, follow in the footsteps of ESnet, CAAREN, KanREN, George Washington University, Indiana University, and DePaul University. WiscNet subsequently also joined, which brings the total number of R&E networks participating in MANRS to nearly 30.

Around 50 participants attended the workshop, where the opening presentation was provided by myself (Kevin Meynell). This highlighted how the global routing system is constantly under attack, and provided some statistics on who the outages were affected, and who were the potential culprits. It also made the point that whilst more than 60,000 Autonomous Systems make up the Internet, only about 10,000 are considered part of the core, which means routing security can be greatly improved even if only a relatively small percentage of these adopt the MANRS principles.

The remainder of the workshop covered how to implement some of the routing security best practices, including the importance of Internet Routing Registry (IRR) updates, implementation of RPKI and uRPF, as well as how to implement BGP FlowSpec to implement packet filtering in order to mitigate Distributed Denial of Service (DDoS) attacks. There was also an interesting presentation on the Legal Barriers to Securing the Routing Architecture, followed by a discussion on what routing security means to Internet2 members implementing the next generation Internet.

Our colleague Ryan Polk assisted by Fabio Erdos also took the opportunity to interview the representatives of several MANRS participants attending the Internet2 Technology Exchange, to get their views on the routing issues they had encountered, how they were supporting routing security best practices, and why supported the MANRS initiative.

We would like to thank all those who agreed to be interviewed, Paul Howell, Anita Nikolich and Grover Browning who organised the workshop, and Internet2 for hosting it.

Further Information

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