<font size=2 face="sans-serif">        Rack
Space appears to have fixed the issue.    "</font><tt><font size=2>dig
</font></tt><a href=www.wip.rackspace.com><tt><font size=2>www.wip.rackspace.com</font></tt></a><tt><font size=2>
 NS</font></tt><font size=2 face="sans-serif">"  now returns
NO DATA instead of NXDOMAIN.</font>
<br>
<br><font size=2 face="sans-serif">        I
wonder how many more are lurking out there.</font>
<br>
<br>
<br><font size=2 face="sans-serif">        We
are still getting a trickle in of complaints about slowness and failures
that appear to be related to the RPZ and the amount of time it takes to
complete all the extra queries for the NSDNAME checks.   When we research
these they seem to fit into 2 groups.</font>
<br>
<br>
<br><font size=2 face="sans-serif">        1.
  DNS zones with "slightly" broken infrastructure.  These
would be domains with either slow response from one or more name servers
or not responding name servers.  A recursive resolver without RPZ
loaded can work though the issue but the extra lookups required primarily
for the NSDNAME increases the query time to the point where DNS times out
from the client perspective.    I can't really see a fix here,
 the issue does reside with the domain owner, we are simply more susceptible
to the issue because of the RPZ's.  </font>
<br>
<br><font size=2 face="sans-serif">        2.
 DNS zones with a large number of NS records and the name servers
have FQDN's in several different DNS zones.</font>
<br>
<br><a href=www.domain.com><font size=2 face="sans-serif">www.domain.com</font></a><font size=2 face="sans-serif">
          NS        ns1.domain1.com</font>
<br><font size=2 face="sans-serif">         
              NS  
     ns2.domain2.com</font>
<br><font size=2 face="sans-serif">         
              NS  
     ns3.domain3.net  ..... </font>
<br>
<br><font size=2 face="sans-serif">        These
are the most frustrating as there is really nothing wrong with this setup
in my opinion.   This is just going to generate a huge number of DNS
lookups to do a full NSDNAME check.  These are hard to explain away
as they "work from home" and "work from my phone".
 </font>
<br>
<br>
<br><font size=2 face="sans-serif">        Have
others found similar issues when implementing RPZ's?</font>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">        </font>
<br>
<br>
<br><font size=5 color=blue><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><font size=3><b> </b></font>
<br>
<br>
<br><tt><font size=2>Mark Andrews <marka@isc.org> wrote on 05/07/2014
10:44:05 AM:<br>
<br>
> From: Mark Andrews <marka@isc.org></font></tt>
<br><tt><font size=2>> To: "David A. Evans" <Evans_David_A@cat.com></font></tt>
<br><tt><font size=2>> Cc: bind-users@isc.org</font></tt>
<br><tt><font size=2>> Date: 05/07/2014 10:44 AM</font></tt>
<br><tt><font size=2>> Subject: Re: RPZ and </font></tt><a href=www.rackspace.com><tt><font size=2>www.rackspace.com</font></tt></a>
<br><tt><font size=2>> <br>
> <br>
> In message <OFDC3C86D9.D668B707-ON86257CD1.005339FC-86257CD1.<br>
> 005431EB@notes.cat.com>, "David A. Evans" writes:<br>
> > <br>
> >         I've done some more troubleshooting
with info from people that <br>
> > responded directly to me and not to the list.    This
can be reproduced <br>
> > without any RPZ loaded by mimicking the behavior of the RPZ lookups
<br>
> > required to validate NSDNAME lines.<br>
> > <br>
> > Issue these 'digs' within 30 second of each other.<br>
> > <br>
> > dig </font></tt><a href=www.wip.rackspace.com><tt><font size=2>www.wip.rackspace.com</font></tt></a><tt><font size=2>
<br>
> > </font></tt><a href=www.wip.rackspace.com><tt><font size=2>www.wip.rackspace.com</font></tt></a><tt><font size=2>.
 30      IN      A      
173.203.44.116 <br>
> > <br>
> > dig </font></tt><a href=www.wip.rackspace.com><tt><font size=2>www.wip.rackspace.com</font></tt></a><tt><font size=2>
 NS<br>
