Subject: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt

From: Ray Bellis <[email-masked]>
Date: Mon, 4 Mar 2019 16:27:34 +0000

DNSOP,

This new draft describes a way for clients and servers to exchange a 
limited amount of information where the semantics of that information 
are completely unspecified, and therefore determined by bi-lateral 
agreement between the client and server operators.

There are known cases where bespoke implementations are using 
experimental EDNS option values for this purpose, for example for a 
front-end load-balancer to tell the server whether an incoming 
connection arrived over TCP or UDP (c.f. my XPF draft).

A goal of this draft is to assign a common EDNS code-point such that 
popular OSS implementations can support similar features interoperably.

Ray

-------- Forwarded Message --------
Subject: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
Date: Mon, 04 Mar 2019 08:14:24 -0800
From: [email-masked]
To: Ray Bellis <[email-masked]>, Alan Clegg <[email-masked]>

A new version of I-D, draft-bellis-dnsop-edns-tags-00.txt
has been successfully submitted by Ray Bellis and posted to the
IETF repository.

Name:		draft-bellis-dnsop-edns-tags
Revision:	00
Title:		DNS EDNS Tags
Document date:	2019-03-04
Group:		Individual Submission
Pages:		6
URL: 
https://www.ietf.org/internet-drafts/draft-bellis-dnsop-edns-tags-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-bellis-dnsop-edns-tags/
Htmlized:       https://tools.ietf.org/html/draft-bellis-dnsop-edns-tags-00
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-edns-tags

Abstract:
    This document describes EDNS Tags, a mechanism by which DNS clients
    and servers can transmit an opaque data field which has no defined
    semantic meaning other than as previously agreed between the client
    and server.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 4 Mar 2019 17:13:49 +0000

On Mar 4, 2019, at 8:27 AM, Ray Bellis <[email-masked]> wrote:
> This new draft describes a way for clients and servers to exchange a limited amount of information where the semantics of that information are completely unspecified, and therefore determined by bi-lateral agreement between the client and server operators.
> 
> There are known cases where bespoke implementations are using experimental EDNS option values for this purpose, for example for a front-end load-balancer to tell the server whether an incoming connection arrived over TCP or UDP (c.f. my XPF draft).
> 
> A goal of this draft is to assign a common EDNS code-point such that popular OSS implementations can support similar features interoperably.

I have read the draft (which is thankfully succinct!) and think it makes good sense. It could be adopted by DNSOP because it directly affects DNS operations.

--Paul Hoffman

---

From: Ted Lemon <[email-masked]>
Date: Mon, 4 Mar 2019 13:06:38 -0500

> This new draft describes a way for clients and servers to exchange a limited amount of information where the semantics of that information are completely unspecified, and therefore determined by bi…

Any reason not to use DNS Stateful Operations for this?

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 4 Mar 2019 18:47:11 +0000

> Any reason not to use DNS Stateful Operations for this?

Yes: the DNS state specification is necessarily complicated to implement because it is doing much more than what is proposed here. It is OK for someone to propose a simple mechanism for a simple need.

--Paul Hoffman

---

From: Ted Lemon <[email-masked]>
Date: Mon, 4 Mar 2019 15:12:18 -0500

> Yes: the DNS state specification is necessarily complicated to implement because it is doing much more than what is proposed here. It is OK for someone to propose a simple mechanism for a simple ne…

No argument, just curious if this had been considered.

---

From: Ray Bellis <[email-masked]>
Date: Mon, 4 Mar 2019 21:28:25 +0000

> Any reason not to use DNS Stateful Operations for this?

I expect there's plenty of reasons to define a DSO equivalent, but I can 
think of no reason to -constrain- this for use only with DSO.

Ray

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 04 Mar 2019 15:03:11 -0800

> agreement between the client and server operators.

Hmmm..  very interesting idea, but I'm having a hard time seeing how
this will be used in the real world in a scalable and interoperable
way.

Let's take an example from the draft (which is a good/interesting one, btw):

   o  client-controlled selection of a DNS-based security filter

So, my client knows the upstream resolver has published two flags/bits
for this:

  0x01 - don't filter out malware
  0x02 - please filter out ad servers

This is all well and good if the client knows what it's talking to.  How
does it know which resolvers support it?  This has to be custom config
in clients I assume?

So let's assume the (roaming) client has a pre-configured list of IP
addresses that know how to send or interpret particular tags.

What happens when the upstream software changes?  Or the upstream server
is taken over by a new company that deploys entirely new semantics?  How
is that change communicated to all the clients?  What if the new bits
mean something entirely different, potentially the exact opposite?  How
are conflicts like this handled?

There are cases for this type of behavior already, and they do work.  As
an example, BGP communities distribute routing policies in a fairly
similar way.  But BGP connections are small in number, contracts or MOUs
at the least are put in place to ensure communication can happen, etc.

The problem with a generic mechanism like this for DNS is that the
number of clients per server are potentially gigantic.  And there is
often not a documented relationship or even a known contact mechanism to
signal changes taking place.  This all makes communication of agreed
upon semantics of bits not exactly impossible, but likely between
difficult to extremely difficult.  And misconfiguration could be
potentially be dangerous, depending on the meaning of the bits.  Imagine
if the new bit for some flipped software suddenly switched to "I trust
MD5, go ahead and believe MD5 DS records".

But maybe, and hopefully, I'm just misunderstanding how this will be
used safely in deployments.

-- 
Wes Hardaker
USC/ISI

---

From: Dick Franks <[email-masked]>
Date: Mon, 4 Mar 2019 23:22:01 +0000

> > agreement between the client and server operators.

8<

> are conflicts like this handled?

The conflict never arises.
As the man said, "[semantics are] determined by bi-lateral agreement".
If the counter-party decides to do something different, it has repudiated
the agreement.

--Dick

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 04 Mar 2019 15:43:14 -0800

Dick Franks <[email-masked]> writes:

> If the counter-party decides to do something different, it has repudiated the
> agreement.

Yes, and that's where I see a problem: when the software doesn't know
the agreement has been severed.
-- 
Wes Hardaker
USC/ISI

---

From: Mark Andrews <[email-masked]>
Date: Tue, 5 Mar 2019 11:45:25 +1100

> On 5 Mar 2019, at 10:43 am, Wes Hardaker <[email-masked]> wrote:
> 

Presumably you won’t get back a server tag and you can log that.

> -- 
> Wes Hardaker
> USC/ISI
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Dick Franks <[email-masked]>
Date: Tue, 5 Mar 2019 00:48:14 +0000

> the agreement has been severed.

Non-performance by one party to the agreement will inevitably cause
something to fail,
which will be directly observable by the [singular] counter-party.

--Dick

---

From: Dick Franks <[email-masked]>
Date: Tue, 5 Mar 2019 01:19:31 +0000

On Tue, 5 Mar 2019 at 00:45, Mark Andrews <[email-masked]> wrote:

8<

Not always.

The spec does not require the server to return a server tag in response to
a client tag.
However, a server tag may only be returned in response to a request
containing a client tag.

--Dick

---

From: Paul Wouters <[email-masked]>
Date: Mon, 4 Mar 2019 20:44:56 -0500 (EST)

On Mon, 4 Mar 2019, Ray Bellis wrote:

> This new draft describes a way for clients and servers to exchange a limited 
> amount of information where the semantics of that information are completely 
> unspecified, and therefore determined by bi-lateral agreement between the 
> client and server operators.

This makes me very nervous. An edge ISP DNS server could use this to
mark DNS packets from certain users, and applications could use this as
another cookie to track users, especially in light of endusers talking
directly to open resolvers like the Quads, from within the application,
bypassing the operating system.

> There are known cases where bespoke implementations are using experimental 
> EDNS option values for this purpose, for example for a front-end 
> load-balancer to tell the server whether an incoming connection arrived over 
> TCP or UDP (c.f. my XPF draft).

Great. And once experimenting is done, submit a draft and get a real
EDNS code point. Do this as many times as you want. The idea of a
limited experimental space is that you cannot rely on it to be rolled
out into the wild word. That's a feature.

> A goal of this draft is to assign a common EDNS code-point such that popular 
> OSS implementations can support similar features interoperably.

I would much rather see 10 specfic EDNS code points for features, than a
kitchen sink EDNS option that can be abused to send potentially
dangerous tracking identifiers that we cannot distinguish from actual
DNS infrastructure options.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Mar 2019 01:54:32 +0000

> bypassing the operating system.

As the draft says, they can already do this now with unassigned EDNS0 code points. There is nothing you can do about it.

> out into the wild word. That's a feature.

Or a bug. IETF WGs cannot agree on which it is. Some WGs cannot remember which they prefer from year-to-year.

> DNS infrastructure options.

That's a fine preference, but it does not align with the reality that anyone can already do that. Not having a standard doesn't prevent abuse.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Mon, 4 Mar 2019 23:04:26 -0500 (EST)

