Hi,
Does “a successful IXFR transfer” include “AXFR-style IXFR” ?
Thanks,
T. Matsumoto
From: bind-users-bounces+tmatsumo=yahoo-corp...@lists.isc.org
[mailto:bind-users-bounces+tmatsumo=yahoo-corp...@lists.isc.org] On Behalf Of
Larissa Shapiro
Sent: Wednesday, February 23, 2011 5:56 AM
To: bin
> Hi Dennis,
>
> Thank you for getting 9.7.3 out on Solaris, that is a huge help in
> getting this important update out there.
I have been running 9.7.3 for a few days now on all my production DNS
servers ( a bunch ) and a few in client sites in Europe. All seems to be
running very well and the u
Hi Dennis,
Thank you for getting 9.7.3 out on Solaris, that is a huge help in
getting this important update out there.
I do not know the answer to your question about the NIST CVE listings,
but I will inquire. Our CVE numbers actually come to us from
Carnegie-Mellon CERT, not NIST, but NIST does
Sorry for the top post but there is no data yet at
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-0414. I'll assume
that is coming along. I have 9.7.3 ready for relase on Solaris 8 and 9 and
10 however I wanted to refer to the various security info sites.
Do you know if the folks at nis
In message <0539E64AD2B54AD2804C2394F923800B@se179>, "Shaoquan Lin" writes:
> Mark,
>
> Are these bugs (2784 and 1804) fixed by BIND 9.6.1-P3? My problem is that I
> can not get A records of NSs (like vwall4a.nyc.gov) of nyc.gov from
> b.gov-servers.net by BIND 9.6.1-P3 but with no problem with
On 2/22/2011 7:29 AM, Terry. wrote:
Hello,
Given I have these MX records:
example.com.3600IN MX 10 m1.example.com.
example.com.3600IN MX 10 m2.example.com.
example.com.3600IN MX 20 m3.example.com.
My question is, when m1.exa
Internet Systems Consortium Security
Advisory
Title: Server Lockup Upon IXFR or DDNS Update Combined with High Query Rate
(http://www.isc.org/software/bind/advisories/cve-2011-0414)
CVE-2011-0414
VU#559980
CVSS: 7.1 (AV:N/AC:M/Au:N/C:N/I:N/A:C)
for more inf
Running 9.6.1-P1 on CentOS 5 with 8 CPU cores. We're anycasting our DNS
service
address. We observe the UDP Recv-Q get as high as 109540 and 2-4 second
response times. The simplest fix is to simply restart the bind process. When
the response time is slow on the DNS service address, I can do
Mark,
Are these bugs (2784 and 1804) fixed by BIND 9.6.1-P3? My problem is that I
can not get A records of NSs (like vwall4a.nyc.gov) of nyc.gov from
b.gov-servers.net by BIND 9.6.1-P3 but with no problem with older BINDs like
9.3. I don't know if the problem is with the authoritative namese
On 22.02.11 20:29, Terry. wrote:
> Given I have these MX records:
>
> example.com.3600IN MX 10 m1.example.com.
> example.com.3600IN MX 10 m2.example.com.
> example.com.3600IN MX 20 m3.example.com.
>
>
> My question is, when m1.
Dnia 2011-02-22 13:29 Eivind Olsen napisał(a):
>On Tue, 22 Feb 2011 08:59:51 +0100, "Torinthiel"
>wrote:
>> Hmm, looks to me as the box listed as client sends some strange notify
>> messages. Notify normally should contain SOA, so that receiving NS can
>> tell if it has outdated zone or no. Thes
Dnia 2011-02-22 20:29 Terry. napisał(a):
>Hello,
>
>Given I have these MX records:
>
>example.com.3600IN MX 10 m1.example.com.
>example.com.3600IN MX 10 m2.example.com.
>example.com.3600IN MX 20 m3.example.com.
>
>
>My question
Hello,
I don't think BIND is the problem, here.
Are the network and attached devices (routers/firewalls/switches/ISP) IPv6
ready ?
That might prove to be harder.
(at least : here in Belgium, our ISP's, for commercial connections are not
in a hurry to offer IPv6 connectivity)
Kind rega
2011/2/22 Florian Weimer :
> * Drunkard Zhang:
>
>> My capture command: tcpdump -s 0 -nnnvvv -w 360.cn-`date +%Y%m%d`.pcap
>> udp port 53
>>
>> 17:59:36 ~ $ dig +nocmd speedtest.360.cn @211.161.192.1 +multiline
>> +noall +answer
>> speedtest.360.cn. 215 IN CNAME speedtest.360.cn.cloudcdn.net.
>
On Tue, 22 Feb 2011 08:59:51 +0100, "Torinthiel"
wrote:
> Hmm, looks to me as the box listed as client sends some strange notify
> messages. Notify normally should contain SOA, so that receiving NS can
> tell if it has outdated zone or no. These don't. What (regarding DNS of
> course) is on those
Hello,
Given I have these MX records:
example.com.3600IN MX 10 m1.example.com.
example.com.3600IN MX 10 m2.example.com.
example.com.3600IN MX 20 m3.example.com.
My question is, when m1.example.com is failed to communicate with
Dnia 2011-02-22 22:16 Mark Andrews napisał(a):
>In message , hugo hugoo writes:
>> Dear all,
>>
>> In the scope of the IPV6 deployment, I have been asked if oiyr DNS server
>> s are IPV6 compliant.
>> We are now upgrading all our servers to bind-9.6-ESV-R3.
>>
>> - Can anybody give some feedb
* Drunkard Zhang:
> My capture command: tcpdump -s 0 -nnnvvv -w 360.cn-`date +%Y%m%d`.pcap
> udp port 53
>
> 17:59:36 ~ $ dig +nocmd speedtest.360.cn @211.161.192.1 +multiline
> +noall +answer
> speedtest.360.cn. 215 IN CNAME speedtest.360.cn.cloudcdn.net.
> speedtest.360.cn.cloudcdn.net. 325
In message , hugo hugoo writes:
> Dear all,
>
> In the scope of the IPV6 deployment, I have been asked if oiyr DNS server
> s are IPV6 compliant.
> We are now upgrading all our servers to bind-9.6-ESV-R3.
>
> - Can anybody give some feedback on the IPV6 compliancy?
>IS bind-9.6-ESV-R3 tota
Dear all,
In the scope of the IPV6 deployment, I have been asked if oiyr DNS servers are
IPV6 compliant.
We are now upgrading all our servers to bind-9.6-ESV-R3.
- Can anybody give some feedback on the IPV6 compliancy?
IS bind-9.6-ESV-R3 totally compliant with IPV6?
Thanks in advance to
The upstream DNS server 211.161.192.1 did responsed correctly, by
analysis via tcpdump. But why bind didn't use THE RESPONSE, but
resolves again from root-servers.
>>>
>>> Unfortunately, the information provided by 211.161.192.1 must be
>>> discarded because that is server is not au
* Drunkard Zhang:
> 2011/2/22 Florian Weimer :
>> * Drunkard Zhang:
>>
>>> The upstream DNS server 211.161.192.1 did responsed correctly, by
>>> analysis via tcpdump. But why bind didn't use THE RESPONSE, but
>>> resolves again from root-servers.
>>
>> Unfortunately, the information provided by 2
2011/2/22 Florian Weimer :
> * Drunkard Zhang:
>
>> The upstream DNS server 211.161.192.1 did responsed correctly, by
>> analysis via tcpdump. But why bind didn't use THE RESPONSE, but
>> resolves again from root-servers.
>
> Unfortunately, the information provided by 211.161.192.1 must be
> disca
* Drunkard Zhang:
> The upstream DNS server 211.161.192.1 did responsed correctly, by
> analysis via tcpdump. But why bind didn't use THE RESPONSE, but
> resolves again from root-servers.
Unfortunately, the information provided by 211.161.192.1 must be
discarded because that is server is not aut
9.7.2-P3-debug3
Description: Binary data
360.cn-20110222.pcap
Description: Binary data
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
On 02/22/11 01:41, Eivind Olsen wrote:
> Hello. I've recently put into production a new recursive nameserver, and
> decided to take a look in the logfiles (the old servers didn't have
> logging enabled so I can't really compare the current logs with whatever
> the old ones would have been).
> I und
26 matches
Mail list logo
