CVE-2012-1033 (Ghost domain names) mitigation

Peter Andreev andreev.peter at gmail.com
Thu Feb 9 12:51:46 UTC 2012


2012/2/9 John Hascall <john at iastate.edu>

>
>
> 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.

>
> (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,
> 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
> >
>
> _______________________________________________
> 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
>



-- 
--
AP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20120209/1d42abe0/attachment.html>


More information about the bind-users mailing list