date:20120717

9.8.2 Assertion Failures

2012-07-17 Thread Bailey, Morgan [BT]

Hi all

We have recently made some major changes to our DNS infrastructure.  This 
involved consolidating servers and standardizing on a single RHEL6 platform.  
We currently running the latest RHEL6 packaged BIND release of 9.8.2 
(9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6).  Lately on one of our busier names 
servers the named daemon has been crashing with assertion errors.  Here is a 
recent log snippet:

Jul 17 07:36:51 ks01 named[11224]: rbtdb.c:1619: INSIST(!((void 
*)((node)->deadlink.prev) != (void *)(-1))) failed, back trace
Jul 17 07:36:51 ks01 named[11224]: #0 0x7f8444865c2f in ??
Jul 17 07:36:51 ks01 named[11224]: #1 0x7f844321c89a in ??
Jul 17 07:36:51 ks01 named[11224]: #2 0x7f84440f2883 in ??
Jul 17 07:36:51 ks01 named[11224]: #3 0x7f84440f82cb in ??
Jul 17 07:36:51 ks01 named[11224]: #4 0x7f844415829f in ??
Jul 17 07:36:51 ks01 named[11224]: #5 0x7f844415e4c0 in ??
Jul 17 07:36:51 ks01 named[11224]: #6 0x7f844323b2f8 in ??
Jul 17 07:36:51 ks01 named[11224]: #7 0x7f8442bf0851 in ??
Jul 17 07:36:51 ks01 named[11224]: #8 0x7f844215367d in ??
Jul 17 07:36:51 ks01 named[11224]: exiting (due to assertion failure)
Jul 17 07:36:55 ks01 abrt[29353]: Saved core dump of pid 11224 
(/usr/sbin/named) to /var/spool/abrt/ccpp-2012-07-17-07:36:51-11224 (346398720 
bytes)
Jul 17 07:36:55 ks01 abrtd: Directory 'ccpp-2012-07-17-07:36:51-11224' creation 
detected

I did a little research and found a few forum posts where others were having 
the same or similar problems and the general consensus was that this was a 
problem that was fixed in 9.8.2.  Apparently my problem is slightly different 
or the issue wasn't fixed.

My questions are:

Is anyone else having this problem, and if so what did you do to remedy it?  
Also, I have the coredump.  Where should I send it for further analysis?

Morgan Bailey
Information Security Engineer
Office of Information Technology Services
785-296-3706

___
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: 9.8.2 Assertion Failures

2012-07-17 Thread Mark Andrews


In message , 
"Bailey, Morgan [BT]" writes:
> 
> Hi all
> 
> We have recently made some major changes to our DNS infrastructure.  This i=
> nvolved consolidating servers and standardizing on a single RHEL6 platform.=
>   We currently running the latest RHEL6 packaged BIND release of 9.8.2 (9.8=
> .2rc1-RedHat-9.8.2-0.10.rc1.el6).  Lately on one of our busier names server=
> s the named daemon has been crashing with assertion errors.  Here is a rece=
> nt log snippet:
> 
> Jul 17 07:36:51 ks01 named[11224]: rbtdb.c:1619: INSIST(!((void *)((node)->=
> deadlink.prev) !=3D (void *)(-1))) failed, back trace
> Jul 17 07:36:51 ks01 named[11224]: #0 0x7f8444865c2f in ??
> Jul 17 07:36:51 ks01 named[11224]: #1 0x7f844321c89a in ??
> Jul 17 07:36:51 ks01 named[11224]: #2 0x7f84440f2883 in ??
> Jul 17 07:36:51 ks01 named[11224]: #3 0x7f84440f82cb in ??
> Jul 17 07:36:51 ks01 named[11224]: #4 0x7f844415829f in ??
> Jul 17 07:36:51 ks01 named[11224]: #5 0x7f844415e4c0 in ??
> Jul 17 07:36:51 ks01 named[11224]: #6 0x7f844323b2f8 in ??
> Jul 17 07:36:51 ks01 named[11224]: #7 0x7f8442bf0851 in ??
> Jul 17 07:36:51 ks01 named[11224]: #8 0x7f844215367d in ??
> Jul 17 07:36:51 ks01 named[11224]: exiting (due to assertion failure)
> Jul 17 07:36:55 ks01 abrt[29353]: Saved core dump of pid 11224 (/usr/sbin/n=
> amed) to /var/spool/abrt/ccpp-2012-07-17-07:36:51-11224 (346398720 bytes)
> Jul 17 07:36:55 ks01 abrtd: Directory 'ccpp-2012-07-17-07:36:51-11224' crea=
> tion detected
> 
> I did a little research and found a few forum posts where others were havin=
> g the same or similar problems and the general consensus was that this was =
> a problem that was fixed in 9.8.2.  Apparently my problem is slightly diffe=
> rent or the issue wasn't fixed.
> 
> My questions are:
> 
> Is anyone else having this problem, and if so what did you do to remedy it?

