Re: [E] Re: strange problem with query being dropped/ignored by the BIND process

[Marc Richer]

Hi Bob,

> I tend to distrust  "CPU(30%)" if it is averaged over more than one
> cpu.  Could you run "top" and hit the number "1" so that it shows each
> cpu separately?  With 8 cpu's, "30%" could be one cpu at 100% and others
> lower, where the one cpu at 100% is your bottleneck.

I checked that with mpstat earlier already and the load is evenly
distributed amongst all CPUs. None of the CPUs is overloaded.

Regards
Marc

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: strange problem with query being dropped/ignored by the BIND process

[Bob Harold]

On Thu, Jun 29, 2017 at 9:51 AM, Marc Richter 
wrote:

> Hi Dennis,
>
> > Do you have any adjustments in /etc/system ?
>
> No. And as mentioned before this is a Solaris 11 system, so /etc/system is
> (mostly) irrelevant, as the IP settings are all done with ipadm now.
>
> >
> > # ndd -get /dev/ip \? | grep "read"
> > # ndd -get /dev/tcp \? | grep "read"
> >
>
> That, as well as the script and examples you provided, won't help me a lot,
> as I am looking at UDP receive buffer overflows, not TCP.
>
> I have set udp_max_buf to 4MB now and udp_send_buf & udp_recv_buf to 2MB
> each, then restarted BIND.
> It seems to be working better now as I don't see that much receive buffer
> overflows anymore.
>
> However, the initial question still stands. How can I reconfigure BIND to
> pick up the data faster from the receive buffer ?
>
> > Since you are on contract ( me too .. arn't we all these days ) then I
> > have to assume you have reasonable kernel updates and tcp patches in
> > this Solaris server ?
>
> Yes, of course.
>
> Regards
> Marc
>

I tend to distrust  "CPU(30%)" if it is averaged over more than one cpu.
Could you run "top" and hit the number "1" so that it shows each cpu
separately?  With 8 cpu's, "30%" could be one cpu at 100% and others lower,
where the one cpu at 100% is your bottleneck.

Just a guess at something to look at.

-- 
Bob Harold
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: strange problem with query being dropped/ignored by the BIND process

[Marc Richter]

Hi Dennis,

> Do you have any adjustments in /etc/system ?

No. And as mentioned before this is a Solaris 11 system, so /etc/system is
(mostly) irrelevant, as the IP settings are all done with ipadm now.

> 
> # ndd -get /dev/ip \? | grep "read"
> # ndd -get /dev/tcp \? | grep "read"
> 

That, as well as the script and examples you provided, won't help me a lot,
as I am looking at UDP receive buffer overflows, not TCP.

I have set udp_max_buf to 4MB now and udp_send_buf & udp_recv_buf to 2MB
each, then restarted BIND.
It seems to be working better now as I don't see that much receive buffer
overflows anymore.

However, the initial question still stands. How can I reconfigure BIND to
pick up the data faster from the receive buffer ?

> Since you are on contract ( me too .. arn't we all these days ) then I
> have to assume you have reasonable kernel updates and tcp patches in
> this Solaris server ?

Yes, of course.

Regards
Marc
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: strange problem with query being dropped/ignored by the BIND process

[Dennis Clarke]

On 06/29/2017 12:52 PM, Marc Richter wrote:

Hi again,

I have checked this again today.

Send & receive buffers are both 1MB, the Server has 8 CPUs and during
startup BIND is reporting this:

found 8 CPUs, using 8 worker threads
using 7 UDP listeners per interface
using up to 32768 sockets

We only have about 1.500 queries per second on this server. CPU(30%) and
memory(50%) usage also is not an issue here.


Do you have any adjustments in /etc/system ?

I will assume you don't have ip_forwarding messed with and let's just 
look at your network stack config. You don't need to publish your 
results to the maillist but have a look at :


# ndd -get /dev/ip \? | grep "read"
# ndd -get /dev/tcp \? | grep "read"

Here you have the full range of stack kernel tunables. At the very least
the ones you can read data from.

You probably already did this but create a quick script :

#!/bin/sh
/usr/bin/printf "\n"

/usr/bin/printf "tcp_wscale_always = "
ndd -get /dev/tcp tcp_wscale_always

/usr/bin/printf "tcp_tstamp_if_wscale = "
ndd -get /dev/tcp tcp_tstamp_if_wscale

/usr/bin/printf "tcp_max_buf = "
ndd -get /dev/tcp tcp_max_buf

/usr/bin/printf "tcp_cwnd_max = "
ndd -get /dev/tcp tcp_cwnd_max

/usr/bin/printf "tcp_xmit_hiwat = "
ndd -get /dev/tcp tcp_xmit_hiwat

/usr/bin/printf "tcp_recv_hiwat = "
ndd -get /dev/tcp tcp_recv_hiwat


Run that.


What I see here on three diff Sol10 servers for various purposes is :

M5 # /tmp/foo.sh

tcp_wscale_always = 1
tcp_tstamp_if_wscale = 1
tcp_max_buf = 1048576
tcp_cwnd_max = 1048576
tcp_xmit_hiwat = 49152
tcp_recv_hiwat = 49152


st0 # /tmp/foo.sh

tcp_wscale_always = 1
tcp_tstamp_if_wscale = 1
tcp_max_buf = 1048576
tcp_cwnd_max = 1048576
tcp_xmit_hiwat = 49152
tcp_recv_hiwat = 49152


st1 #

tcp_wscale_always = 1
tcp_tstamp_if_wscale = 1
tcp_max_buf = 16777216
tcp_cwnd_max = 8388608
tcp_xmit_hiwat = 65535
tcp_recv_hiwat = 65535


The first two are defaults whereas the last unit needs to sling around
terabytes daily.  I am curious what your system thinks it is doing
with its tcp/ip stack.

Since you are on contract ( me too .. arn't we all these days ) then I
have to assume you have reasonable kernel updates and tcp patches in
this Solaris server ?

Dennis




___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: strange problem with query being dropped/ignored by the BIND process

[Marc Richter]

Hi again,

I have checked this again today.

Send & receive buffers are both 1MB, the Server has 8 CPUs and during
startup BIND is reporting this:

found 8 CPUs, using 8 worker threads
using 7 UDP listeners per interface
using up to 32768 sockets

We only have about 1.500 queries per second on this server. CPU(30%) and
memory(50%) usage also is not an issue here.

Now Oracle support is saying that the buffer sizes are fine and we need to
"speed up the application" to read the data faster from the receive buffer
and this prevent package drops.

Do you think that is a reasonable statement in this environment ?
What would be the best way to "speed up the application" ? Just increase
the worker threads ?

Regards
Marc


On 06/28/17 15:31, Marc Richter wrote:
> Hi Ben,
> 
> thanks for the answer.
> 
> Yeah, I think you are right. I see a lot of udpInOverflows on the system,
> which suggest that the receive buffer is too small indeed.
> 
> Is there any kind of recommendation or best-practice advice what the
> buffers should ideally be set to on Solaris ?
> I did search the ISC Knowledge Base, but didn't find any useful advice.
> 
> Regards
> arc
> 
> On 06/28/17 14:37, Ben Croswell wrote:
>> Have you checked deeper at the OS level? I have seen on Linux DNS servers
>> silent drops of queries on very busy servers that were exhausting UDP
>> receive buffers.
>>
>> On Jun 28, 2017 10:26 AM, "Marc Richter" > > wrote:
>>
>> Hi,
>>
>> we have a setup here consisting of a recursive DNS server and two
>> monitoring servers. The monitoring servers sent a test query to the DNS
>> server once every two minutes to check if it is answering properly.
>>
>> We now have the problems that these test queries are timing out from time
>> to time, (correctly) resulting in alarms in our monitoring system.
>>
>> I have checked this now and noticed that each time we see that alarm, the
>> query sent by the monitoring server is not being answered at all.
>> To debug that I ran tcpdump on both the monitoring server and the 
>> recursive
>> DNS server. I see the query being sent out on the monitoring server and I
>> also see the query being received on the DNS server, however there is no
>> response sent to this query at all.
>> Looking at the query log, which I enabled temporarily, the query is also
>> not logged there so it looks like BIND is ignoring that query somewhere,
>> although it is properly received by the IP stack of the server.
>>
>> Do you have any suggestions how to debug this further, to hopefully find
>> out where these queries are stuck/dropped/ignored, as I have run out of
>> ideas ?
>>
>> The environment is:
>> BIND 9.9.9-P5 (Extended Support Version) 
>> running on SunOS sun4v 5.11 11.3
>>
>>
>> Thanks !
>> Marc
>> ___
>> Please visit 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.isc.org_mailman_listinfo_bind-2Dusers=DwICAg=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=wDgZv-d1RrBMzWr_7pSF_09ZAXIr59EgoXQU4ctOHMk=b8p_t6atDvFHu2tWe4Jgw_EvLufZakMUJL0w06aA3V0=bXYnQq1IzLGZG6xbey81qsaTVpqiLVlwxazV8CXVP_A=
>>  
>> 
>> 
>> to unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org 
>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.isc.org_mailman_listinfo_bind-2Dusers=DwICAg=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=wDgZv-d1RrBMzWr_7pSF_09ZAXIr59EgoXQU4ctOHMk=b8p_t6atDvFHu2tWe4Jgw_EvLufZakMUJL0w06aA3V0=bXYnQq1IzLGZG6xbey81qsaTVpqiLVlwxazV8CXVP_A=
>>  
>> 
>> 
>>
>>
> 

-- 
Marc Richter
Engr III Cslt-Ntwk Eng

Sebrathweg 20
44149 Dortmund
Germany

O +49 231 972 1293
F +49 231 972 2587
E marc.rich...@de.verizon.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: [E] Re: strange problem with query being dropped/ignored by the BIND process

[Marc Richter]

Hi Ben,

thanks for the answer.

Yeah, I think you are right. I see a lot of udpInOverflows on the system,
which suggest that the receive buffer is too small indeed.

Is there any kind of recommendation or best-practice advice what the
buffers should ideally be set to on Solaris ?
I did search the ISC Knowledge Base, but didn't find any useful advice.

Regards
arc

On 06/28/17 14:37, Ben Croswell wrote:
> Have you checked deeper at the OS level? I have seen on Linux DNS servers
> silent drops of queries on very busy servers that were exhausting UDP
> receive buffers.
> 
> On Jun 28, 2017 10:26 AM, "Marc Richter"  > wrote:
> 
> Hi,
> 
> we have a setup here consisting of a recursive DNS server and two
> monitoring servers. The monitoring servers sent a test query to the DNS
> server once every two minutes to check if it is answering properly.
> 
> We now have the problems that these test queries are timing out from time
> to time, (correctly) resulting in alarms in our monitoring system.
> 
> I have checked this now and noticed that each time we see that alarm, the
> query sent by the monitoring server is not being answered at all.
> To debug that I ran tcpdump on both the monitoring server and the 
> recursive
> DNS server. I see the query being sent out on the monitoring server and I
> also see the query being received on the DNS server, however there is no
> response sent to this query at all.
> Looking at the query log, which I enabled temporarily, the query is also
> not logged there so it looks like BIND is ignoring that query somewhere,
> although it is properly received by the IP stack of the server.
> 
> Do you have any suggestions how to debug this further, to hopefully find
> out where these queries are stuck/dropped/ignored, as I have run out of
> ideas ?
> 
> The environment is:
> BIND 9.9.9-P5 (Extended Support Version) 
> running on SunOS sun4v 5.11 11.3
> 
> 
> Thanks !
> Marc
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users
> 
> 
> to unsubscribe from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org 
> https://lists.isc.org/mailman/listinfo/bind-users
> 
> 
> 
> 

-- 
Marc Richter
Engr III Cslt-Ntwk Eng

Sebrathweg 20
44149 Dortmund
Germany

O +49 231 972 1293
F +49 231 972 2587
E marc.rich...@de.verizon.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: strange problem with query being dropped/ignored by the BIND process

[Ben Croswell]

Have you checked deeper at the OS level? I have seen on Linux DNS servers
silent drops of queries on very busy servers that were exhausting UDP
receive buffers.

On Jun 28, 2017 10:26 AM, "Marc Richter" 
wrote:

Hi,

we have a setup here consisting of a recursive DNS server and two
monitoring servers. The monitoring servers sent a test query to the DNS
server once every two minutes to check if it is answering properly.

We now have the problems that these test queries are timing out from time
to time, (correctly) resulting in alarms in our monitoring system.

I have checked this now and noticed that each time we see that alarm, the
query sent by the monitoring server is not being answered at all.
To debug that I ran tcpdump on both the monitoring server and the recursive
DNS server. I see the query being sent out on the monitoring server and I
also see the query being received on the DNS server, however there is no
response sent to this query at all.
Looking at the query log, which I enabled temporarily, the query is also
not logged there so it looks like BIND is ignoring that query somewhere,
although it is properly received by the IP stack of the server.

Do you have any suggestions how to debug this further, to hopefully find
out where these queries are stuck/dropped/ignored, as I have run out of
ideas ?

The environment is:
BIND 9.9.9-P5 (Extended Support Version) 
running on SunOS sun4v 5.11 11.3


Thanks !
Marc
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

strange problem with query being dropped/ignored by the BIND process

[Marc Richter]

Hi,

we have a setup here consisting of a recursive DNS server and two
monitoring servers. The monitoring servers sent a test query to the DNS
server once every two minutes to check if it is answering properly.

We now have the problems that these test queries are timing out from time
to time, (correctly) resulting in alarms in our monitoring system.

I have checked this now and noticed that each time we see that alarm, the
query sent by the monitoring server is not being answered at all.
To debug that I ran tcpdump on both the monitoring server and the recursive
DNS server. I see the query being sent out on the monitoring server and I
also see the query being received on the DNS server, however there is no
response sent to this query at all.
Looking at the query log, which I enabled temporarily, the query is also
not logged there so it looks like BIND is ignoring that query somewhere,
although it is properly received by the IP stack of the server.

Do you have any suggestions how to debug this further, to hopefully find
out where these queries are stuck/dropped/ignored, as I have run out of ideas ?

The environment is:
BIND 9.9.9-P5 (Extended Support Version) 
running on SunOS sun4v 5.11 11.3


Thanks !
Marc
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Strange problem with a query deleting a record...

[John E.P. Hynes]

On 08/24/2013 12:46 AM, Barry Margolin wrote:

In article mailman.1159.1377301811.20661.bind-us...@lists.isc.org,
  Mark Andrews ma...@isc.org wrote:


In message 52177d81.8020...@chrysler.com, Kevin Darcy writes:

On 8/22/2013 12:55 PM, jo...@primebuchholz.com wrote:

Greetings All,

First of all, I apologize if this is out of place - I'm having a very
strange issue that is either a problem with bind itself, or at least,
affecting it.  Summary:

For only ONE address, whenever I attempt to access it through my squid
proxy, the record disappears from DNS, and the retry time changes too.
Essentially, accessing www.thisdomain.com works, but a link to a portal
on
that page to the subdomain login.thisdomain.com causes the problem.  I'm
willing to bet the problem lies with squid, but as to how it could
possibly change a record in bind... Well, I'm stumped.  If you don't go
through squid, everything works.  All other requests to bind for the
address of the host in question work fine. Here's a the output of dig
from
before accessing the page through squid:

;  DiG 9.4.1-P1  login.thisdomain.com
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 45037
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;login.thisdomain.com.IN  A

;; ANSWER SECTION:
login.thisdomain.com. 17  IN  A   111.222.333.123

;; AUTHORITY SECTION:
thisdomain.com. 168319  IN  NS  ns1.thisdomain.com.
thisdomain.com. 168319  IN  NS  ns2.thisdomain.com.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 22 12:29:57 2013
;; MSG SIZE  rcvd: 88

You can do anything to request the address from bind and it works,
*except* try to access it through squid.  Bypassing squid and going
directly through the firewall works fine.

Now, immediately after you try to access it through squid:

;  DiG 9.4.1-P1  login.thisdomain.com
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 43943
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;login.thisdomain.com.IN  A

;; AUTHORITY SECTION:
thisdomain.com. 298 IN  SOA ns1.thisdomain.com.
serv.anotherdomain.com. 2006062510 3600 3600 2592000 300

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 22 12:30:06 2013
;; MSG SIZE  rcvd: 95

After the 5-minute retry shown above expires, the original record
reappears.

Ideas?  I'm stumped.  It seems like squid is somehow able to corrupt
bind's info, but I can't imagine how.

I have a theory. If this is a name that's hosted on a stupid
load-balancer, and that load-balancer doesn't understand non-A-record
query types, then if Squid is sending a non-A query type (e.g. SRV,
possibly even , if it's *really* stupid), then the load-balancer may
be erroneously poisoning your cache with an NXDOMAIN response.

We ran into this many years ago with Cisco GSSes (Global Site Selectors)
and work around it by having a shadow version of the zone, which the
GSSes proxy to for QTYPEs they don't handle. That shadow version of
the zone has a wildcard entry in it which forces responses to be NODATA
instead of NXDOMAIN, and this prevents the cache poisoning.

  - Kevin

The load balancer should be able to correct for such misconfigurations
by changing the rcode of the response from NXDOMAIN to NOERROR.  It
knows what names is is answering for so it can know that the NXDOMAIN
is a erroneous response.

If I understand what Kevin was saying, the load balancer IS the DNS
server. If you ask it for the A record it's responsible for, it sends a
reasonable reply. If you ask it for some other record type for that
name, it sends NXDOMAIN instead of NOERROR.

It's a design flaw in these load balancers.



Thanks everyone who's been helping with this.

In order to investigate this further, I did a tcpdump of both a 
working conversation of a browser requesting the site, not going 
through the squid proxy, and another of the broken conversation 
through the proxy.


Result:  There is an NXDOMAIN response to a request for an  record 
that the proxy makes that is causing this.  The browser never asks for 
anything but an A record, which succeeds.


I've contacted the site in question with this info, so hopefully it'll 
get resolved.  I'll keep the list posted on any results or info for 
posterity.


-John


--
Please consider the environment before printing this e-mail.

This e-mail is intended only for the named person or entity to which it
is addressed and contains valuable business information that is
privileged, confidential and/or otherwise protected from disclosure.
Dissemination, distribution or copying of this e-mail or the information
herein by anyone other than the intended recipient, 

Re: Strange problem with a query deleting a record...

[Gordon A. Lang]

Making some assumptions about where your dig queries are being sent, I would 
say it looks like the Squid is simply failing its DNS lookup (for whatever 
reason), then the Squid system is retaining a 5 minute negative cache.  If 
this is true, then the question would become why does the Squid system fail 
on that one lookups but (presumably) succeeds on others?


--
Gordon A. Lang

--
From: John E.P. Hynes jo...@primebuchholz.com
Sent: Saturday, August 24, 2013 8:55 AM
To: Barry Margolin bar...@alum.mit.edu
Cc: comp-protocols-dns-b...@isc.org; bind-us...@isc.org
Subject: Re: Strange problem with a query deleting a record...


On 08/24/2013 12:46 AM, Barry Margolin wrote:

In article mailman.1159.1377301811.20661.bind-us...@lists.isc.org,
  Mark Andrews ma...@isc.org wrote:


In message 52177d81.8020...@chrysler.com, Kevin Darcy writes:

On 8/22/2013 12:55 PM, jo...@primebuchholz.com wrote:

Greetings All,

First of all, I apologize if this is out of place - I'm having a very
strange issue that is either a problem with bind itself, or at least,
affecting it.  Summary:

For only ONE address, whenever I attempt to access it through my squid
proxy, the record disappears from DNS, and the retry time changes too.
Essentially, accessing www.thisdomain.com works, but a link to a 
portal

on
that page to the subdomain login.thisdomain.com causes the problem. 
I'm

willing to bet the problem lies with squid, but as to how it could
possibly change a record in bind... Well, I'm stumped.  If you don't 
go

through squid, everything works.  All other requests to bind for the
address of the host in question work fine. Here's a the output of dig
from
before accessing the page through squid:

;  DiG 9.4.1-P1  login.thisdomain.com
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 45037
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;login.thisdomain.com.IN  A

;; ANSWER SECTION:
login.thisdomain.com. 17  IN  A   111.222.333.123

;; AUTHORITY SECTION:
thisdomain.com. 168319  IN  NS  ns1.thisdomain.com.
thisdomain.com. 168319  IN  NS  ns2.thisdomain.com.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 22 12:29:57 2013
;; MSG SIZE  rcvd: 88

You can do anything to request the address from bind and it works,
*except* try to access it through squid.  Bypassing squid and going
directly through the firewall works fine.

Now, immediately after you try to access it through squid:

;  DiG 9.4.1-P1  login.thisdomain.com
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 43943
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;login.thisdomain.com.IN  A

;; AUTHORITY SECTION:
thisdomain.com. 298 IN  SOA ns1.thisdomain.com.
serv.anotherdomain.com. 2006062510 3600 3600 2592000 300

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 22 12:30:06 2013
;; MSG SIZE  rcvd: 95

After the 5-minute retry shown above expires, the original record
reappears.

Ideas?  I'm stumped.  It seems like squid is somehow able to corrupt
bind's info, but I can't imagine how.

I have a theory. If this is a name that's hosted on a stupid
load-balancer, and that load-balancer doesn't understand non-A-record
query types, then if Squid is sending a non-A query type (e.g. SRV,
possibly even , if it's *really* stupid), then the load-balancer 
may

be erroneously poisoning your cache with an NXDOMAIN response.

We ran into this many years ago with Cisco GSSes (Global Site 
Selectors)

and work around it by having a shadow version of the zone, which the
GSSes proxy to for QTYPEs they don't handle. That shadow version of
the zone has a wildcard entry in it which forces responses to be NODATA
instead of NXDOMAIN, and this prevents the cache poisoning.

  - Kevin

The load balancer should be able to correct for such misconfigurations
by changing the rcode of the response from NXDOMAIN to NOERROR.  It
knows what names is is answering for so it can know that the NXDOMAIN
is a erroneous response.

If I understand what Kevin was saying, the load balancer IS the DNS
server. If you ask it for the A record it's responsible for, it sends a
reasonable reply. If you ask it for some other record type for that
name, it sends NXDOMAIN instead of NOERROR.

It's a design flaw in these load balancers.



Thanks everyone who's been helping with this.

In order to investigate this further, I did a tcpdump of both a working 
conversation of a browser requesting the site, not going through the squid 
proxy, and another of the broken conversation through the proxy.


Result:  There is an NXDOMAIN response to a request for an  record 
that the proxy makes

Re: Strange problem with a query deleting a record...

[Barry Margolin]

In article mailman.1164.1377359473.20661.bind-us...@lists.isc.org,
 Gordon A. Lang gl...@goalex.com wrote:

 Making some assumptions about where your dig queries are being sent, I would 
 say it looks like the Squid is simply failing its DNS lookup (for whatever 
 reason), then the Squid system is retaining a 5 minute negative cache.  If 
 this is true, then the question would become why does the Squid system fail 
 on that one lookups but (presumably) succeeds on others?

The reason is that squid is requesting  records, and the broken DNS 
server (a load balancer, probably) is responding with NXDOMAIN instead 
of NOERROR.

Maybe there's a configuration option in squid that tells it not to try 
to use IPv6, so it won't request  records.

-- 
Barry Margolin
Arlington, MA
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Strange problem with a query deleting a record...

[Kevin Darcy]

On 8/22/2013 12:55 PM, jo...@primebuchholz.com wrote:

Greetings All,

First of all, I apologize if this is out of place - I'm having a very
strange issue that is either a problem with bind itself, or at least,
affecting it.  Summary:

For only ONE address, whenever I attempt to access it through my squid
proxy, the record disappears from DNS, and the retry time changes too.
Essentially, accessing www.thisdomain.com works, but a link to a portal on
that page to the subdomain login.thisdomain.com causes the problem.  I'm
willing to bet the problem lies with squid, but as to how it could
possibly change a record in bind... Well, I'm stumped.  If you don't go
through squid, everything works.  All other requests to bind for the
address of the host in question work fine. Here's a the output of dig from
before accessing the page through squid:

;  DiG 9.4.1-P1  login.thisdomain.com
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 45037
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;login.thisdomain.com.IN  A

;; ANSWER SECTION:
login.thisdomain.com. 17  IN  A   111.222.333.123

;; AUTHORITY SECTION:
thisdomain.com. 168319  IN  NS  ns1.thisdomain.com.
thisdomain.com. 168319  IN  NS  ns2.thisdomain.com.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 22 12:29:57 2013
;; MSG SIZE  rcvd: 88

You can do anything to request the address from bind and it works,
*except* try to access it through squid.  Bypassing squid and going
directly through the firewall works fine.

Now, immediately after you try to access it through squid:

;  DiG 9.4.1-P1  login.thisdomain.com
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 43943
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;login.thisdomain.com.IN  A

;; AUTHORITY SECTION:
thisdomain.com. 298 IN  SOA ns1.thisdomain.com.
serv.anotherdomain.com. 2006062510 3600 3600 2592000 300

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 22 12:30:06 2013
;; MSG SIZE  rcvd: 95

After the 5-minute retry shown above expires, the original record
reappears.

Ideas?  I'm stumped.  It seems like squid is somehow able to corrupt
bind's info, but I can't imagine how.
I have a theory. If this is a name that's hosted on a stupid 
load-balancer, and that load-balancer doesn't understand non-A-record 
query types, then if Squid is sending a non-A query type (e.g. SRV, 
possibly even , if it's *really* stupid), then the load-balancer may 
be erroneously poisoning your cache with an NXDOMAIN response.


We ran into this many years ago with Cisco GSSes (Global Site Selectors) 
and work around it by having a shadow version of the zone, which the 
GSSes proxy to for QTYPEs they don't handle. That shadow version of 
the zone has a wildcard entry in it which forces responses to be NODATA 
instead of NXDOMAIN, and this prevents the cache poisoning.


- Kevin
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Strange problem with a query deleting a record...

[Mark Andrews]

In message 52177d81.8020...@chrysler.com, Kevin Darcy writes:
 On 8/22/2013 12:55 PM, jo...@primebuchholz.com wrote:
  Greetings All,
 
  First of all, I apologize if this is out of place - I'm having a very
  strange issue that is either a problem with bind itself, or at least,
  affecting it.  Summary:
 
  For only ONE address, whenever I attempt to access it through my squid
  proxy, the record disappears from DNS, and the retry time changes too.
  Essentially, accessing www.thisdomain.com works, but a link to a portal on
  that page to the subdomain login.thisdomain.com causes the problem.  I'm
  willing to bet the problem lies with squid, but as to how it could
  possibly change a record in bind... Well, I'm stumped.  If you don't go
  through squid, everything works.  All other requests to bind for the
  address of the host in question work fine. Here's a the output of dig from
  before accessing the page through squid:
 
  ;  DiG 9.4.1-P1  login.thisdomain.com
  ;; global options:  printcmd
  ;; Got answer:
  ;; -HEADER- opcode: QUERY, status: NOERROR, id: 45037
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
 
  ;; QUESTION SECTION:
  ;login.thisdomain.com.IN  A
 
  ;; ANSWER SECTION:
  login.thisdomain.com. 17  IN  A   111.222.333.123
 
  ;; AUTHORITY SECTION:
  thisdomain.com. 168319  IN  NS  ns1.thisdomain.com.
  thisdomain.com. 168319  IN  NS  ns2.thisdomain.com.
 
  ;; Query time: 0 msec
  ;; SERVER: 127.0.0.1#53(127.0.0.1)
  ;; WHEN: Thu Aug 22 12:29:57 2013
  ;; MSG SIZE  rcvd: 88
 
  You can do anything to request the address from bind and it works,
  *except* try to access it through squid.  Bypassing squid and going
  directly through the firewall works fine.
 
  Now, immediately after you try to access it through squid:
 
  ;  DiG 9.4.1-P1  login.thisdomain.com
  ;; global options:  printcmd
  ;; Got answer:
  ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 43943
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
 
  ;; QUESTION SECTION:
  ;login.thisdomain.com.IN  A
 
  ;; AUTHORITY SECTION:
  thisdomain.com. 298 IN  SOA ns1.thisdomain.com.
  serv.anotherdomain.com. 2006062510 3600 3600 2592000 300
 
  ;; Query time: 0 msec
  ;; SERVER: 127.0.0.1#53(127.0.0.1)
  ;; WHEN: Thu Aug 22 12:30:06 2013
  ;; MSG SIZE  rcvd: 95
 
  After the 5-minute retry shown above expires, the original record
  reappears.
 
  Ideas?  I'm stumped.  It seems like squid is somehow able to corrupt
  bind's info, but I can't imagine how.
 I have a theory. If this is a name that's hosted on a stupid 
 load-balancer, and that load-balancer doesn't understand non-A-record 
 query types, then if Squid is sending a non-A query type (e.g. SRV, 
 possibly even , if it's *really* stupid), then the load-balancer may 
 be erroneously poisoning your cache with an NXDOMAIN response.
 
 We ran into this many years ago with Cisco GSSes (Global Site Selectors) 
 and work around it by having a shadow version of the zone, which the 
 GSSes proxy to for QTYPEs they don't handle. That shadow version of 
 the zone has a wildcard entry in it which forces responses to be NODATA 
 instead of NXDOMAIN, and this prevents the cache poisoning.
 
  - Kevin

The load balancer should be able to correct for such misconfigurations
by changing the rcode of the response from NXDOMAIN to NOERROR.  It
knows what names is is answering for so it can know that the NXDOMAIN
is a erroneous response.

Obviously this hack doesn't work for signed zones where the shadow
zone needs to have dummy records for the queries being answered by
the load balancer so that all the DNSSEC records are properly
consistent with the records being returned by the load balancer.

In either case the load balancer should be logging error or in the
DNSSEC case not answering anymore queries for the name until the
error is corrected.

Mark

 ___
 Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
  from this list
 
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Strange problem with a query deleting a record...

[Barry Margolin]

In article mailman.1159.1377301811.20661.bind-us...@lists.isc.org,
 Mark Andrews ma...@isc.org wrote:

 In message 52177d81.8020...@chrysler.com, Kevin Darcy writes:
  On 8/22/2013 12:55 PM, jo...@primebuchholz.com wrote:
   Greetings All,
  
   First of all, I apologize if this is out of place - I'm having a very
   strange issue that is either a problem with bind itself, or at least,
   affecting it.  Summary:
  
   For only ONE address, whenever I attempt to access it through my squid
   proxy, the record disappears from DNS, and the retry time changes too.
   Essentially, accessing www.thisdomain.com works, but a link to a portal 
   on
   that page to the subdomain login.thisdomain.com causes the problem.  I'm
   willing to bet the problem lies with squid, but as to how it could
   possibly change a record in bind... Well, I'm stumped.  If you don't go
   through squid, everything works.  All other requests to bind for the
   address of the host in question work fine. Here's a the output of dig 
   from
   before accessing the page through squid:
  
   ;  DiG 9.4.1-P1  login.thisdomain.com
   ;; global options:  printcmd
   ;; Got answer:
   ;; -HEADER- opcode: QUERY, status: NOERROR, id: 45037
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
  
   ;; QUESTION SECTION:
   ;login.thisdomain.com.IN  A
  
   ;; ANSWER SECTION:
   login.thisdomain.com. 17  IN  A   111.222.333.123
  
   ;; AUTHORITY SECTION:
   thisdomain.com. 168319  IN  NS  ns1.thisdomain.com.
   thisdomain.com. 168319  IN  NS  ns2.thisdomain.com.
  
   ;; Query time: 0 msec
   ;; SERVER: 127.0.0.1#53(127.0.0.1)
   ;; WHEN: Thu Aug 22 12:29:57 2013
   ;; MSG SIZE  rcvd: 88
  
   You can do anything to request the address from bind and it works,
   *except* try to access it through squid.  Bypassing squid and going
   directly through the firewall works fine.
  
   Now, immediately after you try to access it through squid:
  
   ;  DiG 9.4.1-P1  login.thisdomain.com
   ;; global options:  printcmd
   ;; Got answer:
   ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 43943
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
  
   ;; QUESTION SECTION:
   ;login.thisdomain.com.IN  A
  
   ;; AUTHORITY SECTION:
   thisdomain.com. 298 IN  SOA ns1.thisdomain.com.
   serv.anotherdomain.com. 2006062510 3600 3600 2592000 300
  
   ;; Query time: 0 msec
   ;; SERVER: 127.0.0.1#53(127.0.0.1)
   ;; WHEN: Thu Aug 22 12:30:06 2013
   ;; MSG SIZE  rcvd: 95
  
   After the 5-minute retry shown above expires, the original record
   reappears.
  
   Ideas?  I'm stumped.  It seems like squid is somehow able to corrupt
   bind's info, but I can't imagine how.
  I have a theory. If this is a name that's hosted on a stupid 
  load-balancer, and that load-balancer doesn't understand non-A-record 
  query types, then if Squid is sending a non-A query type (e.g. SRV, 
  possibly even , if it's *really* stupid), then the load-balancer may 
  be erroneously poisoning your cache with an NXDOMAIN response.
  
  We ran into this many years ago with Cisco GSSes (Global Site Selectors) 
  and work around it by having a shadow version of the zone, which the 
  GSSes proxy to for QTYPEs they don't handle. That shadow version of 
  the zone has a wildcard entry in it which forces responses to be NODATA 
  instead of NXDOMAIN, and this prevents the cache poisoning.
  
   - Kevin
 
 The load balancer should be able to correct for such misconfigurations
 by changing the rcode of the response from NXDOMAIN to NOERROR.  It
 knows what names is is answering for so it can know that the NXDOMAIN
 is a erroneous response.

If I understand what Kevin was saying, the load balancer IS the DNS 
server. If you ask it for the A record it's responsible for, it sends a 
reasonable reply. If you ask it for some other record type for that 
name, it sends NXDOMAIN instead of NOERROR.

It's a design flaw in these load balancers.

-- 
Barry Margolin
Arlington, MA
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Strange problem with a query deleting a record...

[johnh]

Greetings All,

First of all, I apologize if this is out of place - I'm having a very 
strange issue that is either a problem with bind itself, or at least, 
affecting it.  Summary:

For only ONE address, whenever I attempt to access it through my squid 
proxy, the record disappears from DNS, and the retry time changes too. 
Essentially, accessing www.thisdomain.com works, but a link to a portal on 
that page to the subdomain login.thisdomain.com causes the problem.  I'm 
willing to bet the problem lies with squid, but as to how it could 
possibly change a record in bind... Well, I'm stumped.  If you don't go 
through squid, everything works.  All other requests to bind for the 
address of the host in question work fine. Here's a the output of dig from 
before accessing the page through squid:

;  DiG 9.4.1-P1  login.thisdomain.com
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 45037
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;login.thisdomain.com.IN  A

;; ANSWER SECTION:
login.thisdomain.com. 17  IN  A   111.222.333.123

;; AUTHORITY SECTION:
thisdomain.com. 168319  IN  NS  ns1.thisdomain.com.
thisdomain.com. 168319  IN  NS  ns2.thisdomain.com.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 22 12:29:57 2013
;; MSG SIZE  rcvd: 88

You can do anything to request the address from bind and it works, 
*except* try to access it through squid.  Bypassing squid and going 
directly through the firewall works fine.

Now, immediately after you try to access it through squid:

;  DiG 9.4.1-P1  login.thisdomain.com
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 43943
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;login.thisdomain.com.IN  A

;; AUTHORITY SECTION:
thisdomain.com. 298 IN  SOA ns1.thisdomain.com. 
serv.anotherdomain.com. 2006062510 3600 3600 2592000 300

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 22 12:30:06 2013
;; MSG SIZE  rcvd: 95

After the 5-minute retry shown above expires, the original record 
reappears.

Ideas?  I'm stumped.  It seems like squid is somehow able to corrupt 
bind's info, but I can't imagine how.

-John

--
Please consider the environment before printing this e-mail.
 
This e-mail is intended only for the named person or entity to which it
is addressed and contains valuable business information that is
privileged, confidential and/or otherwise protected from disclosure.
Dissemination, distribution or copying of this e-mail or the information
herein by anyone other than the intended recipient, or an employee, or
agent responsible for delivering the message to the intended recipient,
is strictly prohibited.  All contents are the copyright property of the
sender.  If you are not the intended recipient, you are nevertheless
bound to respect the sender's worldwide legal rights.  We require that
unintended recipients delete the e-mail and destroy all electronic
copies in their system, retaining no copies in any media.  If you have
received this e-mail in error, please immediately notify us by calling
our Help Desk at (603) 433-1143, or e-mail to i...@primebuchholz.com.
We appreciate your cooperation.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

strange problem (SERVFAIL), but able to query google's DNS servers

[W S]

Folks - my DNS slaves are flooded with these [req from corp email gateways]:
 
query failed (SERVFAIL) for buildcount.com/IN/NS at query.c:4623
query failed (SERVFAIL) for rss.sina.com.cn/IN/A at query.c:4623
...
 
BUT if I query the very same Domain Names within googles' DNS - it's all good:
dig @8.8.8.8 buildcount.com
buildcount.com. 3600    IN  A   61.136.59.34
 
 
And of course, my systems are NOT able to resolve these and other names 
cause /etc/resolv.conf pointing to my local resolvers, this is just partial 
list:
 
host treesfresh.net
host rss.sina.com.cn
host twoproperitary.ru
host qq.com
host 53www.com
host exactshy.ru
host heldthem.ru

 
Are these misconfigured Domains - if so - then why Google's DNS able to resolve 
name, MX etc...and my DNS slaves 
 
 
Thanks a lot,
--Walter Smith

--- On Tue, 2/9/10, W S whatis...@yahoo.com wrote:


From: W S whatis...@yahoo.com
Subject: Re: strange problem with double CNAMEs ?
To: bind-users@lists.isc.org
Date: Tuesday, February 9, 2010, 4:08 PM







Is there anything I have to enable on my side to query these double CNAMEs?
 
dig @8.8.8.8 cdn2.example.com
cdn2.example.com 3600 IN CNAME cdn2.example2.com
cdn2.example2.com 3600 IN CNAME cdn3.example2.com
cdn3.example2.com 3600 IN A 1.2.3.4
 
Thanks a lot guys,
--WS

--- On Mon, 2/8/10, W S whatis...@yahoo.com wrote:


From: W S whatis...@yahoo.com
Subject: strange problem
To: bind-users@lists.isc.org
Date: Monday, February 8, 2010, 3:44 PM







Folks,
 
When I try to get an IP address for some sub-site/domain, let's say
cdn2.example.com --- I'm getting errors, BUT when I query
Google's DNS servers I'm getting an IP address:
 
dig @8.8.8.8 cdn2.example.com
cdn2.example.com 3600 IN CNAME cdn2.example2.com
cdn2.example2.com 3600 IN CNAME cdn3.example2.com
cdn3.example2.com 3600 IN A 1.2.3.4
 
This is my DNS configurations/errors:
 
#
/usr/local/bind/sbin/named -V
BIND 9.6.1-P3 built with '--prefix=/usr/local/bind' 
'--with-openssl=/usr/local/openssl' '--enable-fixed-rrset' '--disable-ipv6'
#
08-Feb-2010 15:13:01.479 query-errors: debug 1: client some_ip_addr#7074: 
query failed (SERVFAIL) for cdn2.example.com/IN/A at query.c:4623
08-Feb-2010 15:13:01.479 query-errors: debug 2: fetch completed at 
resolver.c:3119 for cdn2.example.com/A in 30.000908: timed out/success 
[domain:example.com,referral:1,restart:6,qrysent:13,timeout:9,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
#
at query.c:4623
~/bind-9.6.1-P3/bin/named/query.c
 default:
    /*
 * Something has gone wrong.
 */
    QUERY_ERROR(DNS_R_SERVFAIL);
    goto cleanup;
    }
#
at resolver.c:3119
~/bind-9.6.1-P3/lib/dns/resolver.c
  if (event-ev_type == ISC_TIMEREVENT_LIFE) {
    fctx-reason = NULL;
    fctx_done(fctx, ISC_R_TIMEDOUT, __LINE__);
#
 
 
Thanks,
--WS
 

-Inline Attachment Follows-


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

-Inline Attachment Follows-


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users



  ___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

strange problem

[W S]

Folks,
 
When I try to get an IP address for some sub-site/domain, let's say
cdn2.example.com --- I'm getting errors, BUT when I query
Google's DNS servers I'm getting an IP address:
 
dig @8.8.8.8 cdn2.example.com
cdn2.example.com 3600 IN CNAME cdn2.example2.com
cdn2.example2.com 3600 IN CNAME cdn3.example2.com
cdn3.example2.com 3600 IN A 1.2.3.4
 
This is my DNS configurations/errors:
 
#
/usr/local/bind/sbin/named -V
BIND 9.6.1-P3 built with '--prefix=/usr/local/bind' 
'--with-openssl=/usr/local/openssl' '--enable-fixed-rrset' '--disable-ipv6'
#
08-Feb-2010 15:13:01.479 query-errors: debug 1: client some_ip_addr#7074: 
query failed (SERVFAIL) for cdn2.example.com/IN/A at query.c:4623
08-Feb-2010 15:13:01.479 query-errors: debug 2: fetch completed at 
resolver.c:3119 for cdn2.example.com/A in 30.000908: timed out/success 
[domain:example.com,referral:1,restart:6,qrysent:13,timeout:9,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
#
at query.c:4623
~/bind-9.6.1-P3/bin/named/query.c
 default:
    /*
 * Something has gone wrong.
 */
    QUERY_ERROR(DNS_R_SERVFAIL);
    goto cleanup;
    }
#
at resolver.c:3119
~/bind-9.6.1-P3/lib/dns/resolver.c
  if (event-ev_type == ISC_TIMEREVENT_LIFE) {
    fctx-reason = NULL;
    fctx_done(fctx, ISC_R_TIMEDOUT, __LINE__);
#
 
 
Thanks,
--WS
 


  ___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: strange problem

[Jeremy C. Reed]

Please provide real names.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: strange problem

[W S]

--- On Mon, 2/8/10, W S whatis...@yahoo.com wrote:


From: W S whatis...@yahoo.com
Subject: Re: strange problem
To: Jeremy C. Reed jr...@isc.org
Date: Monday, February 8, 2010, 4:24 PM






$  dig @8.8.8.8  cdn2.totalporn.com
cdn2.totalporn.com. 3600    IN  CNAME   wac.1a2a.edgecastcdn.net.
wac.1a2a.edgecastcdn.net. 3600  IN  CNAME   gs1.wac.edgecastcdn.net.
gs1.wac.edgecastcdn.net. 3600   IN  A   72.21.91.20

--- On Mon, 2/8/10, Jeremy C. Reed jr...@isc.org wrote:


From: Jeremy C. Reed jr...@isc.org
Subject: Re: strange problem
To: W S whatis...@yahoo.com
Cc: bind-users@lists.isc.org
Date: Monday, February 8, 2010, 4:15 PM


Please provide real names.




  ___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users