Re: [dns-operations] DNS Flush Protocol
On Mar 27, 2015, at 8:48 AM, Mike Jones m...@mikejones.in wrote: Comments? Ideas? Does someone want to make a slightly more formal proposal for what such a protocol should look like? In the responses so far, I have not seen people give one of the earlier-stated reasons why such a protocol might be bad: it can allow an attacker to more easily temporarily take over your zone. Assume that you're an attacker who has gotten the temporary ability to be on-path for one or more of a zone's servers. Being able to send out please refresh my zone alerts makes your attack much more effective. Further, when discovered, and the real zone owner sends out another blast of please refresh my zone, recipients might think I already did that and ignore it. Thus, the protocol proposed probably has to involve a requirement for DNSSEC validation of announcements, which will limit its utility. --Paul Hoffman ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Flush Protocol
On 3/27/15 9:48 AM, Warren Kumari wrote: Joe Abley and myself wrote some Internet Drafts on this. Requirements for a Mechanism for Remote-Triggered DNS Cache Flushes - draft-jabley-dnsop-flush-reqs-00 and A Mechanism for Remote-Triggered DNS Cache Flushes (DNS FLUSH) - http://tools.ietf.org/html/draft-jabley-dnsop-dns-flush-00 The above is quite elegant. And it does not require some new trust framework. I can NOTIFY any resolver I wish, and they can check to see if their cache is current by querying the master server (*before* flushing, hopefully). Richard. Some slides: http://www.ietf.org/proceedings/88/slides/slides-88-dnsop-5.pdf I eventually got bored and have started writing an out of band thing. It is basically a cooperative model . Basically a django app where a domain operator / owner will create an account and register their domains. The system will confirm domain ownership (kinda like a CA does (send emails, publish a TXT record, etc)). When something goes wrong, the domain operator logs in and requests a cache flush. The system then publishes (using pubsubhubbub) a signed cache flush request. Resolvers will run a (very) small daemon that listens for pubsub messages, validates them and then runs e.g rndc flush $domain. Domain owners have an incentive to do this to recover from Oopses. Resolver operators have less of an incentive, but I think many will still be willing to do this -- it protects their users, removes operational annoyance, etc. The message format, etc will all be published, so resolver operators can either just install the (to be provided) daemon, or roll their own. I cannot remember Geoff's numbers, but we need 100 of hte largest resolvers to get 85% of users. W On Fri, Mar 27, 2015 at 10:48 AM, Mike Jones m...@mikejones.in wrote: Every couple of months someone posts on a selection of industry mailing lists that something has happened and can everyone please flush their DNS caches for mywebsite.com. Often someone follows up the discussion by suggesting some kind of automated system, which results in a mention of opendns/googles flush pages, there is a little more suggestion that a community flush system would be useful, then the thread fizzles out. I hereby propose an automated cache flush mechanism. I have no idea what such a protocol should look like, however support for it probably needs to be built in to standard DNS software. BIND needs a setting that can tell it to register with cacheflushservice.net which will result in the cacheflushservice.net server sending out a request to flush google.com to all registered servers whenever I ask them to flush google.com for me. Comments? Ideas? Does someone want to make a slightly more formal proposal for what such a protocol should look like? - Mike Jones ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Flush Protocol
In your previous mail you wrote: I hereby propose an automated cache flush mechanism. I have no idea what such a protocol should look like, however support for it probably needs to be built in to standard DNS software. BIND needs a setting that can tell it to register with cacheflushservice.net which will result in the cacheflushservice.net server sending out a request to flush google.com to all registered servers whenever I ask them to flush google.com for me. = bind provides with rndc flush of the whole cache or a name or a treee (i.e., all entries under a name). So you are about an external interface to this admin function. Comments? Ideas? Does someone want to make a slightly more formal proposal for what such a protocol should look like? = I have a concern about security, in particular because the lack of trust relationship but we can design something to allow someone to flush his own names, can't we? Regards francis.dup...@fdupont.fr PS: we already have home made ways to proof ownership of a domain so perhaps the first step should be to formalize/standardize one? ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Flush Protocol
On Fri, Mar 27, 2015 at 03:48:17PM +, Mike Jones wrote: I hereby propose an automated cache flush mechanism. I have no idea what such a protocol should look like, however support for it probably needs to be built in to standard DNS software. Without a proposal for how this could possibly work, I don't see how it's a proposal at all. It's just a wish. The basic problem is that the DNS is designed as a database with distributed operation. That operation relies on TTLs. What people want is a way to continue to rely on that decentralization except when they mess up and don't want decentralization very briefly. I don't see a way that that can work reliably. I'm especially not keen to add yet more warts to the DNS protocol to solve the problem where people mess up during publication. It seems like it'd be better to concentrate those resources in better support tools for DNS operation. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Flush Protocol
OK. thats a good motivation. Nicely stated. Models based on in-band proof(s) of possession might then in some sense, be better. While I hate meta-protocol usage, since we don't have a cc channel that zone owners share with resolver owners, it might be a tool in the locker. How do you feel about state in the resolver to rendesvous on? Because if we can do DNS 'query knocking' with held state, we can signal both intentionality, and proof of possession. Obvious DoS risk of making a resolver hold state but its probably no worse than the Amp Attack risks. Or if we have held-open session, then sequences of queries can be more meaningful. I connect, I prove something doesn't exist with zero TTL, I perform state change in the zone and re-query which shows you I effected change for a prior query.. -G On 27 March 2015 at 15:08, Paul Vixie p...@redbarn.org wrote: George Michaelson wrote: I would agree that assumptions are a road to perdition. But the model of concentration of eyeballs through resolvers is not new. So, whilst I agree in *principle* I think it bears thinking about: do you actually really expect a disruptive (sea)change here? yes. or i wouldn't have worked on RPZ. the DNS resolution path is a huge component of internet autonomy, and it is under powerful attack by both corporations and governments around the world, for censorship, surveillance, and commerce purposes. to regain control of their own internet experience and to protect their privacy against upstream wiretapping, many enterprises of all sizes and many power users are going to move back to a private resolver model. we should do nothing in this WG that makes that movement less attractive, such as creating a DNS cache purge model that requires registration, subscription, or a clearinghouse. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Flush Protocol
Warren Kumari wrote: ... I cannot remember Geoff's numbers, but we need 100 of hte largest resolvers to get 85% of users. let us please not encode that assumption into any design work in this working group. the era of big resolvers may be finite, and even if not, there are many millions of users using the long tail of smaller resolvers. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Flush Protocol
I would agree that assumptions are a road to perdition. But the model of concentration of eyeballs through resolvers is not new. So, whilst I agree in *principle* I think it bears thinking about: do you actually really expect a disruptive (sea)change here? I mean, I think its more likely we get a sea-change in the signed root outcomes, than less people use 8.8.8.8 and 4.4.4.4 personally. Or Comcast, given their centrality in current (and forseeable future) market share now they're getting the eyes behind TW. Or China's concentration of views behind 3-4 carriers. So yes. But then again.. Perhaps.. No. On 27 March 2015 at 14:16, Paul Vixie p...@redbarn.org wrote: see also: http://www.techrepublic.com/blog/data-center/opendns-and-neustars-real-time-directory-aim-to-speed-dns-update-times/ ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Flush Protocol
George Michaelson wrote: OK. thats a good motivation. Nicely stated. Models based on in-band proof(s) of possession might then in some sense, be better. While I hate meta-protocol usage, since we don't have a cc channel that zone owners share with resolver owners, it might be a tool in the locker. How do you feel about state in the resolver to rendesvous on? Because if we can do DNS 'query knocking' with held state, we can signal both intentionality, and proof of possession. Obvious DoS risk of making a resolver hold state but its probably no worse than the Amp Attack risks. Or if we have held-open session, then sequences of queries can be more meaningful. I connect, I prove something doesn't exist with zero TTL, I perform state change in the zone and re-query which shows you I effected change for a prior query.. i put a fair amount of thought into this in 2002, and i could not come up with a scalable secure protocol, with either push or pull, with either subscriptions or registrations. therefore i decided that the only thing we could do is hold up. in the hold up model, the TTL's of the above-the-zone-cut NS RRset (so, the delegation from the ancestor zone) would control a redelegation check in the caching resolver. essentially this NS RRset would be cached, and when it expires, then a subsequent iterative lookup (even if it was for an in-cache RRset) would cause the caching resolver to use the zone's closest unexpired ancestor as the closest enclosing NS RRset, and to forward the query to that set of name servers. if those name servers answer with a delegation as they must previously have done, then the iterative lookup would be answered from cache, and the above-the-zone-cut NS RRset would be replaced in cache with the new one just refreshed. if on the other hand the NS RRset has changed (or is no longer present), then all cached data at or below that name would be purged, and the iterative lookup would be restarted without that cached data present. the idea here is that a 1-day TTL on all in-zone data would cause it to be retained for 1-day just as now, but, if there was a 1-hour (or 10-minute) TTL on the ancestor's delegation NS RRset to this zone, then there would be a delegation refresh every hour (or every ten minutes, or whatever the TTL was set to) such that if the delegation was altered or removed, then all cached data received from the prior set of delegated servers, would be dropped. if combined with a registry TTL setting of ten minutes or 30 minutes or similar, this would allow for: 1. rapid removal of criminal DNS content from all cooperating caches, upon DNS takedown; 2. rapid removal of incorrect DNS content from all cooperating caches, upon DNS oops. the cost of these delegation refresh checks would be minimal compared to the incredible flood of garbage queries we see at all registry-level authority servers today. even if we doubled the number of valid queries, which is unlikely, it would still be noise compared to the invalid, endlessly-repeating queries. so, low pain, great gain, no security concerns other than predictable timeouts (which could be randomized, if kaminsky-style attacks are a concern), no privacy concerns, no loss of performance for cache hot spots, no central registration or subscription or clearinghouse. years later (so, in 2010), i wrote this up as one of three similar improvements, here: http://datatracker.ietf.org/doc/draft-vixie-dnsext-resimprove/ but, i think noone understood it, so it languished. (note, it's only 4 pages long, so, an easy read.) -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Flush Protocol
On Fri, Mar 27, 2015 at 2:40 PM, George Michaelson g...@apnic.net wrote: I would agree that assumptions are a road to perdition. But the model of concentration of eyeballs through resolvers is not new. So, whilst I agree in *principle* I think it bears thinking about: do you actually really expect a disruptive (sea)change here? I mean, I think its more likely we get a sea-change in the signed root outcomes, than less people use 8.8.8.8 and 4.4.4.4 personally. Or Comcast, given their centrality in current (and forseeable future) market share now they're getting the eyes behind TW. Or China's concentration of views behind 3-4 carriers. So yes. But then again.. Perhaps.. No. This isn't really an architectural decision -- currently the way we flush caches is someone posts a OMG, I just did something dumb, please can everyone flush their cache for $foo on some set of mailing lists... and then we all wander around asking how / why we should trust that mail, some set of people actually flush, some don't read them mail till 4 days later, some bemoan the fact that we still haven't solved this problem, etc. I was saying is that we don't really need to reach *every* recursive, whatever we do manage to do will be better than the current position. Sure, a fully awesome, all shining, all dancing cache flush solution that can securely flush all caches everywhere would be best, but until this comes along, something, anything really, is better than posting on DNS-Operations W [0}: I'm assuming everyone knows about: https://developers.google.com/speed/public-dns/cache and http://cachecheck.opendns.com/ ? On 27 March 2015 at 14:16, Paul Vixie p...@redbarn.org wrote: see also: http://www.techrepublic.com/blog/data-center/opendns-and-neustars-real-time-directory-aim-to-speed-dns-update-times/ ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Flush Protocol
On 27 Mar 2015, at 20:56, Warren Kumari war...@kumari.net wrote: I was saying is that we don't really need to reach *every* recursive, whatever we do manage to do will be better than the current position. I disagree Warren. What's wrong with the status quo? Why can't it be left to the discretion of each manager of a resolving server to make their own decisions about when and why to flush their caches? It's not clear to me that there is a problem that needs fixing here. Discussions of possible solutions seems to be putting the cart before the horse. OK, George said he wants a pony. I'd like to see a clear problem statement. I have a feeling we're both going to be disappointed. :-) Sure, a fully awesome, all shining, all dancing cache flush solution that can securely flush all caches everywhere would be best, but until this comes along, something, anything really, is better than posting on DNS-Operations Doing nothing from a protocol perspective looks to be just fine and quite probably the Right Thing To Do. YMMV. I wonder too about the potential security and stability implications of this all-singing, all-dancing cache flushing solution. For example suppose organisation A's forwarding only servers get resolving service from organisation B. How would B's servers forward the received flush requests to A's? Suppose a botnet floods resolving servers with cache flush requests to make those servers then hammer authoritative servers. Cache flush requests to delete the metadata for the root would make things rather interesting too. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNS Flush Protocol
Warren Kumari wrote: ... I'd rather see an imperfect solution that anyone can use soon, instead of hoping that perhaps someone will eventually, maybe solve the issue sometime in the future. the delegation NS TTL based solution is not a protocol change; anyone who wants to adopt it can do so immediately. i suggest that clamping at two hours on the upper bound and 30 minutes at the lower bound would give immediate good results even before any registry gets around to changing their delegation TTLs. On Fri, Mar 27, 2015 at 4:00 PM, Paul Vixie p...@redbarn.org wrote: warren, have you read http://datatracker.ietf.org/doc/draft-vixie-dnsext-resimprove/ and do you have comments? http://www.ietf.org/mail-archive/web/namedroppers/current/msg09903.html and we had a discussion on another mailing list which was eerily similar to the above. when i was younger i thought that people older than me were mostly crazy. turns out we are mostly forgetful. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
