<div class="gmail_quote">2012/2/9 John Hascall <span dir="ltr"><<a href="mailto:john@iastate.edu">john@iastate.edu</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Questions:<br>
<br>
(1) It looks to me like if the ghost name is in our<br>
    DNS RPZ zone, then that 'fixes' the problem for<br>
    that name.   Is this correct?<br></blockquote><div><br>Ghost domain could be redelegated to a new owner and become absolutely legal.<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
(2) It also looks like restarting bind flushes the cache<br>
    and that prevents the repopulation of the local cache<br>
    with names which are ghosts (new different ghost names<br>
    could, of course, be created).    Is this correct?<br></blockquote><div><br>AFAIK 'rndc flush' will do the same.<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
Thanks,<br>
John<br>
<br>
-------------------------------------------------------------------------------<br>
John Hascall, <a href="mailto:john@iastate.edu">john@iastate.edu</a><br>
Team Lead, NIADS (Network Infrastructure, Authentication & Directory Services)<br>
IT Services, The Iowa State University of Science and Technology<br>
<br>
> In <<a href="https://www.isc.org/software/bind/advisories/cve-2012-1033" target="_blank">https://www.isc.org/software/bind/advisories/cve-2012-1033</a>>, ISC<br>
> writes:<br>
><br>
> > ISC continues to recommend that organizations with security needs<br>
> > who are reliant on the Domain Name System proceed with adoption of<br>
> > DNSSEC; DNSSEC is the best known method of mitigating this issue.<br>
><br>
> But ISC provides no details about *how* exactly DNSSEC will solve the<br>
> problem. I'm puzzled. In the ghost domain names attack, the child zone<br>
> is controlled by the bad guy, who wants the domain to stick. So, he<br>
> will certainly not sign it. Unless you make DNSSEC mandatory, how will<br>
> you solve the ghost domain problem with DNSSEC? If the resolver is<br>
> sticky (will not go to the parent to ask the NS RRset), it won't check<br>
> the NSEC at the parent either...<br>
><br>
> Is it because the resolver, even if sticky, re-queries the parent when<br>
> the negative TTL of the (missing) DS records ends? And chokes when it<br>
> receives back a NXDOMAIN?<br>
> _______________________________________________<br>
> Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe<br>
 from this list<br>
><br>
> bind-users mailing list<br>
> <a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br>
> <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
><br>
<br>
_______________________________________________<br>
Please visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>--<br>AP<br>