You should install 9.8.2 or later.  You are currently running 9.8.2rc1.

>   Also, I have the coredump.  Where should I send it for further analysis?
> 
> Morgan Bailey
> Information Security Engineer
> Office of Information Technology Services
> 785-296-3706
> 
>
-- 
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: 9.8.2 Assertion Failures

2012-07-17 Thread Oscar Ricardo Silva


Bailey, Morgan [BT] wrote:

Hi all

 

We have recently made some major changes to our DNS infrastructure.  
This involved consolidating servers and standardizing on a single RHEL6 
platform.  We currently running the latest RHEL6 packaged BIND release 
of 9.8.2 (9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6).  Lately on one of our 
busier names servers the named daemon has been crashing with assertion 
errors.  Here is a recent log snippet:


 

Jul 17 07:36:51 ks01 named[11224]: rbtdb.c:1619: INSIST(!((void 
*)((node)->deadlink.prev) != (void *)(-1))) failed, back trace


Jul 17 07:36:51 ks01 named[11224]: #0 0x7f8444865c2f in ??

Jul 17 07:36:51 ks01 named[11224]: #1 0x7f844321c89a in ??

Jul 17 07:36:51 ks01 named[11224]: #2 0x7f84440f2883 in ??

Jul 17 07:36:51 ks01 named[11224]: #3 0x7f84440f82cb in ??

Jul 17 07:36:51 ks01 named[11224]: #4 0x7f844415829f in ??

Jul 17 07:36:51 ks01 named[11224]: #5 0x7f844415e4c0 in ??

Jul 17 07:36:51 ks01 named[11224]: #6 0x7f844323b2f8 in ??

Jul 17 07:36:51 ks01 named[11224]: #7 0x7f8442bf0851 in ??

Jul 17 07:36:51 ks01 named[11224]: #8 0x7f844215367d in ??

Jul 17 07:36:51 ks01 named[11224]: exiting (due to assertion failure)

Jul 17 07:36:55 ks01 abrt[29353]: Saved core dump of pid 11224 
(/usr/sbin/named) to /var/spool/abrt/ccpp-2012-07-17-07:36:51-11224 
(346398720 bytes)


Jul 17 07:36:55 ks01 abrtd: Directory 'ccpp-2012-07-17-07:36:51-11224' 
creation detected


 

I did a little research and found a few forum posts where others were 
having the same or similar problems and the general consensus was that 
this was a problem that was fixed in 9.8.2.  Apparently my problem is 
slightly different or the issue wasn’t fixed.


 


My questions are:

 

Is anyone else having this problem, and if so what did you do to remedy 
it?  Also, I have the coredump.  Where should I send it for further 
analysis?


 


Morgan Bailey

Information Security Engineer

Office of Information Technology Services

785-296-3706





Morgan,

This appears to be the same problem we're experiencing on RHEL6.  This 
bug WAS fixed in bind 9.8.2rc2 AND the final 9.8.2 BUT Redhat decided to 
use 9.8.2rc1 as the base for their bind package.  I can't shake my head 
enough trying to figure out why they would use a release candidate but 
that's what was done.


Anyway, Redhat is working on a patch for this and it should be released 
"soon".






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

DNSSEC for NS delegation record

2012-07-17 Thread Khuu, Linh Contractor

Hi,

I have questions about how to configure the DNS with NS delegation record once 
it's signed.

My DNS server is the parent zone, for example, "testing.net" and is signed  
with DNSSEC. My zone configuration is as follows:

$TTL 36000
$INCLUDE /var/named9/dnssec-testing/Ktesting.net..+007+32934.key ; key signing 
key
$INCLUDE /var/named9/dnssec-testing/Ktesting.net.+007+46725.key ; zone signing 
key
$INCLUDE /var/named9/dnssec-testing/Ktesting.net.+007+32367.key ; pre-published 
zone signing key
@ IN SOA dns1.testing.net. root.testing.net. (2011031200 3600 600 1209600 14400)

Testing.net. IN  NS  dns1.testing.net.
Testing.net. IN  NS  dns2.testing.net.
www   IN  A   168.168.168.168
access IN  NS   sub1.testing.net.

As of right now, the "sub1.testing.net" isn't DNSSEC compliant yet. We want 
sub1.testing.net to be DNSSEC aware.

