Contents x
EDNS Client Subnet (ECS) for Resolver Operators - Getting Started
  • 04 Jan 2024
  • 4 Minutes to read
  • Contributors
  • Print
  • Dark
    Light
  • PDF
Contents

EDNS Client Subnet (ECS) for Resolver Operators - Getting Started

  • Updated on 04 Jan 2024
  • 4 Minutes to read
  • Contributors
  • Print
  • Dark
    Light
  • PDF
Article Summary

ISC has implemented EDNS Client Subnet (ECS) for Resolvers in the BIND Supported Preview (-S) edition. This feature is not available in public (Open Source) BIND.

BIND does not have an authoritative ECS feature

At one time, BIND did offer an experimental ECS feature for authoritative zones. This was not practical to deploy and has been removed from all versions of BIND from 9.13.0 onwards.

In order to help Resolver Operators to get started with ECS, here are some things that it is helpful to understand before making the first configuration changes.

  1. When starting with ECS, the first (and possibly only) option you need to configure is ecs-zones{}. This is where you list the zones (not the names within those zones), for which you wish BIND to offer ECS options on the queries it makes to authoritative servers, based on the IP subnets of the clients on whose behalf the queries are being made. Query responses will be cached, along with the subnet and prefix to which they apply, per the information provided by the authoritative server(s).

  2. BIND Supported Preview Edition does not become 'ECS aware' until at least one ECS option is added to named.conf. This is important to be aware of because when you start to configure ECS on your server, you may unintentionally change the client experience for queries made for names outside of the zones upon which you're focussing your attention.

ECS-aware resolvers may respond REFUSED to clients who add ECS options to their queries

EDNS options are usually added to queries made to authoritative servers on behalf of the clients whose recursive queries they are processing. However, queries from some clients (typically forwarding resolvers themselves) may be received with ECS options on them already. Once your server is ECS-aware, then unless a client is included in the ecs-forward ACL, any recursive query it makes which contains an ECS option with a non-zero source prefix-length will be answered with REFUSED. (The ecs-forward option is discussed further below).

ECS-aware resolvers may reject query responses from authoritative servers that contain unexpected/unsolicited ECS options

Some authoritative servers include ECS in the query responses, irrespective of whether or not the query they respond to has used ECS. BIND that is not ECS-aware will ignore the extraneous ECS options, but a resolver that has been configured to use ECS will reject these query responses. A mitigation can be found in the server option ignore-ecs-opt.

  1. Some clients may wish to disable ECS being added by the resolver on their behalf. They do this by sending their own ECS option with a zero length prefix. BIND will always honour this, regardless of whether not the server is ECS-aware. This zero-length prefix option is ignored by a resolver that is not ECS-aware and is treated as a signal to disable ECS for this query, by a server that is ECS-aware.
It is not necessary to add a client to the ecs-forward ACL for it to be able to have zero-length prefix ECS options on a query be accepted and be used to disable ECS for this client
  1. Use ECS option ecs-forward to provide an ACL that permits clients to add their own ECS options and have those used when making authoritative queries, instead of constructing the ECS options from the client's source IP subnet. This is necessary for accommodating a multi-tiered resolver environment where the end-user client queries are received indirectly by the resolver having first been received and forwarded by an intermediate device, or by another resolver.
Think about whether or not you want to permit all potential clients to add their own ECS options

As noted already, as soon as ECS is enabled on your resolver, if you do not permit clients to make recursive queries using ECS options that they have added themselves, then those clients will now be receiving REFUSED instead of having those ECS options be ignored. Note specifically, that adding clients to the ecs-forward ACL doesn't automatically mean that the ECS options will actually be used as received. The name being queried will still be matched against ecs-zones and if not allowed, then no ECS will be used. Secondly, the client may have requested a too-specific ECS scope - this will be capped by the global ecs-bits or per-zone bits-v4 and bits-v6 configured in named.conf.

  1. Use ECS option ecs-bits to set the subnet size (prefix) that BIND should use when adding the client subnet information. These values can be overridden on a per-domain basis by specifying bits-v4 and bits-v6 values in ecs-zones. The default values are 24 and 56, respectively, for IPv4 and IPv6 addresses.
ECS prefix lengths - larger or smaller than the default?

It might be tempting to be more specific with ECS options but this could negatively affect your resolver cache by causing more information to be added to it. On the other hand, BIND will create ECS cache content matching the specific subnet and size as provided by the authoritative server, so sending overly-specific ECS options on queries might not actually result in cache expansion due to tightly specific answers anyway...

  1. Negative ECS responses are cached in global cache alone. This means that BIND will not be able to cache or serve a positive RRset for one client in one subnet, but serve NXDOMAIN or NXRRSET (name exists but the requested RTYPE doesn't - typically this is a NOERROR empty ANSWER on the query response to the client) to another client in another subnet. As soon as the NXDOMAIN or NXRRSET is received and cached, then it will be used for all subsequent queries, irrespective of the client's subnet and the other RRsets that have been cached.

For more information on configuring EDNS Client Subnet, and for a precise description of how the various options work, please see the Administrator Reference Manual for the BIND Supported Preview edition that you are using.

What's Next

Cookie consent

We use our own and third-party cookies to understand how you interact with our Knowledgebase. This helps us show you more relevant content and ads based on your browsing and navigation history.