Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
On 08/03/2019 18:33, 神明達哉 wrote:
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,
Yes, that's feasible (and from dicussions I've had with them I think
it's not just feasible but extremely likely).
- 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 ?
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 { ... };
};
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.
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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
At Fri, 8 Mar 2019 12:03:27 -0500 (EST), Paul Wouters wrote: > [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] > > >> 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. > > > > 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. +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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
On Fri, 8 Mar 2019, Ray Bellis wrote: [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] 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. 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. The intention is that software operators can define rules in their configuration files such that *they* determine which values have what 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
On 08/03/2019 14:28, Paul Wouters wrote: 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. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
On 08/03/2019 03:58, Paul Wouters wrote: 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. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
On Fri, 8 Mar 2019 at 03:58, Paul Wouters wrote: 8< 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. > groundhog day > 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. > There are exactly two parties to a bi-lateral agreement. > If your use case is too private/secret or non-standard, then use a > 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
On Thu, 7 Mar 2019, Ray Bellis wrote: On 07/03/2019 16:57, Petr Špaček wrote: Like this one? 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? 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
On 07/03/2019 16:57, Petr Špaček wrote: Like this one? 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
On 05. 03. 19 7:26, Wes Hardaker wrote: > Mark Andrews writes: > >>> Yes, and that's where I see a problem: when the software doesn't know >>> the agreement has been severed. >> >> 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. Like this one? https://dougseven.com/2014/04/17/knightmare-a-devops-cautionary-tale/ -- Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
On 05/03/2019 10:57, I wrote wrote: (Just as BGP communities only have meaning between peers) That should've been qualified "usually". Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
Ray Bellis wrote: > On 04/03/2019 23:03, Wes Hardaker wrote: > > > 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. > > 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.finchhttp://dotat.at/ Viking, North Utsire, South Utsire: Cyclonic 5 or 6, becoming southeasterly 5 to 7. Moderate, occasionally rough. Occasional rain. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
On Tue, 5 Mar 2019 at 09:27, Ray Bellis wrote: 8< 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). > 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
On 05/03/2019 09:11, Shane Kerr wrote: I don't see much value in this beyond the already-standardized EDNS 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
Ray and all, On 04/03/2019 17.27, 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. 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 don't see much value in this beyond the already-standardized EDNS range reserved for local/experimental use. Cheers, -- Shane ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
On Tue, 5 Mar 2019 at 08:13, Ray Bellis wrote: > > > On 04/03/2019 23:03, Wes Hardaker wrote: > > > 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. > > The use cases on the open internet are probably less interesting than > those were client and server have a more tightly coupled relationship. > +1 > 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. > 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
On 04/03/2019 23:03, Wes Hardaker wrote: 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. The use cases on the open internet are probably less interesting than those were client and server have a more tightly coupled relationship. 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". 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
On 05/03/2019 01:44, Paul Wouters wrote: 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. 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). 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. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
Mark Andrews writes: > > Yes, and that's where I see a problem: when the software doesn't know > > the agreement has been severed. > > 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
On Tue, 5 Mar 2019 at 00:45, Mark Andrews wrote: 8< Presumably you won’t get back a server tag and you can log that. > 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
On Mon, 4 Mar 2019 at 23:43, Wes Hardaker wrote: > Dick Franks writes: > > > 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. > > Yes, and that's where I see a problem: when the software doesn't know > 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
> On 5 Mar 2019, at 10:43 am, Wes Hardaker wrote: > > Dick Franks writes: > >> 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. > > Yes, and that's where I see a problem: when the software doesn't know > the agreement has been severed. Presumably you won’t get back a server tag and you can log that. > -- > Wes Hardaker > USC/ISI > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- 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
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
Dick Franks writes: > 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. Yes, and that's where I see a problem: when the software doesn't know the agreement has been severed. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
On Mon, 4 Mar 2019 at 23:03, Wes Hardaker wrote: > Ray Bellis writes: > > > 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. > 8< 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? > 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
Ray Bellis writes: > 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. 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
On Mar 4, 2019, at 11:27 AM, 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. Any reason not to use DNS Stateful Operations for this? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-edns-tags-00.txt
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: internet-dra...@ietf.org To: Ray Bellis , Alan Clegg 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