My question is, do we (as parent of testing.net zone) need to generate the key 
(KSK) and zone key (ZSK) for the "sub1.testing.net" or should 
"sub1.testing.net" server will need to do that? If they generate the keys to 
sign all the records in their server, do they need to send us their key files? 
How do we (as parent) to include those keys in our zone file?

Thanks,
Linh Khuu



___
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: A lot of queries from a customer.

2012-07-17 Thread Fr34k

We have been monitoring the same.

Google found an unrelated, yet similar, issue a few years ago:  
http://pages.cs.wisc.edu/~plonka/netgear-sntp/#ToC16





>
> From: Rafael Molina 
>To: bind-users@lists.isc.org 
>Sent: Thursday, June 28, 2012 8:30 AM
>Subject: A lot of queries from a customer.
> 
>
>> Hi,
>> 
>> Recently, I have been watching on one DNS server a lot of queries from a 
>> customer to ¨time-b.netgear.com¨  (Maybe a Netgear´s NTP server).
>> 
>> About 1000 queries per minute.
>> 
>> tail -f /var/log/bind9-query.log | grep time-b.netgear.com
>> 
>> 21-Jun-2012 12:50:53.003 client 186.14.xx.xx#32770: query: 
>> time-b.netgear.com IN A + (10.1.xx.xx)
>> 21-Jun-2012 12:50:53.003 client 186.14.xx.xx#32770: query: 
>> time-b.netgear.com IN A + (10.1.xx.xx)
>> 21-Jun-2012 12:50:53.003 client 186.14.xx.xx#32770: query: 
>> time-b.netgear.com IN A + (10.1.xx.xx)
>> 21-Jun-2012 12:50:53.008 client 186.14.xx.xx#32770: query: 
>> time-b.netgear.com IN A + (10.1.xx.xx)
>> 21-Jun-2012 12:50:53.009 client 186.14.xx.xx#32770: query: 
>> time-b.netgear.com IN A + (10.1.xx.xx)
>> 21-Jun-2012 12:50:53.009 client 186.14.xx.xx#32770: query: 
>> time-b.netgear.com IN A + (10.1.xx.xx)
>> 21-Jun-2012 12:50:53.015 client 186.14.xx.xx#32770: query: 
>> time-b.netgear.com IN A + (10.1.xx.xx)
>> 21-Jun-2012 12:50:53.015 client 186.14.xx.xx#32770: query: 
>> time-b.netgear.com IN A + (10.1.xx.xx)
>> 21-Jun-2012 12:50:53.015 client 186.14.xx.xx#32770: query: 
>> time-b.netgear.com IN A + (10.1.xx.xx)
>> 
>> tcpdump -i eth0 port 53 and host 186.14.xx.xx
>> 
>> 12:54:28.375374 IP 186.14.xx.xx.32770 > inter.net.ve.domain: 16150+ A? 
>> time-b.netgear.com. (36)
>> 12:54:28.375479 IP 186.14.xx.xx.32770 > inter.net.ve.domain: 16150+ A? 
>> time-b.netgear.com. (36)
>> 12:54:28.375507 IP 186.14.xx.xx.32770 > inter.net.ve.domain: 16150+ A? 
>> time-b.netgear.com. (36)
>> 12:54:28.375553 IP 186.14.xx.xx.32770 > inter.net.ve.domain: 16150+ A? 
>> time-b.netgear.com. (36)
>> 12:54:28.375638 IP 186.14.xx.xx.32770 > inter.net.ve.domain: 44669+ A? 
>> time-b.netgear.com. (36)
>> 12:54:28.376424 IP inter.net.ve.domain > 186.14.xx.xx.32770: 16150 2/13/3 
>> CNAME nsone.netgear.com., A 209.249.181.21 (343)
>> 12:54:28.376525 IP inter.net.ve.domain > 186.14.xx.xx.32770: 16150 2/13/3 
>> CNAME nsone.netgear.com., A 209.249.181.21 (343)
>> 12:54:28.376807 IP inter.net.ve.domain > 186.14.xx.xx.32770: 16150 2/13/3 
>> CNAME nsone.netgear.com., A 209.249.181.21 (343)
>> 12:54:28.376845 IP inter.net.ve.domain > 186.14.xx.xx.32770: 16150 2/13/3 
>> CNAME nsone.netgear.com., A 209.249.181.21 (343)
>> 12:54:28.376906 IP inter.net.ve.domain > 186.14.xx.xx.32770: 44669 2/13/3 
>> CNAME nsone.netgear.com., A 209.249.181.21 (343)
>> 12:54:28.381638 IP 186.14.xx.xx.32770 > inter.net.ve.domain: 44669+ A? 
>> time-b.netgear.com. (36)
>> 12:54:28.381693 IP 186.14.xx.xx.32770 > inter.net.ve.domain: 62683+ A? 
>> time-b.netgear.com. (36)
>> 12:54:28.381745 IP 186.14.xx.xx.32770 > inter.net.ve.domain: 50898+ A? 
>> time-b.netgear.com. (36)
>> 12:54:28.381869 IP inter.net.ve.domain > 186.14.xx.xx.32770: 44669 2/13/3 
>> CNAME nsone.netgear.com., A 209.249.181.21 (343)
>> 12:54:28.382011 IP inter.net.ve.domain > 186.14.xx.xx.32770: 62683 2/13/3 
>> CNAME nsone.netgear.com., A 209.249.181.21 (343)
>> 12:54:28.382058 IP inter.net.ve.domain > 186.14.xx.xx.32770: 50898 2/13/3 
>> CNAME nsone.netgear.com., A 209.249.181.21 (343)
>> 
>> I don´t find the ways to limit of queries per minutes on this customer
>> Is it possible in Bind9 a filtering these queries, to limit the responses ?
>> 
>> Thank in advance,
>> 
>> Below, I´ve attached my configuration
>> 
>> OS: ubuntu 11.10
>> Bind: 9.7.3.dfsg-1ubuntu4.1
>> 
>> named.conf.options
>> 
>> allow-recursion { corp; };
>> allow-query-cache { corp; };
>> 
>> corp : clients.
>> 
>> allow-query { any; };
>>         clients-per-query 10 ;
>>         max-clients-per-query 20 ;
>>         blackhole { bogusnets; };
>>         version "I hope this is a joke !";
>>         edns-udp-size 512;
>>         max-udp-size 512;
>>         recursive-clients 1000;
>>   max-cache-size 500M;
>>         tcp-clients 500;
>>         max-cache-ttl 43200; # 12 Hours
>>         max-ncache-ttl 900; # 15 min
>> 
>> Saludos,
>> 
>> Atentamente,
>> Rafael J. Molina Q.
>> www.inter.com.ve
>> 
>> 
>
>
>
>___
>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

Re: A lot of queries from a customer.

2012-07-17 Thread Drunkard Zhang

2012/7/17 Fr34k :
> We have been monitoring the same.
>
> Google found an unrelated, yet similar, issue a few years ago:
> http://pages.cs.wisc.edu/~plonka/netgear-sntp/#ToC16
>
>
>> Hi,
>>
>> Recently, I have been watching on one DNS server a lot of queries from a
>> customer to ¨time-b.netgear.com¨  (Maybe a Netgear´s NTP server).
>>
>> About 1000 queries per minute.
>>
>> tail -f /var/log/bind9-query.log | grep time-b.netgear.com
>>
>> 21-Jun-2012 12:50:53.003 client 186.14.xx.xx#32770: query:
>> time-b.netgear.com IN A + (10.1.xx.xx)
>> 21-Jun-2012 12:50:53.003 client 186.14.xx.xx#32770: query:
>> time-b.netgear.com IN A + (10.1.xx.xx)
>> 21-Jun-2012 12:50:53.003 client 186.14.xx.xx#32770: query:
>> time-b.netgear.com IN A + (10.1.xx.xx)
>> 21-Jun-2012 12:50:53.008 client 186.14.xx.xx#32770: query:
>> time-b.netgear.com IN A + (10.1.xx.xx)
>> 21-Jun-2012 12:50:53.009 client 186.14.xx.xx#32770: query:
>> time-b.netgear.com IN A + (10.1.xx.xx)
>> 21-Jun-2012 12:50:53.009 client 186.14.xx.xx#32770: query:
>> time-b.netgear.com IN A + (10.1.xx.xx)
>> 21-Jun-2012 12:50:53.015 client 186.14.xx.xx#32770: query:
>> time-b.netgear.com IN A + (10.1.xx.xx)
>> 21-Jun-2012 12:50:53.015 client 186.14.xx.xx#32770: query:
>> time-b.netgear.com IN A + (10.1.xx.xx)
>> 21-Jun-2012 12:50:53.015 client 186.14.xx.xx#32770: query:
>> time-b.netgear.com IN A + (10.1.xx.xx)
>>
>> tcpdump -i eth0 port 53 and host 186.14.xx.xx
>>
>> 12:54:28.375374 IP 186.14.xx.xx.32770 > inter.net.ve.domain: 16150+ A?
>> time-b.netgear.com. (36)
>> 12:54:28.375479 IP 186.14.xx.xx.32770 > inter.net.ve.domain: 16150+ A?
>> time-b.netgear.com. (36)
>> 12:54:28.375507 IP 186.14.xx.xx.32770 > inter.net.ve.domain: 16150+ A?
>> time-b.netgear.com. (36)
>> 12:54:28.375553 IP 186.14.xx.xx.32770 > inter.net.ve.domain: 16150+ A?
>> time-b.netgear.com. (36)
>> 12:54:28.375638 IP 186.14.xx.xx.32770 > inter.net.ve.domain: 44669+ A?
>> time-b.netgear.com. (36)
>> 12:54:28.376424 IP inter.net.ve.domain > 186.14.xx.xx.32770: 16150 2/13/3
>> CNAME nsone.netgear.com., A 209.249.181.21 (343)
>> 12:54:28.376525 IP inter.net.ve.domain > 186.14.xx.xx.32770: 16150 2/13/3
>> CNAME nsone.netgear.com., A 209.249.181.21 (343)
>> 12:54:28.376807 IP inter.net.ve.domain > 186.14.xx.xx.32770: 16150 2/13/3
>> CNAME nsone.netgear.com., A 209.249.181.21 (343)
>> 12:54:28.376845 IP inter.net.ve.domain > 186.14.xx.xx.32770: 16150 2/13/3
>> CNAME nsone.netgear.com., A 209.249.181.21 (343)
>> 12:54:28.376906 IP inter.net.ve.domain > 186.14.xx.xx.32770: 44669 2/13/3
>> CNAME nsone.netgear.com., A 209.249.181.21 (343)
>> 12:54:28.381638 IP 186.14.xx.xx.32770 > inter.net.ve.domain: 44669+ A?
>> time-b.netgear.com. (36)
>> 12:54:28.381693 IP 186.14.xx.xx.32770 > inter.net.ve.domain: 62683+ A?
>> time-b.netgear.com. (36)
>> 12:54:28.381745 IP 186.14.xx.xx.32770 > inter.net.ve.domain: 50898+ A?
>> time-b.netgear.com. (36)
>> 12:54:28.381869 IP inter.net.ve.domain > 186.14.xx.xx.32770: 44669 2/13/3
>> CNAME nsone.netgear.com., A 209.249.181.21 (343)
>> 12:54:28.382011 IP inter.net.ve.domain > 186.14.xx.xx.32770: 62683 2/13/3
>> CNAME nsone.netgear.com., A 209.249.181.21 (343)
>> 12:54:28.382058 IP inter.net.ve.domain > 186.14.xx.xx.32770: 50898 2/13/3
>> CNAME nsone.netgear.com., A 209.249.181.21 (343)
>>
>> I don´t find the ways to limit of queries per minutes on this customer
>> Is it possible in Bind9 a filtering these queries, to limit the responses
>> ?
>>

