CVE-2012-1033 (Ghost domain names) mitigation

John Hascall john at iastate.edu
Thu Feb 9 12:40:52 UTC 2012



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, john at 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 




More information about the bind-users mailing list