Re: [DNSOP] [internet-dra...@ietf.org: New Version Notification for draft-edmonds-dnsop-capabilities-00.txt]

2017-07-03 Thread Robert Edmonds 
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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [internet-dra...@ietf.org: New Version Notification for draft-edmonds-dnsop-capabilities-00.txt]

2017-07-03 Thread Paul Hoffman 


On 2 Jul 2017, at 20:53, 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 don't see how adding a capabilities option will help here when
the primary problem is bad code.


I do. The fact that some middleboxes and servers have bad code doesn't 
mean that all of them do.


--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [internet-dra...@ietf.org: New Version Notification for draft-edmonds-dnsop-capabilities-00.txt]

2017-07-02 Thread Mark Andrews 

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 don't see how adding a capabilities option will help here when
the primary problem is bad code.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] [internet-dra...@ietf.org: New Version Notification for draft-edmonds-dnsop-capabilities-00.txt]

2017-07-02 Thread Robert Edmonds 
Hi,

I've written a proposal for adding capability signaling to the DNS
protocol that may be of interest to this group.

The git repository is here:
https://github.com/edmonds/draft-edmonds-dnsop-capabilities.

- Forwarded message from internet-dra...@ietf.org -

Date: Sun, 02 Jul 2017 13:42:39 -0700
From: internet-dra...@ietf.org
To: Robert Edmonds 
Subject: New Version Notification for draft-edmonds-dnsop-capabilities-00.txt


A new version of I-D, draft-edmonds-dnsop-capabilities-00.txt
has been successfully submitted by Robert Edmonds and posted to the
IETF repository.

Name:   draft-edmonds-dnsop-capabilities
Revision:   00
Title:  Signaling DNS Capabilities
Document date:  2017-07-02
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/internet-drafts/draft-edmonds-dnsop-capabilities-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-edmonds-dnsop-capabilities/
Htmlized:   https://tools.ietf.org/html/draft-edmonds-dnsop-capabilities-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-edmonds-dnsop-capabilities-00


Abstract:
   This document defines an Extension Mechanisms for DNS (EDNS0) option
   that allows DNS clients and servers to signal support for DNS
   protocol capabilities.  Clients and servers that support this option
   can take advantage of new DNS protocol features when completing a
   transaction, and by caching the set of capabilities advertised by a
   DNS server, a DNS client can utilize any mutually supported DNS
   protocol capability in subsequent queries.


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


- End forwarded message -

-- 
Robert Edmonds

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop