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