> As the draft says, they can already do this now with unassigned EDNS0 code points. There is nothing you can do about it.

We can not facilitate those practises by not giving these practises a
code point ?

> Or a bug. IETF WGs cannot agree on which it is. Some WGs cannot remember which they prefer from year-to-year.

Well, it seems we have a registry for EDNS code points with
experimental/local code points. So I'm not sure how your
comment relates to this or other WGs?

> That's a fine preference, but it does not align with the reality that anyone can already do that. Not having a standard doesn't prevent abuse.

Sure, but facilitating those general purpose meta-camels is also not required action of the WG or implementers.

Paul

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 04 Mar 2019 22:26:15 -0800

> Presumably you won’t get back a server tag and you can log that.

No you may get back a server tag, and you're equally as likely to
misinterpret it just as the server misinterpreted your client tag.
Sure, *sometimes* (many times even) it will cause a parse error.  It's
the cases that don't cause parse errors that concern me.  What if the
client and server *think* they understand each other, but actually are
doing very different things because one side of the "agreement" is no
longer acting the same way.

-- 
Wes Hardaker
USC/ISI

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 04 Mar 2019 22:27:17 -0800

Dick Franks <[email-masked]> writes:

> Non-performance by one party to the agreement will inevitably cause something to fail,

How can you guarantee that a fail is never turned into a misinterpretation?
-- 
Wes Hardaker
USC/ISI

---

From: Ray Bellis <[email-masked]>
Date: Tue, 5 Mar 2019 08:04:16 +0000

> bypassing the operating system.

This is why the specification limits the data to a mere 16 bits.

Granted that this might permit more fine-grained "finger printing" when 
combined with other meta data but the intention is that _by itself_ it's 
insufficient to carry any PII (at least not unless your total number of 
clients is < 2^16).

> out into the wild word. That's a feature. 

It's not a feature, it's a bug.  These internal experiments almost never 
see the light of day, and as a result are unsupportable in e.g. BIND, 
instead relying on internal patches (which are fragile) or bespoke 
implementations (that are often protocol non-conformant).

Meanwhile we have customers who would like to deploy some kind of packet 
tagging but find that the only "blessed" option that kinda fits their 
needs is EDNS Client Subnet.   No thanks!

Ray

---

From: Ray Bellis <[email-masked]>
Date: Tue, 5 Mar 2019 08:13:12 +0000

> this will be used in the real world in a scalable and interoperable

The use cases on the open internet are probably less interesting than 
those were client and server have a more tightly coupled relationship.

> MD5, go ahead and believe MD5 DS records".

I suggest that I add a sentence or two about applicability, constraining 
it to those where the client has tight coupling (be that topologically 
or contractually) to a particular set of servers.

Ray

---

From: Dick Franks <[email-masked]>
Date: Tue, 5 Mar 2019 08:59:56 +0000

> those were client and server have a more tightly coupled relationship.

+1

> or contractually) to a particular set of servers.

The present wording already provides the necessary constraint; being
exclusively between the [exactly two] parties to the agreement.

What is there to not understand about the term "bi-lateral agreement".

--Dick

---

From: Shane Kerr <[email-masked]>
Date: Tue, 5 Mar 2019 10:11:33 +0100

Ray and all,

> popular OSS implementations can support similar features interoperably.

I don't see much value in this beyond the already-standardized EDNS 
range reserved for local/experimental use.

Cheers,

--
Shane

---

From: Ray Bellis <[email-masked]>
Date: Tue, 5 Mar 2019 09:27:18 +0000

> range reserved for local/experimental use.

Shane,

The additional value is being able to use the feature in off-the-shelf 
DNS software.

Stretching the analogy to BGP communities slightly (the authors had 
already discussed this internally when working on the draft, and Wes has 
made that comparison too):

Folks *could* have decided to use some unassigned BGP Path attribute 
value to carry similar information, but each implementor would have had 
their own special version of it.   Making it _standardised_ is what 
allows support to be ubiquitous (and interoperable).

Ray

---

From: Dick Franks <[email-masked]>
Date: Tue, 5 Mar 2019 10:54:49 +0000

On Tue, 5 Mar 2019 at 09:27, Ray Bellis <[email-masked]> wrote:

8<

> allows support to be ubiquitous (and interoperable).

But that is not the case here.
Even if the mechanism were to become standardised and ubiquitous, each
instance would be interoperable only between two specific consenting
parties.
IMHO this falls into the "local use" category.

--Dick