We use iptables doing this, which works fine for us:
iptables -A INPUT -p udp -m state --state NEW -m connlimit
--connlimit-upto 500 --connlimit-mask 32 --connlimit-saddr -m udp
--dport 53 -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW -m connlimit
--connlimit-upto 200 --connlimit-mask 32 --connlimit-saddr -m tcp
--dport 53 -j ACCEPT

Hope it's useful for you ;)

>> Thank in advance,
>>
>> Below, I´ve attached my configuration
>>
>> OS: ubuntu 11.10
>> Bind: 9.7.3.dfsg-1ubuntu4.1
>>
>> named.conf.options
>>
>> allow-recursion { corp; };
>> allow-query-cache { corp; };
>>
>> corp : clients.
>>
>> allow-query { any; };
>>clients-per-query 10 ;
>>max-clients-per-query 20 ;
>>blackhole { bogusnets; };
>>version "I hope this is a joke !";
>>edns-udp-size 512;
>>max-udp-size 512;
>>recursive-clients 1000;
>>  max-cache-size 500M;
>>tcp-clients 500;
>>max-cache-ttl 43200; # 12 Hours
>>max-ncache-ttl 900; # 15 min
>>
___
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: A lot of queries from a customer.

2012-07-17 Thread Paul Wouters


On Tue, 17 Jul 2012, Drunkard Zhang wrote:


I don´t find the ways to limit of queries per minutes on this customer
Is it possible in Bind9 a filtering these queries, to limit the responses


We use iptables doing this, which works fine for us:
iptables -A INPUT -p udp -m state --state NEW -m connlimit
--connlimit-upto 500 --connlimit-mask 32 --connlimit-saddr -m udp
--dport 53 -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW -m connlimit
--connlimit-upto 200 --connlimit-mask 32 --connlimit-saddr -m tcp
--dport 53 -j ACCEPT


