<font size=2 face="sans-serif">        To
my question of how many more are lurking out there.  It looks like
quite a few.  I am not sure we are going to be able to continue with
RPZ's and NSDNAME's.   </font>
<br>
<br><font size=2 face="sans-serif">         xserv.dell.com
is my newest main stream web site having the issue.</font>
<br>
<br><font size=2 face="sans-serif">        I
is behaving the same way as </font><a href=www.rackspace.com><font size=2 face="sans-serif">www.rackspace.com</font></a><font size=2 face="sans-serif">.
  They have DNS servers answering NXDOMAIN when they should be answering
NODATA.</font>
<br>
<br>
<br>
<br>
<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>(309) 675-9700 </b></font>
<br><a href=mailto:Evans_David_A@cat.com><font size=3 color=blue><b><u>Evans_David_A@cat.com</u></b></font></a>
<br>
<br><tt><font size=2>bind-users-bounces@lists.isc.org wrote on 05/28/2014
03:09:54 PM:<br>
<br>
> From: "David A. Evans" <Evans_David_A@cat.com></font></tt>
<br><tt><font size=2>> To: bind-users@isc.org</font></tt>
<br><tt><font size=2>> Date: 05/28/2014 03:10 PM</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>> Sent by: bind-users-bounces@lists.isc.org</font></tt>
<br><tt><font size=2>> <br>
> CATERPILLAR SECURITY ALERT: The email address in the sender line <br>
> does not match the account that sent the email. This can be an <br>
> indication of phishing. Do not click links or open attachments <br>
> unless you are certain it is from a safe source. Learn more at <br>
> security.cat.com/phishing<br>
>         Rack Space appears to have fixed the issue.
   "dig <br>
> </font></tt><a href=www.wip.rackspace.com><tt><font size=2>www.wip.rackspace.com</font></tt></a><tt><font size=2>
 NS"  now returns NO DATA instead of NXDOMAIN. <br>
> <br>
>         I wonder how many more are lurking out
there. <br>
> <br>
> <br>
>         We are still getting a trickle in of complaints
about <br>
> slowness and failures that appear to be related to the RPZ and the
<br>
> amount of time it takes to complete all the extra queries for the
<br>
> NSDNAME checks.   When we research these they seem to fit into
2 groups. <br>
> <br>
> <br>
>         1.   DNS zones with "slightly"
broken infrastructure.  These<br>
> would be domains with either slow response from one or more name <br>
> servers or not responding name servers.  A recursive resolver
<br>
> without RPZ loaded can work though the issue but the extra lookups
<br>
> required primarily for the NSDNAME increases the query time to the
<br>
> point where DNS times out from the client perspective.    I
can't <br>
> really see a fix here,  the issue does reside with the domain
owner,<br>
> we are simply more susceptible to the issue because of the RPZ's.
  <br>
> <br>
>         2.  DNS zones with a large number
of NS records and the name<br>
> servers have FQDN's in several different DNS zones. <br>
> <br>
> </font></tt><a href=www.domain.com><tt><font size=2>www.domain.com</font></tt></a><tt><font size=2>
          NS        ns1.domain1.com
<br>
>                    
    NS        ns2.domain2.com <br>
>                    
    NS        ns3.domain3.net  .....
<br>
> <br>
>         These are the most frustrating as there
is really nothing <br>
> wrong with this setup in my opinion.   This is just going to
<br>
> generate a huge number of DNS lookups to do a full NSDNAME check.
 <br>
> These are hard to explain away as they "work from home"
and "work <br>
> from my phone".   <br>
> <br>
> <br>
>         Have others found similar issues when
implementing RPZ's? <br>
> <br>
> <br>
> <br>
>         <br>
> <br>
> <br>
> David A. Evans <br>
> Enterprise IP/DNS Management <br>
> Network Infrastructure Tools and Services <br>
>   <br>
> <br>
> <br>
> Mark Andrews <marka@isc.org> wrote on 05/07/2014 10:44:05 AM:<br>
> <br>
> > From: Mark Andrews <marka@isc.org> <br>
> > To: "David A. Evans" <Evans_David_A@cat.com>
<br>
> > Cc: bind-users@isc.org <br>
> > Date: 05/07/2014 10:44 AM <br>
> > Subject: Re: RPZ and </font></tt><a href=www.rackspace.com><tt><font size=2>www.rackspace.com</font></tt></a><tt><font size=2>
<br>
> > <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 theirweb 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
linedoes 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 <br>
> 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
<br>
> 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 <br>
> 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>
> 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>