---

From: Ray Bellis <[email-masked]>
Date: Tue, 5 Mar 2019 10:57:44 +0000

On 05/03/2019 10:54, Dick Franks wrote:

> But that is not the case here. Even if the mechanism were to become
> standardised and ubiquitous, each instance would be interoperable
> only between two specific consenting parties. IMHO this falls into
> the "local use" category.

I was talking interoperable with respect to implementations, not the
specific values of the tags chosen between a pair of systems.

(Just as BGP communities only have meaning between peers)

Ray

---

From: Tony Finch <[email-masked]>
Date: Tue, 5 Mar 2019 12:32:49 +0000

Ray Bellis <[email-masked]> wrote:
> The use cases on the open internet are probably less interesting than those
> were client and server have a more tightly coupled relationship.

If I understand the purpose of this option, operators are already solving
this kind of problem with views and using the port number space or IP
address space for the tag.

Perhaps the draft needs to say more about the use cases, and give some
examples of how existing/planned implementations are expected to react to
tags.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire, South Utsire: Cyclonic 5 or 6, becoming southeasterly 5
to 7. Moderate, occasionally rough. Occasional rain. Good, occasionally poor.

---

From: Ray Bellis <[email-masked]>
Date: Tue, 5 Mar 2019 15:24:18 +0000

> (Just as BGP communities only have meaning between peers)

That should've been qualified "usually".

Ray

---

From: Petr Špaček <[email-masked]>
Date: Thu, 7 Mar 2019 17:57:46 +0100

> longer acting the same way.

Like this one?
https://dougseven.com/2014/04/17/knightmare-a-devops-cautionary-tale/

-- 
Petr Špaček  @  CZ.NIC

---

From: Ray Bellis <[email-masked]>
Date: Thu, 7 Mar 2019 17:45:34 +0000

> https://dougseven.com/2014/04/17/knightmare-a-devops-cautionary-tale/

Have you perhaps got anything constructive to contribute to the 
discussion instead of pure hyperbole?

:p

Ray

---

From: "Peter van Dijk" <[email-masked]>
Date: Thu, 07 Mar 2019 19:29:58 +0100

On 4 Mar 2019, at 18:13, Paul Hoffman wrote:

> I have read the draft (which is thankfully succinct!) and think it 
> makes good sense. It could be adopted by DNSOP because it directly 
> affects DNS operations.

+1

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Paul Wouters <[email-masked]>
Date: Thu, 7 Mar 2019 22:58:05 -0500 (EST)

On Thu, 7 Mar 2019, Ray Bellis wrote:

> Have you perhaps got anything constructive to contribute to the discussion 
> instead of pure hyperbole?

It is not hyperbole. It is an example of what can happen when people
overload options. Your proposal is a bad overloading option.

You are suggesting to introduce an option code point to convey blobs in
DNS. So different parties can send and receive blobs. You think or hope
that these parties will interpret this blob the same. But you have no
guarantee this is true.

If you have a specific use case, get a code point for that specific use
case. Than you know for sure what the blob means and that it will be
interpreted by all parties in the same standard RFC way.

If your use case is too private/secret or non-standard, then use a
code point from the "Reserved for Local/Experimental Use" range. Other
implementations then do not need to worry about misinterpreting the
meaning of the blob if more than one common use case started happening
on this code point, since they can ignore private use code points. If
your use case is experimental, go experiment and come back to us for a
real code point once the experiment is a success.

This draft is not a good idea.

Paul

---

From: Dick Franks <[email-masked]>
Date: Fri, 8 Mar 2019 10:02:03 +0000

On Fri, 8 Mar 2019 at 03:58, Paul Wouters <[email-masked]> wrote:

8<

> that these parties will interpret this blob the same. But you have no

groundhog day

> interpreted by all parties in the same standard RFC way.

There are exactly two parties to a bi-lateral agreement.

> code point from the "Reserved for Local/Experimental Use" range.

My inclination too, but the argument cannot be made by ignoring the
clearly stated requirement for agreement between participating parties.

--Dick

---

From: Ray Bellis <[email-masked]>
Date: Fri, 8 Mar 2019 10:33:46 +0000

> interpreted by all parties in the same standard RFC way.

I have some generic use cases in mind (subject to the existing cautions 
about bilateral agreements, consenting adults, etc) and also a very 
specific use case.

I have customers that want to tag a packet received by a DNS 
load-balancer and then on the back-end server use that tag to make 
decisions about the processing of that packet.

