Re: CVE-2012-1033 (Ghost domain names) mitigation
On 09.02.12 11:43, Lyle Giese wrote: This is just my opinion, but this is not a bug. It's the side effect of a desirable feature called caching. It's a design flaw - you cache something forever, even if case you should not do it. The cache time is given and we should not expand it, for valid reasons. Yea, we can brainstorm how to mitigate the effect, but in order to mitigate a problem, we have to know that there is a problem(revoked or bad domain). I think that the described draft seems to solve the problem. http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00 -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. M$ Win's are shit, do not use it ! ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
CVE-2012-1033 (Ghost domain names) mitigation
Questions: (1) It looks to me like if the ghost name is in our DNS RPZ zone, then that 'fixes' the problem for that name. Is this correct? (2) It also looks like restarting bind flushes the cache and that prevents the repopulation of the local cache with names which are ghosts (new different ghost names could, of course, be created).Is this correct? Thanks, John --- John Hascall, j...@iastate.edu Team Lead, NIADS (Network Infrastructure, Authentication Directory Services) IT Services, The Iowa State University of Science and Technology In https://www.isc.org/software/bind/advisories/cve-2012-1033, ISC writes: ISC continues to recommend that organizations with security needs who are reliant on the Domain Name System proceed with adoption of DNSSEC; DNSSEC is the best known method of mitigating this issue. But ISC provides no details about *how* exactly DNSSEC will solve the problem. I'm puzzled. In the ghost domain names attack, the child zone is controlled by the bad guy, who wants the domain to stick. So, he will certainly not sign it. Unless you make DNSSEC mandatory, how will you solve the ghost domain problem with DNSSEC? If the resolver is sticky (will not go to the parent to ask the NS RRset), it won't check the NSEC at the parent either... Is it because the resolver, even if sticky, re-queries the parent when the negative TTL of the (missing) DS records ends? And chokes when it receives back a NXDOMAIN? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: CVE-2012-1033 (Ghost domain names) mitigation
Questions: (1) It looks to me like if the ghost name is in our DNS RPZ zone, then that 'fixes' the problem for that name. Is this correct? Ghost domain could be redelegated to a new owner and become absolutely legal. Caveat Emptor -- if you buy a former TDSS (or someother evil) domain, that's just too bad. (2) It also looks like restarting bind flushes the cache and that prevents the repopulation of the local cache with names which are ghosts (new different ghost names could, of course, be created).Is this correct? AFAIK 'rndc flush' will do the same. Thanks - we're doing a nightly restart for other reasons. John ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: CVE-2012-1033 (Ghost domain names) mitigation
On Feb 9 2012, Peter Andreev wrote: 2012/2/9 John Hascall j...@iastate.edu [...snip...] (2) It also looks like restarting bind flushes the cache and that prevents the repopulation of the local cache with names which are ghosts (new different ghost names could, of course, be created).Is this correct? AFAIK 'rndc flush' will do the same. If you know the domain name in question, rndc flushname ghost.example should be enough. (BIND 9.9 has rndc flushtree as well, but I think clobbering the cached NS records for the ghost domain should be enough.) -- Chris Thompson Email: c...@cam.ac.uk ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: CVE-2012-1033 (Ghost domain names) mitigation
Questions: (1) It looks to me like if the ghost name is in our DNS RPZ zone, then that 'fixes' the problem for that name. Is this correct? Ghost domain could be redelegated to a new owner and become absolutely legal. On 09.02.12 07:36, John Hascall wrote: Caveat Emptor -- if you buy a former TDSS (or someother evil) domain, that's just too bad. unfortunately, RPZ or DNSSEC - solving this problem depends on while world using them, so with this flaw in DNS protocol we're screwed still. When you buy a domain, just check if it's blacklisted anywhere if you want to avoid this (2) It also looks like restarting bind flushes the cache and that prevents the repopulation of the local cache with names which are ghosts (new different ghost names could, of course, be created).Is this correct? AFAIK 'rndc flush' will do the same. Thanks - we're doing a nightly restart for other reasons. what? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. My mind is like a steel trap - rusty and illegal in 37 states. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: CVE-2012-1033 (Ghost domain names) mitigation
On 02/09/12 09:56, Matus UHLAR - fantomas wrote: Questions: (1) It looks to me like if the ghost name is in our DNS RPZ zone, then that 'fixes' the problem for that name. Is this correct? Ghost domain could be redelegated to a new owner and become absolutely legal. On 09.02.12 07:36, John Hascall wrote: Caveat Emptor -- if you buy a former TDSS (or someother evil) domain, that's just too bad. unfortunately, RPZ or DNSSEC - solving this problem depends on while world using them, so with this flaw in DNS protocol we're screwed still. When you buy a domain, just check if it's blacklisted anywhere if you want to avoid this (2) It also looks like restarting bind flushes the cache and that prevents the repopulation of the local cache with names which are ghosts (new different ghost names could, of course, be created).Is this correct? AFAIK 'rndc flush' will do the same. Thanks - we're doing a nightly restart for other reasons. what? This is just my opinion, but this is not a bug. It's the side effect of a desirable feature called caching. Yea, we can brainstorm how to mitigate the effect, but in order to mitigate a problem, we have to know that there is a problem(revoked or bad domain). 1) How would we(as dns server operators) know when a domain name is revoked? (Gee sounds like what the US government wants to do and it seems the community does not like that idea and I agree it's a bad idea to put the US DHS in charge of that list.) 2) Restart or flush our DNS cache frequently? Let's assume the A record TTL is 24 hrs. And if we decide to flush the cache once a day? That leaves a whole bunch of time that we are open to this and not much remaining time for the record in cache. I fail to see the benefit here. The idea to flush just the 'bad' domain fails due to #1, IMHO. 3) Maybe I don't understand DNS cache and it's relationship with DNSSEC yet. But if my server caches a good answer (verified via DNSSEC), why would my server recheck the DNSSEC records until the TTL has elapsed? My thinking(and I could be quite wrong here) is that my server will cache a good verified answer and DNSSEC does not seem to help here. Please let me know where I am wrong here if I am. Lyle Giese LCR Computer Services, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: CVE-2012-1033 (Ghost domain names) mitigation
On 2/9/12 9:43 AM, Lyle Giese l...@lcrcomputer.net wrote: This is just my opinion, but this is not a bug. It's the side effect of a desirable feature called caching. Yea, we can brainstorm how to mitigate the effect, but in order to mitigate a problem, we have to know that there is a problem(revoked or bad domain). 1) How would we(as dns server operators) know when a domain name is revoked? (Gee sounds like what the US government wants to do and it seems the community does not like that idea and I agree it's a bad idea to put the US DHS in charge of that list.) +1 on less government (note: that doesn't mean lack of regulation, but it should be community driven IMCO). It really seems we need a revoked domains feed that could be used with RPZ to implement the desired local policy (or not, choice rocks). Obviously this would need to be hosted somewhere like other DNSBLs, but would also need a well defined mechanism (simple web services API?) for registrars to submit data...and then, of course, there's the issue of participation. That said, this isn't a threat to the DNS servers themselves... the main concern is that someone could maintain a revoked domain and possibly redirect folks there. Controlling access to bad domains, revoked or not, may be better accomplished by having local protection (think web proxy/AV scanning with 0-day signatures) that reduces the impact rogue domains could have on your organization. -- Work is the curse of the drinking classes. -- Mike Romanoff ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
