<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    <br>
    On 12/7/2010 5:31 PM, David A. Evans wrote:
    <blockquote
cite="mid:OF7D06AA53.FFD067E7-ON862577F2.0079F9FD-862577F2.007BB4E4@notes.cat.com"
      type="cite">
      <br>
      <font face="sans-serif" size="2">        I'm
        in the mood to prove a point.   I have a very poorly written
        application
        that is generating a few hundred queries per second of
        completely bogus
        AAAA records before attempting a lookup of the correct A
        records.  This
        is because the application was compiled with a IPv6 interface
        enabled on
        the severs so it assumes that v6 is available.  It is not.  The
        application owner does not see an issue as they get the handful
        NXDOMAIN
        responses back in ~2 ms for each valid response and don't see
        any performance
        hit.   </font>
      <br>
      <br>
      <font face="sans-serif" size="2">        I
        would like to silently drop the AAAA record lookups instead of
        responding
        back with NXDOMAIN.  <br>
      </font></blockquote>
    NXDOMAIN? Is the application looking up a different *name* for its
    AAAA queries than for its A queries? If a single name owned A
    records but no AAAA records then the correct response from an
    AAAA-capable resolver to an AAAA query of the name, would be the
    so-called "NODATA" response (NOERROR with 0 answers and an SOA RR in
    Authority Section for negative caching purposes, see RFC 2308 for
    details). NXDOMAIN, as another poster pointed out, could inhibit
    even A-record queries of the name, and would be the wrong response
    in that situation.<br>
    <br>
    <blockquote
cite="mid:OF7D06AA53.FFD067E7-ON862577F2.0079F9FD-862577F2.007BB4E4@notes.cat.com"
      type="cite"><font face="sans-serif" size="2">Thusly generating a
        performance hit as the application
        waits 2 seconds for the reply.</font>
      <br>
      <br>
      <font face="sans-serif" size="2">        I
        have found the </font><tt><font size="3">filter-aaaa-on-v4 </font></tt><font
        face="sans-serif" size="2"> but
        it doesn't quiet do what I want.  From the description and my
        testing
        it appears to still reply with NXDOMAIN to these queries, it
        simply filters
        out the 'valid' AAAA records from IPV4 based replies. (which is
        a really
        cool solution to other issues, but not what I need.)</font>
      <br>
    </blockquote>
    How nasty do you want to be? You could always add an AAAA record for
    that name. Point it anywhere you want <evil laugh><br>
    <br>
    If you point it to something simply non-existent, this solution
    seems to me only slightly ruder than silently dropping the queries.<br>
    <br>
    <blockquote
cite="mid:OF7D06AA53.FFD067E7-ON862577F2.0079F9FD-862577F2.007BB4E4@notes.cat.com"
      type="cite">
      <br>
      <font face="sans-serif" size="2">        Besides
        spinning up a bind 4.x box which google tells me did this by
        default, is
        there any way of doing this?</font>
      <br>
    </blockquote>
    <br>
    I think it would be a really *bad* idea to spin up a BIND 4.x
    instance. Do you really want a big ugly security hole on your
    network? What about the person that inherits this setup from you?
    Would they be conversant in BIND 4.x setup and maintenance? I
    wouldn't wish BIND 4.x on anyone...<br>
    <br>
    If you really want to go in the direction of dropping packets, I'd
    look at some sort of software-firewall intervention (iptables or
    whatever) to do the packet-dropping.<br>
    <br>
    On the other hand, if the app really is looking up a different name
    for AAAA than for A (see above), that opens up all sorts of options
    for you. You could set up that name as a zone by itself and simply
    return REFUSED for all of those queries (the response packet count,
    and potentially the application delay, would be the same, but the
    response packets would be smaller and your intent crystal clear). Or
    set up a forwarder and play some games that way.<br>
    <br>
                                                                       
                                                                       
                                                                       
                - Kevin<br>
    <br>
    <br>
    <blockquote
cite="mid:OF7D06AA53.FFD067E7-ON862577F2.0079F9FD-862577F2.007BB4E4@notes.cat.com"
      type="cite"><font face="sans-serif" size="2">
      </font><font color="blue" size="5"><b>David A. Evans</b></font>
      <br>
      <font size="3"><b>Enterprise IP/DNS Management</b></font>
      <br>
      <font size="3"><b>Network Infrastructure Tools and Services</b></font>
      <br>
      <a moz-do-not-send="true" href="mailto:Evans_David_A@cat.com"><font
          color="blue" size="3"><b><u>Evans_David_A@cat.com</u></b></font></a>
      <br>
      <font size="3"><b> </b></font>
      <br>
      <font color="red" face="Comic Sans MS" size="1"><i>Eschew
          Obfuscation</i></font>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
bind-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a></pre>
    </blockquote>
    <br>
  </body>
</html>