They want to do that with heterogenous off-the-shelf software, which 
means that implementations have to agree which code point to use.  This 
strongly suggests requesting an *assigned* code point.

Please also note that the requirements for assignment of an EDNS option 
is "Expert Review".  It does *not* require a Standards Track RFC.

It's therefore none of DNSOP's business what the values of those tags 
are, nor what the resulting packet processing decisions will be.  As far 
as the *protocol* is concerned, they're opaque.

It's not even any of DNSOP's business how large that blob is, but the 
current 16-bit limit is a concession (or some might say appeasement) to 
the perceived privacy concerns.

So while not requiring an RFC to obtain an assignment, the I-D is 
published for feedback on the design aspects of the option and to act as 
the reference specification for it.

Ray

---

From: "Peter van Dijk" <[email-masked]>
Date: Fri, 08 Mar 2019 12:13:57 +0100

Hello Ray,

On 8 Mar 2019, at 11:33, Ray Bellis wrote:

> I have some generic use cases in mind (subject to the existing 
> cautions about bilateral agreements, consenting adults, etc) and also 
> a very specific use case.
>

Me too, and I’ve spoken to several other people who also have such 
needs. I bet dnsdist users would eat this up if we implemented it.

> means that implementations have to agree which code point to use.  
> This strongly suggests requesting an *assigned* code point.
>
> Please also note that the requirements for assignment of an EDNS 
> option is "Expert Review".  It does *not* require a Standards Track 
> RFC.
>
> are, nor what the resulting packet processing decisions will be.  As 
> far as the *protocol* is concerned, they're opaque.
>
> current 16-bit limit is a concession (or some might say appeasement) 
> to the perceived privacy concerns.
>
> published for feedback on the design aspects of the option and to act 
> as the reference specification for it.

Well said!

Kind regards,

---

From: Paul Wouters <[email-masked]>
Date: Fri, 8 Mar 2019 09:28:32 -0500 (EST)

On Fri, 8 Mar 2019, Ray Bellis wrote:

> I have some generic use cases in mind (subject to the existing cautions about 
> bilateral agreements, consenting adults, etc) and also a very specific use 
> case.
>
> I have customers that want to tag a packet received by a DNS load-balancer 
> and then on the back-end server use that tag to make decisions about the 
> processing of that packet.

So you need to know the semantics of this even if each endpoint can decide
in their own way what to do with that information. Sounds like it should
use a code point ideally with a specification.

> They want to do that with heterogenous off-the-shelf software, which means 
> that implementations have to agree which code point to use.  This strongly 
> suggests requesting an *assigned* code point.

But assigned and left completely opague is not really suitable for
"heterogenous off-the-shelf software". These different vendors must
understand the meaning of the opaque data even if their functionality
can be non-standard.

> Please also note that the requirements for assignment of an EDNS option is 
> "Expert Review".  It does *not* require a Standards Track RFC.

Let's hope the Expert is reading these emails. I would hope they have
similar concerns.

> It's therefore none of DNSOP's business what the values of those tags are,

See above. I disagree.

> nor what the resulting packet processing decisions will be.

Agreed.

> As far as the *protocol* is concerned, they're opaque.

It seems you want to make decisions based on the blob content, so the
protocol functioning _is_ involved. At least vendors need to know what
the blob means.

> It's not even any of DNSOP's business how large that blob is

Again, I disagree. You want to both have it working in different
software vendors while not defining the blobs at all. Interoperability
quacks like a DNS standard to me.

> , but the current 
> 16-bit limit is a concession (or some might say appeasement) to the perceived 
> privacy concerns.

I'm glad to hear you are taking Privacy Considerations into account.

> So while not requiring an RFC to obtain an assignment, the I-D is published 
> for feedback on the design aspects of the option and to act as the reference 
> specification for it.

I'm confused why and how you would want multiple vendors to implement the same
opague blob interpretation without a standard.

Sure you can get a code point without RFC, but if you plan to use that
for some standarized interoperability thing, I would hope the DNS
vendors would balk and ask you to write a document for this.

Paul

---

From: Ray Bellis <[email-masked]>
Date: Fri, 8 Mar 2019 14:53:36 +0000

> understand the meaning of the opaque data even if their functionality

No, it does *not* require that at all.

We very careful referred to the *operators* of the software in the 
draft, not the implementors.

The intention is that software operators can define rules in their 
configuration files such that *they* determine which values have what 
meaning.    Just like how a BGP router can use BGP communities within 
routing policy maps.