> > (NXDOMAIN)<br>
> > <br>
> > dig </font></tt><a href=www.wip.rackspace.com><tt><font size=2>www.wip.rackspace.com</font></tt></a><tt><font size=2><br>
> > (NXDOMAIN)<br>
> > <br>
> > <br>
> >         I think this is another case of miss
configured load balancers. <br>
> > Shouldn't the NS record lookup respond with a NODATA response
and not <br>
> > NXDOMAIN? <br>
> <br>
> Yes.  The name exists.<br>
> <br>
> >         That still doesn't really answer
why a site as big as <br>
> > </font></tt><a href=www.rackspace.com><tt><font size=2>www.rackspace.com</font></tt></a><tt><font size=2>
isn't getting hit with support issues on their web site. <br>
> >  It only took us about 4 hours into our first production
day with <br>
> > NSDNAME's in our RPZ to get a call about </font></tt><a href=www.rackspace.com><tt><font size=2>www.rackspace.com</font></tt></a><tt><font size=2>
not loading.<br>
> <br>
> Because NS queries are not common with normal DNS lookups.  For<br>
> some reason people that deploy load balancers think they don't need<br>
> to fix issues like this.  Send something other than a A record
and<br>
> you get:<br>
> <br>
>    - NXDOMAIN being returned when the name exists.<br>
>    - NOTIMP being returned.<br>
>      (Really you can't just send NODATA?)<br>
>    - REFUSED being returned.<br>
>      (Really you don't want to tell us the record does
not exist?)<br>
>    - the wrong SOA being returned.<br>
>    - malformed RDATA with the content being the A record
content.<br>
> <br>
> Mark<br>
> <br>
> > David A. Evans<br>
> > Enterprise IP/DNS Management<br>
> > Network Infrastructure Tools and Services<br>
> > Evans_David_A@cat.com<br>
> > <br>
> > <br>
> > <br>
> > From:   "David A. Evans" <Evans_David_A@cat.com><br>
> > To:     bind-users@lists.isc.org<br>
> > Date:   05/07/2014 09:11 AM<br>
> > Subject:        RPZ and </font></tt><a href=www.rackspace.com><tt><font size=2>www.rackspace.com</font></tt></a><tt><font size=2><br>
> > Sent by:        bind-users-bounces@lists.isc.org<br>
> > <br>
> > <br>
> > <br>
> > CATERPILLAR SECURITY ALERT: The email address in the sender line
does not <br>
> > match the account that sent the email. This can be an indication
of <br>
> > phishing. Do not click links or open attachments unless you are
certain it <br>
> > is from a safe source. Learn more at security.cat.com/phishing<br>
> >         We have just enabled RPZ with some
NSDNAME checks and are seeing <br>
> > an issue resolving </font></tt><a href=www.rackspace.com><tt><font size=2>www.rackspace.com</font></tt></a><tt><font size=2>.
<br>
> > <br>
> >         The first lookup is successful and
returns both the CNAME and the <br>
> > A record.  The second query, within a second of the first,
will only <br>
> > return the CNAME.  It will only return the CNAME until the
TTL of the A <br>
> > record times out.  The first query, when it actually has
to go out and do <br>
> > recursion will always work.   Answering from cache will
always fail. When <br>
> > you inspect the cache during the time that it is only returning
the CNAME, <br>
> > the record in cache is "</font></tt><a href=www.wip.rackspace.com><tt><font size=2>www.wip.rackspace.com</font></tt></a><tt><font size=2>
 type ANY NXDOMAIN".    This <br>
> > only happens with RPZ's enabled and query hitting a RPZ zone
with a <br>
> > NSDNAME line.   Turning off RPZ or whitelisting the lookup
via RPZ before <br>
> > it hits a RPZ with NSDNAME allows the query to be successful
100% of the <br>
> > time. <br>
> > <br>
> > <br>
> >         Can anyone else verify this behavior?
  What is going on with <br>
> > </font></tt><a href=www.rackspace.com?><tt><font size=2>www.rackspace.com?</font></tt></a><tt><font size=2>
  If this is a miss configuration on Rackspace's DNS <br>
> > servers how are they not getting hit with support calls like
crazy? <br>
> > <br>
> > <br>
> > <br>
> > dig @redacted.cat.com </font></tt><a href=www.rackspace.com><tt><font size=2>www.rackspace.com</font></tt></a><tt><font size=2>
<br>
> > <br>
> > ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6
<<>> @redacted.cat.com <br>
> > </font></tt><a href=www.rackspace.com><tt><font size=2>www.rackspace.com</font></tt></a><tt><font size=2>
<br>
> > ; (1 server found) <br>
> > ;; global options: +cmd <br>
> > ;; Got answer: <br>
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:
30337 <br>
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL:
0 <br>
> > <br>
> > ;; QUESTION SECTION: <br>
> > ;</font></tt><a href=www.rackspace.com><tt><font size=2>www.rackspace.com</font></tt></a><tt><font size=2>.
            IN      A <br>
> > <br>
> > ;; ANSWER SECTION: <br>
> > </font></tt><a href=www.rackspace.com><tt><font size=2>www.rackspace.com</font></tt></a><tt><font size=2>.
     300     IN      CNAME  
</font></tt><a href=www.wip.rackspace.com><tt><font size=2>www.wip.rackspace.com</font></tt></a><tt><font size=2>.
<br>
> > </font></tt><a href=www.wip.rackspace.com><tt><font size=2>www.wip.rackspace.com</font></tt></a><tt><font size=2>.
 30      IN      A      
173.203.44.116 <br>
> > <br>
> > ;; Query time: 193 msec <br>
> > ;; SERVER: redacted <br>
> > ;; WHEN: Wed May  7 08:53:08 2014 <br>
> > ;; MSG SIZE  rcvd: 73 <br>
> > <br>
> > <br>
> > <br>
> > dig @redacted.cat.com </font></tt><a href=www.rackspace.com><tt><font size=2>www.rackspace.com</font></tt></a><tt><font size=2>
<br>
> > <br>
> > ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6
<<>> @redacted.cat.com <br>
> > </font></tt><a href=www.rackspace.com><tt><font size=2>www.rackspace.com</font></tt></a><tt><font size=2>
<br>
> > ; (1 server found) <br>
> > ;; global options: +cmd <br>
> > ;; Got answer: <br>
> > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN,
id: 25905 <br>
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL:
0 <br>
> > <br>
> > ;; QUESTION SECTION: <br>
> > ;</font></tt><a href=www.rackspace.com><tt><font size=2>www.rackspace.com</font></tt></a><tt><font size=2>.
            IN      A <br>
> > <br>
> > ;; ANSWER SECTION: <br>
> > </font></tt><a href=www.rackspace.com><tt><font size=2>www.rackspace.com</font></tt></a><tt><font size=2>.
     298     IN      CNAME  
</font></tt><a href=www.wip.rackspace.com><tt><font size=2>www.wip.rackspace.com</font></tt></a><tt><font size=2>.
<br>
> > <br>
> > ;; AUTHORITY SECTION: <br>
> > wip.rackspace.com.      58      IN
     SOA www-gtm-ord1.rackspace.com. <br>
> > hostmaster.305181-GTM1.rackspace.com. 86 10800 3600 604800 60
<br>
> > <br>
> > ;; Query time: 2 msec <br>
> > ;; SERVER: redacted <br>
> > ;; WHEN: Wed May  7 08:53:10 2014 <br>
> > ;; MSG SIZE  rcvd: 129 <br>
> > <br>
> > <br>
> > David A. Evans <br>
> > Enterprise IP/DNS Management <br>
> > Network Infrastructure Tools and Services <br>
> > Evans_David_A@cat.com _______________________________________________<br>
> > Please visit </font></tt><a href="https://lists.isc.org/mailman/listinfo/bind-users"><tt><font size=2>https://lists.isc.org/mailman/listinfo/bind-users</font></tt></a><tt><font size=2>
to <br>
> > unsubscribe from this list<br>
> > <br>
> > bind-users mailing list<br>
> > bind-users@lists.isc.org<br>
> > </font></tt><a href="https://lists.isc.org/mailman/listinfo/bind-users"><tt><font size=2>https://lists.isc.org/mailman/listinfo/bind-users</font></tt></a><tt><font size=2><br>
> > <br>
> > --=_alternative 0054318186257CD1_=<br>
> > Content-Type: text/html; charset="US-ASCII"<br>
> > <br>
</font></tt>