This document defines Discovery of Designated Resolvers (DDR), a mechanism for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. This mechanism can be used to move from unencrypted DNS to encrypted DNS when only the IP address of an encrypted resolver is known. It can also be used to discover support for encrypted DNS protocols when the name of an encrypted resolver is known. This mechanism is designed to be limited to cases where unencrypted resolvers and their designated resolvers are operated by the same entity.

This document describes an extension to DNS Over HTTPS (DoH) that allows hiding client IP addresses via proxying encrypted DNS transactions. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers.

This document describes several use cases for discovering DNSresolvers that support encrypted transports, and discusses howsolutions for these use cases can be designed to use commonmechanisms. It also considers the requirements for privacy andsecurity when designing resolver discovery mechanisms.

This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.

This document defines a mechanism for running the WebSocket Protocol(RFC 6455) over a single stream of an HTTP/2 connection.

This document presents the main experiments carried out in WP4 for validation and evaluation of the NEAT System. Based on the test plan proposed in Deliverable D4.2 [11], the report provides a detailed overview of the test setups, equipment configurations, measurement methodologies and evaluations for each of the four industrial use cases developed in WP1. We demonstrate the feasibility of the developed NEAT approaches in realistic environments underlining the relevance of the designed solutions in the context of the industrial use cases, related to the partners’ business needs. The experiments exercise key components of the core transport system designed in WP2, and highlight important research outcomes from WP3, related to the extended transport system and transport enhancements developed in the latter work package. Furthermore, the document includes a discussion on the future of NEAT with an emphasis on NEAT’s impact on scalability on a global scale as well as scalability aspects that relate to the end-host stack. Finally, the influence of the work carried out in NEAT on IETF standardisation efforts, in particular on a future standard transport API, is summarised. Participant organisation name Short name Simula Research Laboratory AS (Coordinator) SRL Celerway Communication AS Celerway EMC Information Systems International EMC MZ Denmark APS Mozilla Karlstads Universitet KaU Fachhochschule Münster FHM The University Court of the University of Aberdeen UoA Universitetet i Oslo UiO Cisco Systems France SARL Cisco 2 of 77 Project no. 644334 D4.3 Validation and evaluation results Public Rev. 1.0/ May 2, 2018

The immutable HTTP response Cache-Control extension allows servers to identify resources that will not be updated during their freshness lifetime. This ensures that a client never needs to revalidate a cached fresh resource to be certain it has not been modified.

Ossification of the Internet transport-layer architecture is a significant barrier to innovation of the Internet. Such innovation is desirable for many reasons. Current applications often need to implement their own mechanisms to receive the transport service they need, but many do not have the breadth of adapting to all possible network characteristics. An updated transport architecture can do much to make the Internet more flexible and extensible. New ground-breaking services often require different or updated transport protocols, could benefit from better signalling between application and network, or desire a more flexible choice of which network path is used for which traffic. This document therefore proposes a new transport architecture. Such architecture lowers the barrier to service innovation by proposing a “transport system”, the NEAT System, that can leverage the rich set of available transport protocols. It paves the way for an architectural change of the Internet where new transport-layer services can seamlessly be integrated and quickly made available, minimising deployment difficulties, and allowing Internet innovators to take advantage of them wherever possible. The document provides a survey of the state-of-the-art to identify the architectural obstacles to, and opportunities for, evolution of the transport layer. It also details a set of general requirements for a new transport architecture. This new architecture is motivated by a set of use-cases, followed by a description of the NEAT architecture for a transport system, designed to permit applications to select appropriate transports based on their needs and the available transport services. Participant organisation name Short name Simula Research Laboratory AS (Coordinator) SRL Celerway Communication AS Celerway EMC Information Systems International EMC MZ Denmark APS Mozilla Karlstads Universitet KaU Fachhochschule Münster FHM The University Court of the University of Aberdeen UoA Universitetet i Oslo UiO Cisco Systems France SARL Cisco 2 of 72 Project no. 644334 D1.1 NEAT Architecture Public Rev. 1.1/ June 13, 2016

This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.

This document defines a method for dynamically discovering resolvers that support encrypted transports, and introduces the concept of a designating a resolver to be used for a subset of client queries based on domain. This method is intended to work both for locally- hosted resolvers and resolvers accessible over the broader Internet.