In the load-balancer case, they might decide to use a few bits to select 
one of several RPZ feeds, or perhaps a view, without having to pass the 
client IP for the use a "source match" ACL to the backend.

They might decide to use another bit to indicate that the client is 
trusted such that the server doesn't need to apply RRL.

Granted this will need some form of representation in whatever 
configuration syntax is in use, but that would be implementation 
dependent.   The minimal implementation would just need to be able to 
test "tag & mask == value".

Ray

---

From: Paul Wouters <[email-masked]>
Date: Fri, 8 Mar 2019 12:03:27 -0500 (EST)

[my last email in this thread. I don't think we are progressing and I'd
  like to give others a chance to participate in this thread. But feel
  free to reply]

> No, it does *not* require that at all.

Unless the implementations just log these numbers, they are expected to
do or trigger something. Either with their own interpretation, or by
some helper process or configuration magic interpreting these things for them.

> We very careful referred to the *operators* of the software in the draft, not 
> the implementors.

That's just talking around the issue. You expect bind or knot or unbound
or a DNS load balancer to cause an act to happen based on these
transmitted values.

> meaning.

And my argument has been that this is bad DNS design not enhancing
interoperability, and that you should just more narrowly define the
actual things you are trying to do instead of bitbanging them into
opaque data. That way, interoperable RFCs and software can be written.

> In the load-balancer case, they might decide to use a few bits to select one 
> of several RPZ feeds, or perhaps a view, without having to pass the client IP 
> for the use a "source match" ACL to the backend.

> They might decide to use another bit to indicate that the client is trusted 
> such that the server doesn't need to apply RRL.

Specify seperate options and drafts for those use cases. It is better
for the entire community.

> Granted this will need some form of representation in whatever configuration 
> syntax is in use, but that would be implementation dependent.   The minimal 
> implementation would just need to be able to test "tag & mask == value".

This is the wrong way of getting independent implementations to interoperate.

Additionally, as you pointed out yourself, opague data can be abused
for nefarious purposes wile still claiming protocol compliance. By
narrowly specifying things, abusing those values at least forces those
implementations to violate the DNS protocol.

Paul

---

From: 神明達哉 <[email-masked]>
Date: Fri, 8 Mar 2019 10:33:40 -0800

At Fri, 8 Mar 2019 12:03:27 -0500 (EST),

> some helper process or configuration magic interpreting these things for
them.

+1.  It's very difficult for me to imagine how we can expect that two
"heterogenous off-the-shelf software" products can be interoperable
just because we have a standardized EDNS option code for opaque tags.

For example, assume that an operator uses dnsdist as a DNS load
balancer and BIND 9 as backend servers with RRL, and the operator
wants to trust particular clients (identified by their IP addresses)
and bypass RRL for them.  How can we expect off-the-shelf dnsdist and
off-the-shelf BIND 9 support this operation with the only assumption
being that both of them support edns-tags?  Is there an implicit
assumption that:
- this version of off-the-shelf dnsdist happens to have a new
  configuration option so it will add an edns-tag with setting bit X
  when the client IP address matches a specified set of address list,
- this version of off-the-shelf BIND 9 happens to have a new
  configuration option to skip RRL if an incoming request contains an
  edns-tag option with bit X on
?

At this moment I don't have a strong opinion on the proposal itself,
but the "off-the-shelf software" argument doesn't sound very
convincing or realistic.  Perhaps I miss some implicit assumptions, in
which case I'd like the draft to explain these in more detail.

--
JINMEI, Tatuya

---

From: Ray Bellis <[email-masked]>
Date: Fri, 8 Mar 2019 21:21:22 +0000

>    when the client IP address matches a specified set of address list,

Yes, that's feasible (and from dicussions I've had with them I think 
it's not just feasible but extremely likely).

>    edns-tag option with bit X on ?

Yes, that is also completely feasible.  I would expect (at some point) 
that BIND would offer the ability to use a tag comparison as part of an 
`address_match_element` that could then be used like so:

   rate-limit {
     exempt-clients { ... };
   };

> which case I'd like the draft to explain these in more detail.

The next version has this text:

"The intended mode of operation is that the value of a bit (or range of
bits) could be tested in access control lists or any other such policy
control mechanism."

I'm open to elaborating on this a little more in the draft, but it would 
be a shame for the draft to lose its current succintness.

Ray

---

From: "Peter van Dijk" <[email-masked]>
Date: Sat, 09 Mar 2019 16:03:41 +0100

>   edns-tag option with bit X on

Yes.

Kind regards,