Re: [DNSOP] [[e-mail]: New Version Notification for draft-edmonds-dnsop-capabilities-00.txt]

[Robert Edmonds <[e-mail]>]

Mark Andrews wrote:
> There are three things that made it hard to deploy new features.
> 
> 1) Firewall vendor shipping firewalls with ridiculously strict rules
>    with zero evidence that they are needed.
> 
> 2) Misimplementation of STD 13 and RFC 2671 by nameserver vendors.
> 
> 3) Unknown EDNS option behaviour was not well defined by RFC 2671,
>    this is addressed in RFC 6891.
> 
> 1 and 2 made it impossible to do a clean update from RFC 2671 to
> RFC 6891 which tightened the unknown EDNS option behaviour.  Proper
> implementation of RFC 2671 would have allowed the EDNS version 1
> to be used to signal that RFC 6891 unknown option behaviour is
> required.

I'm more that willing to strip out any opinionated text in the draft
about what makes it hard to deploy new DNS features.

I agree that there is a lot of bad code out there, but my primary use
case is for greenfield deployments where both client and server side
have new code, and there is a need to detect the other side's
capabilities.

If you have old or bad code running in the client, server, or middlebox,
you just don't get to use the new features.

> I don't see how adding a capabilities option will help here when
> the primary problem is bad code.

There are cases where all you need is a feature flag, and in some cases,
the ability to remember an advertised feature for subsequent queries.

Currently there are 16 reserved bits between the DNS and EDNS headers
that require standards action to use. The small number of bits available
and the difficulty required to obtain one (the last allocation was over
10 years ago) means that an EDNS0 option is a more likely path for a
feature flag, but that path wastes a minimum of 5 octets. There's a
limited amount of space available in a UDP DNS query packet, maybe
around ~200 octets for a query with a maximum length QNAME and a
plausible set of EDNS0 options.

The "DNS Features" capability in my proposal provides space for 256
feature bits at a cost of up to 32 octets. If we make that space a FCFS
registry (and provide a handful of "Reserved for Local/Experimental Use"
bits) it becomes easier to experiment with new features (using a new bit
in an existing EDNS0 option is easier than implementing an entirely new
EDNS0 option).

-- 
Robert Edmonds