Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt
On Tue, 5 Mar 2019, Dave Lawrence wrote: I can sort of see how someone might infer from "It is predicated on the observation that authoritative server unavailability can cause outages ..." that it means this whole idea is constrained to DDoS, and presumably you would include as well other network and server outages not caused by DDoS. It doesn't only mean that though. The intention is that this applies to any inability to get a proper authoritative response, one which has AA set in a protocol-meaningful way. This can be edited to be clearer, perhaps as simply as changing "authoritative server unavailability" to "authoritative answer unavailability". We'd be happy to consider alternative text. Ok, then that needs to be clarified in the draft. And you should discuss exactly which kind of failures are valid for extending the TTL and which are not and which should still try another auth server. ServFail is a clear signal that something is going wrong with the authoritative server itself has something going wrong. If you send a ServFail then AA is completely irrelevant. REFUSED is slightly murkier as to its exact meaning, thanks to overloading, but in its most commonly seen usage for lameness indicates a clear problem with the delegation. Even in its other use cases, notably an EDNS Client Subnet error or an actual "I am authoritative for the name but administratively denying your resolution of it", I submit that if the resolver has a stale answer then serving it is reasonable. In that administrative denial case it'd be better to issue NXDomain anyway, which is exactly what split horizon authorities do. Other lesser seen rcodes are largely similar in not indicating anything at all about the legitimacy of the name and whatever data you might have previously associated with it. Only the dynamic update rcodes come close to being relevant, but they are not part of the resolution process covered by serve-stale. Despite the unfortunate RFC 1035 nomenclature of NXDomain as "Name Error" it is called out explicitly because it isn't really an error, not in the database lookup sense. There's no way of knowing whether the NXDomain is happening because of operator fault or the far more likely case that it just doesn't exist. That's why it is called out separately in the doc, with an explicit note about why it has to be treated as replacing any stale data associated with the name. So put some text similar to this in the draft. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt
Tony Finch writes: > If the zone has a mixture of lame and working servers, the lame servers > should not trigger serve-stale, because the resolver still needs to try > asking the working servers. Yes, complete agreement. That is the thrust of what the document says. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt
Christopher Morrow writes: > My point is that the recursive reoslver has no idea why an authoritative > is unreachable and that doing anything like sending stale records is > going to cause unintended problems. Given the operational benefit that has already been observed in production with serve-stale, I think it needs more than vague fears of "is going to cause unintended problems" to argue against it. If we let unspecified concerns of possible unintended problems be our guidance we'd never get anything done around here. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt
Paul Wouters writes: > I am a bit confused here. The goal of the draft is to keep data past > the TTL in case you cannot reach the authoritative servers during a > DDOS attack. There are many different failure modes in operating the DNS and the goal of this draft has been to accommodate the ones that are clear failures. I, for one, have never put forth that it is only about resiliency against DDoS and don't recall hearing Warren or Puneet say that either. It can include when there are other clear errors in the system, even when self-inflicted by the authoritative operator. > Misconfiguring your authoritative server by removing the zone is not > meant to be covered by this draft if I understood it correctly. If it > is, then introduction will need to add text to cover that use case. I can sort of see how someone might infer from "It is predicated on the observation that authoritative server unavailability can cause outages ..." that it means this whole idea is constrained to DDoS, and presumably you would include as well other network and server outages not caused by DDoS. It doesn't only mean that though. The intention is that this applies to any inability to get a proper authoritative response, one which has AA set in a protocol-meaningful way. This can be edited to be clearer, perhaps as simply as changing "authoritative server unavailability" to "authoritative answer unavailability". We'd be happy to consider alternative text. Realistically only rcodes NoError and NXDomain apply for being authoritative answers, each being an explicit assertion regarding the name/type in the query and legitimately supplanting whatever previous data was known about that name and type. ServFail is a clear signal that something is going wrong with the authoritative server itself has something going wrong. If you send a ServFail then AA is completely irrelevant. REFUSED is slightly murkier as to its exact meaning, thanks to overloading, but in its most commonly seen usage for lameness indicates a clear problem with the delegation. Even in its other use cases, notably an EDNS Client Subnet error or an actual "I am authoritative for the name but administratively denying your resolution of it", I submit that if the resolver has a stale answer then serving it is reasonable. In that administrative denial case it'd be better to issue NXDomain anyway, which is exactly what split horizon authorities do. Other lesser seen rcodes are largely similar in not indicating anything at all about the legitimacy of the name and whatever data you might have previously associated with it. Only the dynamic update rcodes come close to being relevant, but they are not part of the resolution process covered by serve-stale. Despite the unfortunate RFC 1035 nomenclature of NXDomain as "Name Error" it is called out explicitly because it isn't really an error, not in the database lookup sense. There's no way of knowing whether the NXDomain is happening because of operator fault or the far more likely case that it just doesn't exist. That's why it is called out separately in the doc, with an explicit note about why it has to be treated as replacing any stale data associated with the name. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt
Tony Finch wrote: > > Say you have a partially-lame zone, where some servers might have an > expired copy (returning SERVFAIL) and some might not know about the zone > at all (returning REFUSED or referrals to the root). Typically (without > serve-stale) a resolver will react by adding a lame server cache entry and > re-trying other hopefully working servers. > > I think serve-stale should only take effect after this point, if a zone > has at least one non-lame server, and all the non-lame servers do not > respond. D'oh, sorry, I missed out the important case: If the zone has a mixture of lame and working servers, the lame servers should not trigger serve-stale, because the resolver still needs to try asking the working servers. Tony. -- f.anthony.n.finchhttp://dotat.at/ Irish Sea: Southwest, veering east for a time, 5 to 7, perhaps gale 8 later. Slight or moderate, occasionally rough in south. Rain or showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt
Paul Wouters wrote: > > I am a bit confused here. The goal of the draft is to keep data past the > TTL in case you cannot reach the authoritative servers during a DDOS > attack. Right. There's a tricky interaction between lameness and serve-stale. Say you have a partially-lame zone, where some servers might have an expired copy (returning SERVFAIL) and some might not know about the zone at all (returning REFUSED or referrals to the root). Typically (without serve-stale) a resolver will react by adding a lame server cache entry and re-trying other hopefully working servers. I think serve-stale should only take effect after this point, if a zone has at least one non-lame server, and all the non-lame servers do not respond. Tony. -- f.anthony.n.finchhttp://dotat.at/ a fair, free and open society ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt
On Mar 5, 2019, at 9:39 AM, Christopher Morrow wrote: > > > So, sorry I added an example set and we rat-holed on those. > > My point is that the recursive reoslver has no idea why an authoritative > is unreachable and that doing anything like sending stale records is > going to cause unintended problems. Those problems were not intended by the authoritative servers. Not sending stale records will also cause problems not intended by the users of the resolver that is serving stale data. Maybe the draft should add a sentence about this shift of "unintended problems" from authoritative to resolvers in the end of the Abstract, and again in the Introduction. It seems like people in the WG may be missing this shift. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt
On 4 Mar 2019, at 23:52, Christopher Morrow wrote: > I don't know how long it takes to get ICANN to 'do something creative' for > the root zone, but I'm guessing this isn't always feasible in normal > timelines (hours to a day or so). The IANA created an official, supported mechanism for emergency changes to the root zone back in 2010, as part of the project to deploy DNSSEC. The goal was to accommodate the needs of TLD managers to do quick changes to DS RRSets in the event that some bad signing thing happened. Even without that emergency provision, there were examples way back when of out-of-cycle changes were pushed through by the root zone maintainer (e.g. a third serial in a single day) because of some operational concern. When it comes down to it, all the people involved are operational and are good at what they do. I think TLDs are a red herring here, though. The TTLs on referral responses from TLD servers tend to be long and there is no shortage of options for diversity and redundancy in the NS set of TLD zones. Developing TLDs that have not yet reached a level to be able to engineer in that kind of diversity tend not to be the TLDs that are relied upon at the scale of those that have (and, I would suggest, serve-stale is not going to save them out from outage anyway). Structural instability in such TLDs is probably better addressed by technical outreach, support and education than by protocol extensions. Enterprise zones with low TTLs and with reduced options for authority server diversity due to the response-time tricks used to manage their traffic are far more likely to be interested in something like serve-stale, especially if their revenue is closely correlated with being reachable, and especially if they use lots of response-time tricks and want to understand what happens to client traffic when there's a DNS blip. From the other side, resolver operators for whom DNS non-reachability means a support burden have already implement these things. Describing how they work using outside voices seems like a good thing for everybody. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt
So, sorry I added an example set and we rat-holed on those. My point is that the recursive reoslver has no idea why an authoritative is unreachable and that doing anything like sending stale records is going to cause unintended problems. -chris ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt
On Tue, 5 Mar 2019, Paul Hoffman wrote: On Mar 5, 2019, at 7:59 AM, Dave Lawrence wrote: Paul Wouters writes: In the non-DDOS case, the auth server is reachable and none of the data is getting additional TTL added: Answers from authoritative servers that have a DNS Response Code of either 0 (NOERROR) or 3 (NXDOMAIN) MUST be considered to have refreshed the data at the resolver. In particular, this means that this method is not meant to protect against operator error at the authoritative server that turns a name that is intended to be valid into one that is non-existent, because there is no way for a resolver to know intent. Although perhaps it should also explicitely state this regarding ServFail ? I personally have a very strong opposition to including servfail. Servfail is an extremely clear indication that the authority that was contacted is having some sort of structural problem. It is a very distinct condition from being told by the authority that the name does or does not exist. I agree with David on this. This has been clear since RFC 1035. I am a bit confused here. The goal of the draft is to keep data past the TTL in case you cannot reach the authoritative servers during a DDOS attack. If you reach the authoritiatve server, and it gives ServFail, you did reach the server. You might have "structural problems" but not in the way of a denial of service attack. Unless you are saying DNS implementations that are overloaded return ServFail instead of dropping the packets? Misconfiguring your authoritative server by removing the zone is not meant to be covered by this draft if I understood it correctly. If it is, then introduction will need to add text to cover that use case. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt
On Mar 5, 2019, at 7:59 AM, Dave Lawrence wrote: > > Paul Wouters writes: >> In the non-DDOS case, the auth server is reachable and none of the data >> is getting additional TTL added: >> >>Answers from authoritative servers that have a DNS Response Code of >>either 0 (NOERROR) or 3 (NXDOMAIN) MUST be considered to have >>refreshed the data at the resolver. In particular, this means that >>this method is not meant to protect against operator error at the >>authoritative server that turns a name that is intended to be valid >>into one that is non-existent, because there is no way for a resolver >>to know intent. >> >> Although perhaps it should also explicitely state this regarding >> ServFail ? > > I personally have a very strong opposition to including servfail. > Servfail is an extremely clear indication that the authority that was > contacted is having some sort of structural problem. It is a very > distinct condition from being told by the authority that the name does > or does not exist. I agree with David on this. This has been clear since RFC 1035. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt
Paul Wouters writes: > In the non-DDOS case, the auth server is reachable and none of the data > is getting additional TTL added: > > Answers from authoritative servers that have a DNS Response Code of > either 0 (NOERROR) or 3 (NXDOMAIN) MUST be considered to have > refreshed the data at the resolver. In particular, this means that > this method is not meant to protect against operator error at the > authoritative server that turns a name that is intended to be valid > into one that is non-existent, because there is no way for a resolver > to know intent. > > Although perhaps it should also explicitely state this regarding > ServFail ? I personally have a very strong opposition to including servfail. Servfail is an extremely clear indication that the authority that was contacted is having some sort of structural problem. It is a very distinct condition from being told by the authority that the name does or does not exist. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt
Paul Vixie writes: > On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote: > > can I ask, what happens when a domain is intentionally down though? For > > instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the > > master/shadow NS go down, hard. All public auth servers eventually (in a > > day or so) went dark too. > > i already raised that question, very far up-thread. got no answer. While my answer to it was significantly late for when the query was made, and for that I have previously and will again apologize, it was responded to: https://mailarchive.ietf.org/arch/msg/dnsop/2o62EmB35OiBKNq9YZLfSMpqL2U ___ 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] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt
On Mon, 4 Mar 2019, Christopher Morrow wrote: "If the recursive server is unable to contact the authoritative servers for a query " So make the DNS server reachable, but return ServFail or NXDOMAIN. If the owner doesn't cooperate and there is legal standing, talk to the parent to do this for the delegation. this wasn't, near as I could tell, an option for the ccTLD in question. They lost their IP access, and were 'required' to disable their dns zone, their master was down hard from the internet's perspective, keeping anything else up wasn't really an option. We should not base our DNS domains on scenarios where a DNS administrator loses access to all their IP addresses and therefor could not operate the DNS as required. i think it prolongs the data being available in a bunch of the cases I can imagine/have-seen. I think there's at least one case where it's likely grave harm could have come to the dns operator. :( Grave harm beyond being already completely disconnected from the internet? I think that kind of harm is not something we can address in protocol design. I think what the draft does is attempt to guess at WHY a thing is changed, without an real data to back up the reasoning. this will mean the decision is wrong more than a small percent of the time. You will have to provide a few scenarions that we can actually evaluate to back that statement. To me, if your presence has been basically cut from the internet, then this is no longer an internet protocol issue. The DNS resolvers who want to accomodate their governments need to manually override their resolvers anyway with new (forged) data. This draft does not change that. If the owner itself wants to bring the domain down, they just need to make its auth servers reachable. sometimes that's not possible :( and the expectation is that 'when the right ttl sets expire all of our records disappear as you requested" If your servers are connected to the internet, that remains the case. The case we seem to talk about is only when all authoritative servers are down. If you get non-technical pressure to bring things down without getting TTL extensions, explain to those cutting you of that they can get a shorter disconnect time by letting you run a modified DNS configuration on your servers? If the DNS hoster wants to bring it down, they just need to modify the data it serves resulting in NXDOMAIN, ServFail or 127.0.0.1 A records. this is also not always possible :( Sorry, again you have to substantiate your answer here. Make up an imaginary story to illustrate this if you cannot use a real example. I don't think the "4 years" is a realistic problem case. is the '4 years' here in reference to the .eg problem? I have no idea what the ".eg problem" is. in my example the '4 yrs' was: "when the incident happened" not "please keep my dns alive for 4 yrs without talking to me" Ahh. I can see how people want to get a few hours or a few days of usage beyond the TTL to accomodate for errors. Although, it is likely that moving up the error this way will also delay the error from being detected before the extra time has expired, and we are just moving the goal post with no effective gain. But in the case of a DDOS attack, the draft's feature is surely useful. seems unlikely to be useful... even in the case of dos...really. (to me anyway) If I need a few hours up to a few days to try and work around a DDOS attack by adding capacity or some external provider to help me deal with the DDOS, then buying those few hours are what is keeping a domain online during such an attack. So while that might not apply to you, it is an actual real use case. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-pusateri-dnsop-update-timeout-02.txt
> On Mar 5, 2019, at 8:20 AM, Tony Finch wrote: > > Tom Pusateri wrote: >> >> Sorry if that freaked you out. > > I wasn't freaked out, I just thought the response was directed to the > wrong place. I didn't bring up the issue for a two-way discussion, I > wanted to see what other wg participants thought. > >> https://github.com/pusateri/draft-pusateri-dnsop-update-timeout >> >> and anyone is welcome to open issues if they like so I don’t think we >> need to replicate this info to the mailing list each time. > > The wg mailing list is where group decisions are supposed to be taken. > I don't particularly want to have to poll another (counting the dnsop > drafts) 35 places to find out if maybe some discussion has happened. > > Tony. I agree with you on this. The issues are for the authors and including the participants was a courtesy for them to be informed when the issue was resolved. However, since you seem to object, I will discontinue this practice. Thanks, Tom ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-pusateri-dnsop-update-timeout-02.txt
Tom Pusateri wrote: > > Sorry if that freaked you out. I wasn't freaked out, I just thought the response was directed to the wrong place. I didn't bring up the issue for a two-way discussion, I wanted to see what other wg participants thought. > https://github.com/pusateri/draft-pusateri-dnsop-update-timeout > > and anyone is welcome to open issues if they like so I don’t think we > need to replicate this info to the mailing list each time. The wg mailing list is where group decisions are supposed to be taken. I don't particularly want to have to poll another (counting the dnsop drafts) 35 places to find out if maybe some discussion has happened. Tony. -- f.anthony.n.finchhttp://dotat.at/ Fitzroy, Sole: South, veering northwest later, 6 to gale 8, perhaps severe gale 9 later in Fitzroy. Rough or very rough, becoming high for a time in southwest Fitzroy. Rain, then thundery showers. Moderate or poor, occasionally good.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-pusateri-dnsop-update-timeout-02.txt
> On Mar 5, 2019, at 7:18 AM, Tony Finch wrote: > > Tom Pusateri wrote: >> >> Modify presentation format of date/time to match RRSIG (Mark Andrews) > > I got some mail from github about this issue which was weirdly sent to > me personally rather than to the WG - see > > https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues/24 > > Tony. Sorry if that freaked you out. I opened issues on github and included comments made on the mailing list to make sure we captured them correctly when the issue was resolved. I referenced participants github user names where applicable. In your case this included: https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues/27 https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues/24 I’ve already mentioned on the WG mailing list that the document is being edited here: https://github.com/pusateri/draft-pusateri-dnsop-update-timeout and anyone is welcome to open issues if they like so I don’t think we need to replicate this info to the mailing list each time. Thanks, Tom ___ 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] draft-pusateri-dnsop-update-timeout-02.txt
Tom Pusateri wrote: > > Modify presentation format of date/time to match RRSIG (Mark Andrews) I got some mail from github about this issue which was weirdly sent to me personally rather than to the WG - see https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues/24 Tony. -- f.anthony.n.finchhttp://dotat.at/ strengthen the democratic process and ensure that there is a just and representative system of government ___ 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