You realise that this could just cause you more queries right?

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

redhat package versions [ was Re: 9.8.2 Assertion Failures ]

2012-07-17 Thread Michael Hoskins (michoski)

turning a dead horse into a wet spot on the ground (in-line)...

-Original Message-
From: Oscar Ricardo Silva 
Date: Tuesday, July 17, 2012 7:13 AM
To: "'bind-users@lists.isc.org'" 
Subject: Re: 9.8.2 Assertion Failures

>Bailey, Morgan [BT] wrote:
>> Hi all
>> 
>>  
>> 
>> We have recently made some major changes to our DNS infrastructure.
>> This involved consolidating servers and standardizing on a single RHEL6
>> platform.  We currently running the latest RHEL6 packaged BIND release
>> of 9.8.2 (9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6).  Lately on one of our
>> busier names servers the named daemon has been crashing with assertion
>> errors.  Here is a recent log snippet:
>> 
>>  
>This appears to be the same problem we're experiencing on RHEL6.  This
>bug WAS fixed in bind 9.8.2rc2 AND the final 9.8.2 BUT Redhat decided to
>use 9.8.2rc1 as the base for their bind package.  I can't shake my head
>enough trying to figure out why they would use a release candidate but
>that's what was done.
>
>Anyway, Redhat is working on a patch for this and it should be released
>"soon".
>
>

just to ensure it's clear for posterity (i've seen it mis-stated a few
times)...  and to point out another common frustration with RHEL -- the
package version itself of "9.8.2rc2" is no real indication of what version
you're running on this platform.  you have to dig through the errata on
RHN to figure out what patches your sub-package (e.g. -0.10) actually
contains.  within the RHEL community you can find lots of vehement
advocacy for this approach, and i really don't want to be involved in that
argument, but for the most part it makes RHEL version numbers meaningless
to the larger community.

i am glad to see there's an official fix in the pipeline...but this
frustration is one reason we maintain our own packages.  with the tarballs
and easy build process from ISC, generating the required spec file is
easy...and lets you control pre/post-install steps.  it's also easy to
host your own yum repo, and tie that into cfengine, puppet, etc.

___
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

Fordwarder and stub records

2012-07-17 Thread nex6


when should you use forwarding records/zones or stub records/zones? and how 
does using them effect client lookups? or, effect the
name server doing the forwarding?

for example, say you have a two groups who both have the same parent... say:

parent.com

but group1  @  group1.parent.com owns all the "clients" and even group2 is a 
client, but group2 has its own zone.
so, group2 wants a forwarder on group1 name server, so the client lookups never 
have to goto parent.com.


so the top question of when do you use these kinds of records and zones, and in 
the example is it good to forward? or not



-Nex6


___
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

port 53 tcp/udp

2012-07-17 Thread nex6

when does bind or dns in general use tcp and when does it use udp?

from what i have read, from the client intial request if under 512b come in on 
UDP port 53, if and depending on the local
resolver in needs to retry it *could* be a tcp port 53 request?

now thats client to name server;


what about, recursive lookups? or forwarded requests? etc 


how does that work?




-Nex6


___
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: port 53 tcp/udp

2012-07-17 Thread Mark Andrews


In message <20120717194840.GA3773@glasya2>, nex6 writes:
> when does bind or dns in general use tcp and when does it use udp?

When it needs to.  TCP support is NOT optional.
 
> from what i have read, from the client intial request if under 512b
> come in on UDP port 53, if and depending on the local
> resolver in needs to retry it *could* be a tcp port 53 request?
> 
> now thats client to name server;
> 
> 
> what about, recursive lookups? or forwarded requests? etc 

It's still client to server.  Recursive servers have a client side
and a server side.

> how does that work?

Exactly the same why.
 
> -Nex6
> 
> 
> ___
> 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: port 53 tcp/udp

2012-07-17 Thread nex6

* Mark Andrews  [2012-07-18 07:43:34 +1000]:

> 
> In message <20120717194840.GA3773@glasya2>, nex6 writes:
> > when does bind or dns in general use tcp and when does it use udp?
> 
> When it needs to.  TCP support is NOT optional.
>  
> > from what i have read, from the client intial request if under 512b
> > come in on UDP port 53, if and depending on the local
> > resolver in needs to retry it *could* be a tcp port 53 request?
> > 
> > now thats client to name server;
> > 
> > 
> > what about, recursive lookups? or forwarded requests? etc 
> 
> It's still client to server.  Recursive servers have a client side
> and a server side.
> 
> > how does that work?
> 
> Exactly the same why.
>  
> > -Nex6

Thanks for the reply, i have an internal client with there own NS that is 
blocking TCP port 53, and complaining of random
issues. like our NS not sending them traffic randomly.

I told them to unblock port 53 tcp then call me



> > 
> > 
> > ___
> > 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: port 53 tcp/udp

2012-07-17 Thread nex6

* Lance Bailey  [2012-07-17 14:50:43 -0700]:

> On Tuesday, July 17, 2012 2:43:34 PM UTC-7, Mark Andrews wrote:
> > In message <20120717194840.GA3773@glasya2>, nex6 writes:
> > > when does bind or dns in general use tcp and when does it use udp?
> > 
> > When it needs to.  TCP support is NOT optional.
> 
> In particular for notification of secondaries and the subsequent xfer request 
> sequence both TCP and UDP are used. without both, the sequence does not work.


Thanks, for the reply. 




___
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: DNSSEC for NS delegation record

2012-07-17 Thread Mark Andrews


In message <349af545493290449749762c5f03929a0cf3bcc...@hq-mb-08.ba.ad.ssa.gov>, 
"Khuu, Linh Contractor" writes:
> Hi,
> 
> I have questions about how to configure the DNS with NS delegation record o=
> nce it's signed.
> 
> My DNS server is the parent zone, for example, "testing.net" and is signed =
>  with DNSSEC. My zone configuration is as follows:
> 
> $TTL 36000
> $INCLUDE /var/named9/dnssec-testing/Ktesting.net..+007+32934.key ; key sign=
> ing key
> $INCLUDE /var/named9/dnssec-testing/Ktesting.net.+007+46725.key ; zone sign=
> ing key
> $INCLUDE /var/named9/dnssec-testing/Ktesting.net.+007+32367.key ; pre-publi=
> shed zone signing key
> @ IN SOA dns1.testing.net. root.testing.net. (2011031200 3600 600 1209600 1=
> 4400)
> 
> Testing.net. IN  NS  dns1.testing.net.
> Testing.net. IN  NS  dns2.testing.net.
> www   IN  A   168.168.168.168
> access IN  NS   sub1.testing.net.
> 
> As of right now, the "sub1.testing.net" isn't DNSSEC compliant yet. We want=
>  sub1.testing.net to be DNSSEC aware.
> 
> My question is, do we (as parent of testing.net zone) need to generate the =
> key (KSK) and zone key (ZSK) for the "sub1.testing.net" or should "sub1.tes=
> ting.net" server will need to do that? If they generate the keys to sign al=
> l the records in their server, do they need to send us their key files? How=
>  do we (as parent) to include those keys in our zone file?

The child generates its own keys and sends the DNSKEY and/or matching
DS record to the parent.  It is the DS record that gets added to
the parent zone to make a secure delegation.  DS records are computed
from the DNSKEY record.

> Thanks,
> Linh Khuu
-- 
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: port 53 tcp/udp

2012-07-17 Thread Doug Barton

On 07/17/2012 03:07 PM, nex6 wrote:
> I told them to unblock port 53 tcp then call me

Good answer. :)
___
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

rndc stats command

2012-07-17 Thread Ben


Hi,

As per man page and my understanding rndc stats writes a current named 
statistics into defined file in named.conf


so suppose, if i run rndc stats command and then i take required 
information from named statistics file.


And after some time, ( after 5 minutes or approx.) when i do again rndc 
stats , so that times it provides new statistics.?


My understanding is that while running rndc stats , it writes current 
named statistics to defined file and internally it flush named 
statistics ( which wrote into file as per named.conf )


And while second time run same command , again it append fresh/new named 
statistics to defined fiel, is it so?


Or is there any interval for rndc / named to generate fresh/new statistics.?

Kindly correct me if I am missing something...


Regards,
Ben
___
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: DNSSEC for NS delegation record

2012-07-17 Thread Marc Lampo

Hello,



(the easiest way)

1)  The admins of sub1.testing.net. should generate ZSK and KSK.
à The parent cannot do this for the child

2)  You do not need the key file*s* of the child, in the parent.
If, by using the plural form, you mean both public (.key) and private
(.private) file.

3)  The easiest way : using the bind tools (and this is the bind
mailing list)
the child will find a dsset- file after signing its zone
à the parent can include *this* file in its testing.net zone

Alternatively :
The child can provide the public part of the KSK
and, using the bind tool dnssec-dsfromkey the parent can obtain the DS
records itself.

4)  How to include :
you are already using $INCLUDE statements now, so, include the file with
DS info, Id say.





One additional comment :

By signing the child  sub1.testing.net.  only, not much will happen,
for DNSSEC.
You need to complete the chain of trust by also signing the parent 
testing.net. -
and having its DS information published in its parent  net. !





Kind regards,







Marc Lampo

Security Officer



EURid



From: Khuu, Linh Contractor [mailto:linh.k...@ssa.gov]
Sent: dinsdag 17 juli 2012 16:36
To: 'bind-users@lists.isc.org'
Subject: DNSSEC for NS delegation record



Hi,



I have questions about how to configure the DNS with NS delegation record
once its signed.



My DNS server is the parent zone, for example, testing.net and is signed
with DNSSEC. My zone configuration is as follows:



$TTL 36000

$INCLUDE /var/named9/dnssec-testing/Ktesting.net..+007+32934.key ; key
signing key

$INCLUDE /var/named9/dnssec-testing/Ktesting.net.+007+46725.key ; zone
signing key

$INCLUDE /var/named9/dnssec-testing/Ktesting.net.+007+32367.key ;
pre-published zone signing key

@ IN SOA dns1.testing.net. root.testing.net. (2011031200 3600 600 1209600
14400)



Testing.net. IN  NS  dns1.testing.net.

Testing.net. IN  NS  dns2.testing.net.

www   IN  A   168.168.168.168

access IN  NS   sub1.testing.net.



As of right now, the sub1.testing.net isnt DNSSEC compliant yet. We
want sub1.testing.net to be DNSSEC aware.



My question is, do we (as parent of testing.net zone) need to generate the
key (KSK) and zone key (ZSK) for the sub1.testing.net or should
sub1.testing.net server will need to do that? If they generate the keys
to sign all the records in their server, do they need to send us their key
files? How do we (as parent) to include those keys in our zone file?



Thanks,

Linh Khuu





___
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

Fwd: Fwd: disabling "Any" requests

2012-07-17 Thread Dns Administrator

Hi
I though that it was a bit drastic removing the requests with iptables
I altered the code slightly - it appears to have the desired effect

ns_query_start() from query.c

  if (dns_rdatatype_ismeta(qtype)) {
switch (qtype) {
case dns_rdatatype_any:
/* break; Let query_find handle it. */
ns_client_next(client, ISC_R_NOTIMPLEMENTED);
return;
case dns_rdatatype_ixfr:
case dns_rdatatype_axfr:
ns_xfr_start(client, rdataset->type);
return;
case dns_rdatatype_maila:
case dns_rdatatype_mailb:
query_error(client, DNS_R_NOTIMP, __LINE__);
return;
case dns_rdatatype_tkey:
result = dns_tkey_processquery(client->message,
ns_g_server->tkeyctx,
client->view->dynamickeys);
if (result == ISC_R_SUCCESS)
query_send(client);
else
query_error(client, result, __LINE__);
return;
default: /* TSIG, etc. */
query_error(client, DNS_R_FORMERR, __LINE__);
return;
}
}



-- Forwarded message --
From: 
Date: Fri, Jul 13, 2012 at 2:55 PM
Subject: Re: Fwd: disabling "Any" requests
To: Dns Administrator 


Peter wrote on 07/13/2012 04:26:55 AM:

> ps I haven't stumbled across any coax cabling since the last millenium

Wirecutters work on twisted pair just as well.  And as a extra bonus, they
work on fiber cables too!



Confidentiality Notice:
This electronic message and any attachments may contain confidential or
privileged information, and is intended only for the individual or entity
identified above as the addressee. If you are not the addressee (or the
employee or agent responsible to deliver it to the addressee), or if this
message has been addressed to you in error, you are hereby notified that
you may not copy, forward, disclose or use any part of this message or any
attachments. Please notify the sender immediately by return e-mail or
telephone and delete this message from your system.
___
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

9.8.2 Assertion Failures

Re: 9.8.2 Assertion Failures

Re: 9.8.2 Assertion Failures

DNSSEC for NS delegation record

Re: A lot of queries from a customer.

Re: A lot of queries from a customer.

Re: A lot of queries from a customer.

redhat package versions [ was Re: 9.8.2 Assertion Failures ]

Fordwarder and stub records

port 53 tcp/udp

Re: port 53 tcp/udp

Re: port 53 tcp/udp

Re: port 53 tcp/udp

Re: DNSSEC for NS delegation record

Re: port 53 tcp/udp

rndc stats command

RE: DNSSEC for NS delegation record

Fwd: Fwd: disabling "Any" requests

18 matches

Site Navigation

Mail list logo

Footer information