Clarification on delegated NS
Hi , When I created delegated NS record. Bind 9.7.1 p3 is giving SERVFAIL , when i queried for NS delegated record with NS. Could you please clarify me or is it bug in 9.7? Thanks & Regards, Ramesh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.7.1-P2 startup: unable to set effective gid to 0
We are also facing the same issue that AJ wrote previously. We are trying to upgrade from bind version 9.4.3-P3 to 9.7.2-P2 using with chroot environment on a Solaris 9. It never see the following warning message when bind 9.4.3-P3 running on a our solaris 9 server, but 9.7.1-P2, 9.7.2rc1 and 9.7.2-P2 show same warning message; [ID 873579 daemon.notice] starting BIND 9.7.2-P2 -u named -t /var/named/chroot [ID 873579 daemon.notice] built with '--exec-prefix=/opt/bind-9.7.2-P2' '--without-openssl' '--disable-ipv6' [ID 873579 daemon.warning] unable to set effective gid to 0: Not owner Sep 29 15:20:34 dns1 last message repeated 1 time [ID 873579 daemon.notice] command channel listening on 127.0.0.1#953 Our bind be starting with following parameters on a our server; /opt/bind/sbin/named -u named -t /var/named/chroot & Our chroot directory on a our server have respectively set to; drwxr-xr-x 3 namednamed 512 /var/named/ drwx-- 6 namednamed512 /var/named/chroot/ drwx-- 4 namednamed512 /var/named/chroot/var/ drwx-- 5 namednamed 1536 /var/named/chroot/var/named/ . Our named user have set to; # grep named /etc/passwd named:x:53:53::/var/named:/bin/false # grep named /etc/group named::53: . Does anyone help how this warning message do repress? Thanks for advance -- Takashi M. - Original Message - From: "aldus jung" To: Sent: Saturday, September 18, 2010 8:13 AM Subject: Re: bind 9.7.1-P2 startup: unable to set effective gid to 0 Just a follow up, I've added some debug statements to bin/named/unix/os.c to see the files that named is trying to set the effective gid for, and I see: [ID 873 daemon.warning] Trying to open: '/var/run/named.pid'. [ID 873 daemon.warning] unable to set effective gid to 0: Not owner [ID 873 daemon.info] generating session key for dynamic DNS [ID 873 daemon.warning] Trying to open: '/var/run/named/session.key'. We are running bind in a chrooted environment, running named as user 'named' on a Solaris 10 server: /bind/sbin/named -t /chroot/domain -u named Only when we make root's primary id to be 0, we can get rid of the warning. We tried adding root to the group 'root', and we still get the warning. We've set /chroot/domain/var/run ownership to: drwxrwxr-x 4 root other And named.pid gets created correctly: -rw-r--r-- 1 namednamed It could be something simple that I am missing.. we'll well see. Any thoughts? Thanks for your help, AJ On Fri, Sep 17, 2010 at 2:42 PM, aldus jung wrote: We recently upgraded from bind version 9.7.0 to 9.7.1-P2 and we noticed that upon start of named, we are seeing the following warning message: [ID 123 daemon.warning] unable to set effective gid to 0: Not owner [ID 123 daemon.info] generating session key for dynamic DNS [ID 123 daemon.warning] unable to set effective gid to 0: Not owner On our DNS server, root user is configured as uid=0(root) gid=1(other), but we didn't encounter these warnings in version 9.7.0. It would be easy to work around the warnings by adding root to root's group, but I wanted to understand why we are getting these warning when we didn't see this on 9.7.0. Which file or directory is named trying to set gid to 0? thanks for your help, AJ ___ 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
Re: dig ns fails when local name servers misconfigured
In message <1285805733.5799.857.ca...@karl>, Karl Auer writes:
> On Wed, 2010-09-29 at 19:51 -0400, Tristan Goguen wrote:
> > We would like to take some action when domain authority transfers take =20
> > place. Can we configure dig to return the name server list based =20
> > exclusively on a query to the root / TLD servers? Can local name =20
> > servers be ignored?
>
>dig +trace ilap.ca ns | grep "^ilap\.ca\." | cut -f6
Note: "awk '{print $5}'" would be more general than "cut -f6" as the
field count doesn't change with the length of the domain name.
> Might need something a bit more robust than that cut if you are working
> with other domains.
>
> Regards, K.
>
> --=20
> ~~~
> Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h)
> http://www.biplane.com.au/kauer/ +61-428-957160 (mob)
>
> GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
> Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
>
> --=-OLxFVUYbaa3pAwUMpi6o
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: This is a digitally signed message part
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEABECAAYFAkyj1p8ACgkQLrx1S82XAVYdhgCffT3jtsoioNOuyDTAxtWjXJWa
> udIAnjp1N7CdkQTrCyRYw2qYxF5mWTik
> =1p3/
> -END PGP SIGNATURE-
>
> --=-OLxFVUYbaa3pAwUMpi6o--
>
>
> --===4169451910662373077==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> --===4169451910662373077==--
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: dig ns fails when local name servers misconfigured
On Wed, 2010-09-29 at 19:51 -0400, Tristan Goguen wrote: > We would like to take some action when domain authority transfers take > place. Can we configure dig to return the name server list based > exclusively on a query to the root / TLD servers? Can local name > servers be ignored? dig +trace ilap.ca ns | grep "^ilap\.ca\." | cut -f6 Might need something a bit more robust than that cut if you are working with other domains. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig ns fails when local name servers misconfigured
In message , Tristan Goguen writ es: > > Hi all, > > We have been using dig to retrieve a domain's name servers for years. > Unfortunately, the dig syntax we normally use does not work when name > servers are misconfigured. Currently, dig is returning an empty name > server list for domain ilap.ca: > > dig +short ilap.ca ns > < empty list > > > For testing purposes, we removed the zone statement for the domain. > > We would like to take some action when domain authority transfers take > place. Can we configure dig to return the name server list based > exclusively on a query to the root / TLD servers? Can local name > servers be ignored? "dig +noall +norec +authority zone @parent" should return you the referral. e.g. dig +noall +authority +norec ilap.ca @sns-pb.isc.org Also it is bad form to turn off the service before the re-delegation has taken place and the old NS/A//DS/DNSKEY records have expired from caches. The old servers should be slaves of the new servers. This allows for a smooth transition to occur. Mark > Thank you for any advice. > > Regards, > Tristan > > - > Tristan Goguen > CEO, ILAP(r) > > (416) 250-5600 x205 - tgog...@ilap.com > > Our mission is to provide the North American marketplace with advanced > Internet solutions. > > > --Apple-Mail-120-406958062 > Content-Disposition: attachment; > filename=vcard.vcf > Content-Type: text/directory; x-mac-hide-extension=yes; x-unix-mode=0644; > name="vcard.vcf" > Content-Transfer-Encoding: quoted-printable > > BEGIN:VCARD=0D=0AVERSION:3.0=0D=0AN:Goguen;Tristan;;;=0D=0AFN:Goguen=20= > Tristan=0D=0AORG:Internet=20Light=20and=20Power=20Inc.;=0D=0ATITLE:CEO=0D= > =0AEMAIL;type=3DINTERNET;type=3DWORK;type=3Dpref:tgog...@ilap.com=0d=0a= > TEL;type=3DWORK;type=3Dpref:(416)=20250-5600=20X\:205=0D=0A= > TEL;type=3DCELL:(416)=20919-3773=0D=0A= > item1.ADR;type=3DWORK;type=3Dpref:;;210=20Sheppard=20Avenue=20= > East;Toronto;ON;M2N=203A9;CA=0D=0Aitem1.X-ABADR:ca=0D=0A= > item2.URL;type=3Dpref:http\://ilap.com/=0D=0A= > item2.X-ABLabel:_$!!$_=0D=0A= > X-ABUID:F34BC1E6-BADF-4147-A464-E049519D1DDE\:ABPerson=0D=0AEND:VCARD=0D=0A= > > --Apple-Mail-120-406958062 > Content-Type: text/plain; > charset=US-ASCII; > format=flowed > Content-Transfer-Encoding: 7bit > > > > > --Apple-Mail-120-406958062 > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > --Apple-Mail-120-406958062-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dig ns fails when local name servers misconfigured
Hi all, We have been using dig to retrieve a domain's name servers for years. Unfortunately, the dig syntax we normally use does not work when name servers are misconfigured. Currently, dig is returning an empty name server list for domain ilap.ca: dig +short ilap.ca ns < empty list > For testing purposes, we removed the zone statement for the domain. We would like to take some action when domain authority transfers take place. Can we configure dig to return the name server list based exclusively on a query to the root / TLD servers? Can local name servers be ignored? Thank you for any advice. Regards, Tristan - Tristan Goguen CEO, ILAP(r) (416) 250-5600 x205 - tgog...@ilap.com Our mission is to provide the North American marketplace with advanced Internet solutions. BEGIN:VCARD VERSION:3.0 N:Goguen;Tristan;;; FN:Goguen Tristan ORG:Internet Light and Power Inc.; TITLE:CEO EMAIL;type=INTERNET;type=WORK;type=pref:tgog...@ilap.com TEL;type=WORK;type=pref:(416) 250-5600 X\:205 TEL;type=CELL:(416) 919-3773 item1.ADR;type=WORK;type=pref:;;210 Sheppard Avenue East;Toronto;ON;M2N 3A9;CA item1.X-ABADR:ca item2.URL;type=pref:http\://ilap.com/ item2.X-ABLabel:_$!!$_ X-ABUID:F34BC1E6-BADF-4147-A464-E049519D1DDE\:ABPerson END:VCARD ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind named 9.7.2-P2 segfault and core dump when in debug mode
In message <62426.10.0.66.17.1285784847.squir...@interact.purplecow.org>, Denni s Clarke writes: > > I am trying to track down a bit of strange behavior. Not sure if anyone > else sees this. > > I tend to run named in the foreground and in debug level 2 for a while > after I compile it. If all looks good then I can run it as a service > daemon in the usual way. > > This means I run it like so : > > bash-3.00# /opt/csw/sbin/named -4 -c /etc/opt/csw/named.conf \ > > -d 2 -f -g -n 1 -p 53 -u named > > Note the -d 2 there. > > 29-Sep-2010 17:31:43.715 starting BIND 9.7.2-P2 -4 -c > /etc/opt/csw/named.conf -d 2 -f -g -n 1 -p 53 -u named > . > . > . > > Everything seems to be fine until I saw this after 20 minutes or so : > > 29-Sep-2010 17:40:35.964 error (unexpected RCODE REFUSED) resolving > '243.136.240.111.dun.dnsrbl.net/A/IN': 66.11.124.26#53 > 29-Sep-2010 17:40:35.965 client 66.225.151.243#45979: query failed > (SERVFAIL) for 243.136.240.111.dun.dnsrbl.net/IN/A at query.c:4650 > > >At this point it is just hung. > > > So I started it up again in the exact same way and then went to a client > machine and issued this query via dig : > > $ /opt/csw/bin/dig +qr @ns1.blastwave.org 243.136.240.111.dun.dnsrbl.net > > ; <<>> DiG 9.7.2-P2 <<>> +qr @ns1.blastwave.org > 243.136.240.111.dun.dnsrbl.net > ; (1 server found) > ;; global options: +cmd > ;; Sending: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 430 > ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;243.136.240.111.dun.dnsrbl.net.IN A > > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 430 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;243.136.240.111.dun.dnsrbl.net.IN A > > ;; Query time: 235 msec > ;; SERVER: 66.225.151.252#53(66.225.151.252) > ;; WHEN: Wed Sep 29 17:47:25 2010 > ;; MSG SIZE rcvd: 48 > > So that response looks okay but > > QUERY, status: SERVFAIL, id: 430 > > also the named process was hung again : > > 29-Sep-2010 17:47:24.850 createfetch: 243.136.240.111.dun.dnsrbl.net A > 29-Sep-2010 17:47:24.986 error (unexpected RCODE REFUSED) resolving > '243.136.240.111.dun.dnsrbl.net/A/IN': 66.11.124.26#53 > 29-Sep-2010 17:47:25.081 lame server resolving > '243.136.240.111.dun.dnsrbl.net' (in 'dnsrbl.net'?): 66.11.124.30#53 > 29-Sep-2010 17:47:25.082 client 66.225.151.227#24722: query failed > (SERVFAIL) for 243.136.240.111.dun.dnsrbl.net/IN/A at query.c:4650 > Killed > > So I figured I would run this in debug level 4 : > > bash-3.00# /opt/csw/sbin/named -4 -c /etc/opt/csw/named.conf -d 4 -f -g -n > 1 -p 53 -u named > 29-Sep-2010 17:48:56.400 starting BIND 9.7.2-P2 -4 -c > /etc/opt/csw/named.conf -d 4 -f -g -n 1 -p 53 -u named > . > . > . > 29-Sep-2010 17:48:56.455 loading configuration from '/etc/opt/csw/named.conf' > 29-Sep-2010 17:48:56.470 reading built-in trusted keys from file > '/etc/opt/csw/bind.keys' > Segmentation Fault (core dumped) > > bash-3.00# file core > core: ELF 32-bit MSB core file SPARC Version 1, from 'named' > > wow .. that is really not good. > > What failed ? > > bash-3.00# mdb /opt/csw/sbin/sparcv8/named core > Loading modules: [ libc.so.1 ld.so.1 ] > > ::status > debugging core file of named (32-bit) from callistoz > file: /opt/csw/sbin/sparcv8/named > initial argv: > /opt/csw/sbin/named -4 -c /etc/opt/csw/named.conf -d 3 -f -g -n 1 -p 53 -u > name > threading model: multi-threaded > status: process terminated by SIGSEGV (Segmentation Fault) > > > $c > libc.so.1`strlen+0x18(cf73c, 2000, a7cb0, fe94fc00, cf720, fe8c0d60) > libisc.so.62`isc_log_doit+0x794(cf700, fee27ab0, c4f44, 3, 0, 0) > libisc.so.62`isc_log_write+0x60(cf700, fee27ab0, c4f44, 3, a7cb0, a7cd8) > set_limit+0x210(a7cb0, a7cd8, a7cd8, 9, , fffd) > set_limits+0x64(fe94fdf8, d89e0, ff0719c0, fe94fe14, a8028, d89e0) > load_configuration+0x7d4(ffbffe22, dc758, 1, 0, ea758, 5fc28) > run_server+0x420(ea758, e89c8, fe935840, 0, fe7e0200, fe8c21f0) > libisc.so.62`dispatch+0x7d8(d6758, 0, 0, 0, fe7e0200, 1) > libisc.so.62`run+0x14(d6758, fe95, 0, 0, fedde7f0, 0) > libc.so.1`_lwp_start(0, 0, 0, 0, 0, 0) > > > ::stack > libc.so.1`strlen+0x18(cf73c, 2000, a7cb0, fe94fc00, cf720, fe8c0d60) > libisc.so.62`isc_log_doit+0x794(cf700, fee27ab0, c4f44, 3, 0, 0) > libisc.so.62`isc_log_write+0x60(cf700, fee27ab0, c4f44, 3, a7cb0, a7cd8) > set_limit+0x210(a7cb0, a7cd8, a7cd8, 9, , fffd) > set_limits+0x64(fe94fdf8, d89e0, ff0719c0, fe94fe14, a8028, d89e0) > load_configuration+0x7d4(ffbffe22, dc758, 1, 0, ea758, 5fc28) > run_server+0x420(ea758, e89c8, fe935840, 0, fe7e0200, fe8c21f0) > libisc.so.62`dispatch+0x7d8(d6758, 0, 0, 0, fe7e0200, 1) > libisc.so.62`run+0x14(d6758, fe95, 0, 0, fedde7f0, 0) > libc.so.1`_lwp_start(0, 0, 0, 0, 0, 0) > > bash-3.00# pstack core > core 'core' of 1647:/opt/csw/sbin/named -4 -c /etc/opt/csw/named.conf > -d 3 -f -g -n 1 -p 5
Re: When does BIND send queries with DO flag enabled?
> Can someone explain when BIND sets DO flag and when it won't? Most of my > client workstations are XPSP3, and NONE of the queries coming from those > clients have DO flag set. The DO bit is part of the EDNS option record, and some servers (and more to the point, some firewalls) are broken and don't understand EDNS. When BIND doesn't initially get an answer to a query, it retries in different ways, and eventually (on the third try, if I recall correctly) it tries omitting the EDNS option. No EDNS means no DO bit, and I'm pretty sure that's what you're seeing on the trace. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: When does BIND send queries with DO flag enabled?
On 29/09/10 10:30 PM, "Kevin Oberman" wrote: >> Date: Wed, 29 Sep 2010 15:51:55 -0400 >> From: "Taylor, Gord" >> Sender: bind-users-bounces+oberman=es@lists.isc.org >> >> >> We recently ran into an intermittent problem sending queries to a >> business partner. Turns out they had CheckPoint firewalls with >> SmartDefense turned of for DNS traffic. This was blocking traffic going >> to them with DO flag enabled. I could duplicate the problem from a >> command line by issuing "dig @partner hostname +DNSSEC" and this failed >> everytime. When querying through the DNS server though using NSLOOKUP on >> WinXP, the resolution was hit-and-miss. Watching a sniffer trace, >> sometimes BIND 9.4.1-P1 would send with DO flag enabled, and other times >> without. >> >> I know this is an older version of BIND, and lots of bugs fixed in newer >> versions. However, looking at sniffer traces from 9.7.0-P2 shows the >> same behavior = sometimes DO is set and sometimes not set. >> >> Can someone explain when BIND sets DO flag and when it won't? Most of my >> client workstations are XPSP3, and NONE of the queries coming from those >> clients have DO flag set. >> >> Any help is appreciated... >> >> Gord Taylor (CISSP, GCIH, GEEK) > > Gee, an annoying and stupid legal notices at the end of a mail message > is even more annoying when it is in several languages. (Yes, I > understand that some totally clueless lawyer earning a LOT more for not > thinking than you do for thinking is not your fault, but it's still > REALLY ANNOYING!) > > The DO bit is set by default for the simple reason that your server is > DNSSEC capable. The DO bit says DNSSEC OK and is simply declaring that > the server is capable of handing (though not necessarily validating) > responses containing DNSSEC RRs. See RFC3225. > > I assume that setting dnssec-enable to "no" will turn this bit off, but > please get the broken firewall fixed! This is actually not the case, although it is understandable you would think it is the way things _should_ work. DO is set when the resolver has EDNS0 enabled. So that is the only way to turn it off (disable EDNS0). Turning off EDNS0 is likely to effect a lot more than DNSSEC. I wouldn't recommend it. A discussion on this topic was held within this mailing list (June 2010 IIRC) with Jinmei and Evan from ISC providing the insight regarding BIND's behaviour. There was further discussion behind the reasoning for this choice as well. Nevertheless your point is valid, fixing the firewall is the only alternative in my opinion. EDNS0 is not a new technology (10 years I think). Would you use a security product still basing its policies on a time when windows 98 was cutting edge? > > As to not always sending DO, I believe that is dependent on the query > from the client. It would depend on the source of the query. If it was > from the server to get data that would not be sent back to the client, I > imagine the DO bit would be set. (NS lookups during recursion would be > an example), while queries for return to the client will probably > follow the state of the DO bit seen in the query from the client. I'd > guess WINXP is not setting DO. I suspect WIN7 would. > > This last section is largely an educated guess. I don't have time now to > read up on those details in the RFCs. > > Again, get the @#$% firewall fixed! As time goes on, more and more > queries will be blocked by it as DNSSEC moves to the mainstream. -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: When does BIND send queries with DO flag enabled?
> Date: Wed, 29 Sep 2010 15:51:55 -0400 > From: "Taylor, Gord" > Sender: bind-users-bounces+oberman=es@lists.isc.org > > > We recently ran into an intermittent problem sending queries to a > business partner. Turns out they had CheckPoint firewalls with > SmartDefense turned of for DNS traffic. This was blocking traffic going > to them with DO flag enabled. I could duplicate the problem from a > command line by issuing "dig @partner hostname +DNSSEC" and this failed > everytime. When querying through the DNS server though using NSLOOKUP on > WinXP, the resolution was hit-and-miss. Watching a sniffer trace, > sometimes BIND 9.4.1-P1 would send with DO flag enabled, and other times > without. > > I know this is an older version of BIND, and lots of bugs fixed in newer > versions. However, looking at sniffer traces from 9.7.0-P2 shows the > same behavior = sometimes DO is set and sometimes not set. > > Can someone explain when BIND sets DO flag and when it won't? Most of my > client workstations are XPSP3, and NONE of the queries coming from those > clients have DO flag set. > > Any help is appreciated... > > Gord Taylor (CISSP, GCIH, GEEK) Gee, an annoying and stupid legal notices at the end of a mail message is even more annoying when it is in several languages. (Yes, I understand that some totally clueless lawyer earning a LOT more for not thinking than you do for thinking is not your fault, but it's still REALLY ANNOYING!) The DO bit is set by default for the simple reason that your server is DNSSEC capable. The DO bit says DNSSEC OK and is simply declaring that the server is capable of handing (though not necessarily validating) responses containing DNSSEC RRs. See RFC3225. I assume that setting dnssec-enable to "no" will turn this bit off, but please get the broken firewall fixed! As to not always sending DO, I believe that is dependent on the query from the client. It would depend on the source of the query. If it was from the server to get data that would not be sent back to the client, I imagine the DO bit would be set. (NS lookups during recursion would be an example), while queries for return to the client will probably follow the state of the DO bit seen in the query from the client. I'd guess WINXP is not setting DO. I suspect WIN7 would. This last section is largely an educated guess. I don't have time now to read up on those details in the RFCs. Again, get the @#$% firewall fixed! As time goes on, more and more queries will be blocked by it as DNSSEC moves to the mainstream. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Round robin DNS query response
On 9/29/2010 12:37 AM, SW wrote: Hi everyone... I am rather new to the world of DNS so I'm hoping to get some of your expertise... Is there a way to make BIND respond DNS query in sequence? For example, if I assign 2 IP addresses to an A record, is it possible to have it respond like... Client 1 for www.example.com -> 192.168.1.1 Client 2 for www.example.com -> 192.168.1.2 Client 3 for www.example.com -> 192.168.1.3 ...and so on. I know companies use load balancer for this function, but my customer in this case don't really want to make additional investment :P Option A: round-robin+sortlist Option B: views Appropriate caveats for each approach. Note that if these are Windows clients on the same subnets as the www.example.com addresses, you could probably just get away with a plain old round-robin and rely on the built-in Windows "subnet prioritization", see http://www.windowsitpro.com/article/dns/what-is-dns-round-robin-and-subnet-prioritization-.aspx - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
When does BIND send queries with DO flag enabled?
We recently ran into an intermittent problem sending queries to a business partner. Turns out they had CheckPoint firewalls with SmartDefense turned of for DNS traffic. This was blocking traffic going to them with DO flag enabled. I could duplicate the problem from a command line by issuing "dig @partner hostname +DNSSEC" and this failed everytime. When querying through the DNS server though using NSLOOKUP on WinXP, the resolution was hit-and-miss. Watching a sniffer trace, sometimes BIND 9.4.1-P1 would send with DO flag enabled, and other times without. I know this is an older version of BIND, and lots of bugs fixed in newer versions. However, looking at sniffer traces from 9.7.0-P2 shows the same behavior = sometimes DO is set and sometimes not set. Can someone explain when BIND sets DO flag and when it won't? Most of my client workstations are XPSP3, and NONE of the queries coming from those clients have DO flag set. Any help is appreciated... Gord Taylor (CISSP, GCIH, GEEK) ___ This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courriel peut contenir des renseignements protégés et confidentiels. Lexpéditeur ne renonce pas aux droits et obligations qui sy rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements quil contient par une personne autre que le destinataire désigné est interdite. Si vous recevez ce courriel par erreur, veuillez men aviser immédiatement, par retour de courriel ou par un autre moyen. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: tkey-gssapi-credential
Do you need anything other than libgssapi installed for GSS-TSIG to work. Are any of these required as well: cyrus-sasl-gssapi.i386 2.1.22-5.el5_4.3 rhel-x86_64-client-5 cyrus-sasl-gssapi.x86_64 2.1.22-5.el5_4.3 rhel-x86_64-client-5 libgssapi.i386 0.10-2 rhel-x86_64-client-5 libgssapi-devel.i386 0.10-2 rhel-x86_64-client-workstation-5 libgssapi-devel.x86_64 0.10-2 rhel-x86_64-client-workstation-5 rsyslog-gssapi.x86_64 3.22.1-3.el5 rhel-x86_64-client-5 _ Nicholas Miller, ITS, University of Colorado at Boulder On Sep 27, 2010, at 10:23 AM, Nicholas F Miller wrote: > A small correction: > > The packets captured below were between one of the DCs and the DNS server not > a client. > > Also, I am getting this as well when I run nsupdate -g and try to add an A > record: > > dns_tkey_negotiategss: TKEY is unacceptable > _ > Nicholas Miller, ITS, University of Colorado at Boulder > > > > On Sep 27, 2010, at 7:54 AM, Nicholas F Miller wrote: > >> Are you sure? ;-P >> >> I can't seem to get things working. It looks like the Windows machines are >> not happy with the TKEY the DCs are giving them. I can kinit a user account >> from the AD on the DNS server so our krb5.conf appears correct. I am getting >> errors when I run kinit -k -t /etc/krb5.keytab saying the client is not >> found in the database. I'm not sure if it should work since the keytab only >> has a reference to the DNS service principle. >> >> I created the keytab using various different flags. Below is the current >> keytab: >> >> ktpass -out new.keytab -princ DNS/@ >> -pass * -mapuser @ -ptype KRB5_NT_PRINCIPAL -crypto >> DES-CBC-CRC >> >>> From the AD client I am getting some DNS TKEY transactions like this after >>> the update fails. Notice the second transaction's Signature inception and >>> expiration have a null date: >> >> 7341 161.603167DNS Standard query TKEY >> 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e >> ... >> Queries >> 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY, >> class IN >> Name: 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e >> Type: TKEY (Transaction Key) >> Class: IN (0x0001) >> Additional records >> 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e: type TKEY, >> class ANY >> Name: 472-ms-7.32-1772bef1.ddfb6613-c726-11df-dfa0-005056a22c3e >> Type: TKEY (Transaction Key) >> Class: ANY (0x00ff) >> Time to live: 0 time >> Data length: 1712 >> Algorithm name: gss-tsig >> Signature inception: Sep 27, 2010 07:26:04.0 Mountain >> Daylight Time >> Signature expiration: Sep 28, 2010 07:26:04.0 Mountain >> Daylight Time >> Mode: GSSAPI >> Error: No error >> Key Size: 1686 >> Key Data >> GSS-API Generic Security Service Application Program Interface >> OID: 1.3.6.1.5.5.2 (SPNEGO - Simple Protected Negotiation) >> Simple Protected Negotiation >> negTokenInit >> mechTypes: 3 items >> MechType: 1.2.840.48018.1.2.2 (MS KRB5 - >> Microsoft Kerberos 5) >> MechType: 1.2.840.113554.1.2.2 (KRB5 - Kerberos >> 5) >> MechType: 1.2.840.113554.1.2.2.3 (KRB5 - >> Kerberos 5 - User to User) >> mechToken: >> 6082065006092a864886f71201020201006e82063f308206... >> krb5_blob: >> 6082065006092a864886f71201020201006e82063f308206... >> KRB5 OID: 1.2.840.113554.1.2.2 (KRB5 - Kerberos >> 5) >> krb5_tok_id: KRB5_AP_REQ (0x0001) >> Kerberos AP-REQ >> Pvno: 5 >> MSG Type: AP-REQ (14) >> Padding: 0 >> APOptions: 2000 (Mutual required) >> 0... >> = reserved: RESERVED bit off >> .0.. >> = Use Session Key: Do NOT use the session key to encrypt the ticket >> ..1. >> = Mutual required: MUTUAL authentication is REQUIRED >> Ticket >> Tkt-vno: 5 >> Realm: >> Server Name (Service and Instance): >> DNS/ >> Name-type: Service and
dig +trace unexpected behaviour
Hi What I have found is that while dig +trace gets and displays the information directly from the name servers along the way the resolver is also queried and the resolver's result overrides the trace result. This can cause great frustration as you see the trace looks correct but if the cache is stale it can fail and this information is hidden. These are results from a lab environment. Here is the dig trace: ns.juliet.dnslab:etc/domain#dig +trace ns.kilo.dnslab -4 ; <<>> DiG 9.7.1-P2 <<>> +trace ns.kilo.dnslab -4 ;; global options: +cmd . 417 IN NS p.root. . 417 IN NS q.root. . 417 IN NS r.root. ;; Received 198 bytes from 10.10.0.2#53(10.10.0.2) in 0 ms dnslab. 900 IN NS ns1.dnslab. dnslab. 900 IN NS ns2.dnslab. ;; Received 156 bytes from 10.0.0.17#53(p.root) in 0 ms kilo.dnslab.900 IN NS ns.kilo.dnslab. ;; Received 90 bytes from 10.0.0.100#53(ns1.dnslab) in 0 ms ns.kilo.dnslab. 600 IN A 10.0.11.1 kilo.dnslab.600 IN NS ns.juliet.dnslab. kilo.dnslab.600 IN NS ns.kilo.dnslab. kilo.dnslab.600 IN NS ns.india.dnslab. ;; Received 309 bytes from 10.0.11.1#53(ns.kilo.dnslab) in 0 ms The dump from vlan0: 14:30:21.764372 IP 10.0.10.1.65314 > 10.0.0.17.53: 54404 A? ns.kilo.dnslab. (32) 14:30:21.764622 IP 10.0.0.17.53 > 10.0.10.1.65314: 54404- 0/2/4 (156) 14:30:21.765525 IP 10.0.10.1.65312 > 10.0.1.200.53: 56721 A? ns.kilo.dnslab. (32) 14:30:22.779310 IP 10.0.10.1.65310 > 10.0.0.100.53: 56721 A? ns.kilo.dnslab. (32) 14:30:22.779536 IP 10.0.0.100.53 > 10.0.10.1.65310: 56721- 0/1/2 (90) 14:30:22.780285 IP 10.0.10.1.65308 > 10.0.11.1.53: 44527 A? ns.kilo.dnslab. (32) 14:30:22.780572 IP 10.0.11.1.53 > 10.0.10.1.65308: 44527* 1/3/8 A 10.0.11.1 (309) Dump from vlan1: 14:30:21.762427 IP 10.10.0.1.65316 > 10.10.0.2.53: 31933 NS? . (17) 14:30:21.762710 IP 10.10.0.2.53 > 10.10.0.1.65316: 31933 3/0/6 NS p.root., NS q.root., (198) 14:30:21.764029 IP 10.10.0.1.65315 > 10.10.0.2.53: 57492+ A? p.root. (24) 14:30:21.764185 IP 10.10.0.2.53 > 10.10.0.1.65315: 57492 1/3/5 A 10.0.0.17 (199) 14:30:21.765092 IP 10.10.0.1.65313 > 10.10.0.2.53: 57493+ A? ns2.dnslab. (28) 14:30:21.765466 IP 10.10.0.2.53 > 10.10.0.1.65313: 57493 1/2/2 A 10.0.1.200 (120) 14:30:22.778952 IP 10.10.0.1.65311 > 10.10.0.2.53: 57494+ A? ns1.dnslab. (28) 14:30:22.779233 IP 10.10.0.2.53 > 10.10.0.1.65311: 57494 1/2/2 A 10.0.0.100 (120) 14:30:22.780076 IP 10.10.0.1.65309 > 10.10.0.2.53: 57495+ A? ns.kilo.dnslab. (32) 14:30:22.780230 IP 10.10.0.2.53 > 10.10.0.1.65309: 57495 1/3/8 A 10.0.11.1 (309) cat /etc/resolv.conf nameserver 10.10.0.2 Kind Regards -- David Peall smime.p7s Description: S/MIME cryptographic signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Bind named 9.7.2-P2 segfault and core dump when in debug mode
I am trying to track down a bit of strange behavior. Not sure if anyone else sees this. I tend to run named in the foreground and in debug level 2 for a while after I compile it. If all looks good then I can run it as a service daemon in the usual way. This means I run it like so : bash-3.00# /opt/csw/sbin/named -4 -c /etc/opt/csw/named.conf \ > -d 2 -f -g -n 1 -p 53 -u named Note the -d 2 there. 29-Sep-2010 17:31:43.715 starting BIND 9.7.2-P2 -4 -c /etc/opt/csw/named.conf -d 2 -f -g -n 1 -p 53 -u named . . . Everything seems to be fine until I saw this after 20 minutes or so : 29-Sep-2010 17:40:35.964 error (unexpected RCODE REFUSED) resolving '243.136.240.111.dun.dnsrbl.net/A/IN': 66.11.124.26#53 29-Sep-2010 17:40:35.965 client 66.225.151.243#45979: query failed (SERVFAIL) for 243.136.240.111.dun.dnsrbl.net/IN/A at query.c:4650 At this point it is just hung. So I started it up again in the exact same way and then went to a client machine and issued this query via dig : $ /opt/csw/bin/dig +qr @ns1.blastwave.org 243.136.240.111.dun.dnsrbl.net ; <<>> DiG 9.7.2-P2 <<>> +qr @ns1.blastwave.org 243.136.240.111.dun.dnsrbl.net ; (1 server found) ;; global options: +cmd ;; Sending: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 430 ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;243.136.240.111.dun.dnsrbl.net.IN A ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 430 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;243.136.240.111.dun.dnsrbl.net.IN A ;; Query time: 235 msec ;; SERVER: 66.225.151.252#53(66.225.151.252) ;; WHEN: Wed Sep 29 17:47:25 2010 ;; MSG SIZE rcvd: 48 So that response looks okay but QUERY, status: SERVFAIL, id: 430 also the named process was hung again : 29-Sep-2010 17:47:24.850 createfetch: 243.136.240.111.dun.dnsrbl.net A 29-Sep-2010 17:47:24.986 error (unexpected RCODE REFUSED) resolving '243.136.240.111.dun.dnsrbl.net/A/IN': 66.11.124.26#53 29-Sep-2010 17:47:25.081 lame server resolving '243.136.240.111.dun.dnsrbl.net' (in 'dnsrbl.net'?): 66.11.124.30#53 29-Sep-2010 17:47:25.082 client 66.225.151.227#24722: query failed (SERVFAIL) for 243.136.240.111.dun.dnsrbl.net/IN/A at query.c:4650 Killed So I figured I would run this in debug level 4 : bash-3.00# /opt/csw/sbin/named -4 -c /etc/opt/csw/named.conf -d 4 -f -g -n 1 -p 53 -u named 29-Sep-2010 17:48:56.400 starting BIND 9.7.2-P2 -4 -c /etc/opt/csw/named.conf -d 4 -f -g -n 1 -p 53 -u named . . . 29-Sep-2010 17:48:56.455 loading configuration from '/etc/opt/csw/named.conf' 29-Sep-2010 17:48:56.470 reading built-in trusted keys from file '/etc/opt/csw/bind.keys' Segmentation Fault (core dumped) bash-3.00# file core core: ELF 32-bit MSB core file SPARC Version 1, from 'named' wow .. that is really not good. What failed ? bash-3.00# mdb /opt/csw/sbin/sparcv8/named core Loading modules: [ libc.so.1 ld.so.1 ] > ::status debugging core file of named (32-bit) from callistoz file: /opt/csw/sbin/sparcv8/named initial argv: /opt/csw/sbin/named -4 -c /etc/opt/csw/named.conf -d 3 -f -g -n 1 -p 53 -u name threading model: multi-threaded status: process terminated by SIGSEGV (Segmentation Fault) > $c libc.so.1`strlen+0x18(cf73c, 2000, a7cb0, fe94fc00, cf720, fe8c0d60) libisc.so.62`isc_log_doit+0x794(cf700, fee27ab0, c4f44, 3, 0, 0) libisc.so.62`isc_log_write+0x60(cf700, fee27ab0, c4f44, 3, a7cb0, a7cd8) set_limit+0x210(a7cb0, a7cd8, a7cd8, 9, , fffd) set_limits+0x64(fe94fdf8, d89e0, ff0719c0, fe94fe14, a8028, d89e0) load_configuration+0x7d4(ffbffe22, dc758, 1, 0, ea758, 5fc28) run_server+0x420(ea758, e89c8, fe935840, 0, fe7e0200, fe8c21f0) libisc.so.62`dispatch+0x7d8(d6758, 0, 0, 0, fe7e0200, 1) libisc.so.62`run+0x14(d6758, fe95, 0, 0, fedde7f0, 0) libc.so.1`_lwp_start(0, 0, 0, 0, 0, 0) > ::stack libc.so.1`strlen+0x18(cf73c, 2000, a7cb0, fe94fc00, cf720, fe8c0d60) libisc.so.62`isc_log_doit+0x794(cf700, fee27ab0, c4f44, 3, 0, 0) libisc.so.62`isc_log_write+0x60(cf700, fee27ab0, c4f44, 3, a7cb0, a7cd8) set_limit+0x210(a7cb0, a7cd8, a7cd8, 9, , fffd) set_limits+0x64(fe94fdf8, d89e0, ff0719c0, fe94fe14, a8028, d89e0) load_configuration+0x7d4(ffbffe22, dc758, 1, 0, ea758, 5fc28) run_server+0x420(ea758, e89c8, fe935840, 0, fe7e0200, fe8c21f0) libisc.so.62`dispatch+0x7d8(d6758, 0, 0, 0, fe7e0200, 1) libisc.so.62`run+0x14(d6758, fe95, 0, 0, fedde7f0, 0) libc.so.1`_lwp_start(0, 0, 0, 0, 0, 0) bash-3.00# pstack core core 'core' of 1647:/opt/csw/sbin/named -4 -c /etc/opt/csw/named.conf -d 3 -f -g -n 1 -p 5 - lwp# 1 / thread# 1 fe8cbc3c ___sigtimedwait (ffbffbb0, 0, 0, fefe2a00, 0, 1) + 8 fe8b4158 __posix_sigwait (ffbffbb0, ffbffb2c, 0, 0, fefe2a00, 1) + 18 fede4aac isc__app_ctxrun (fee27fb8, c5170, c4f34, fffe, a5574, a5728) + 45c fede4bd8 isc__app_run (c9be0, a56fc, 0, 6e616d65, 80808080, 1010101) + 28 000458dc main
Re: Multiple masters and multiple TSIG keys
On 29 Sep 2010, at 15:53, Anand Buddhdev wrote: > Anyway, I discussed this with my colleague here, and we came up with a > solution that works. We have created 2 views of the master name servers: Nice one, and useful to have in the mailing-list archive! /Niall ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Multiple masters and multiple TSIG keys
On 29/09/2010 12:09, Niall O'Reilly wrote:
> On 29 Sep 2010, at 09:34, Anand Buddhdev wrote:
>
>> Now, I have been given 2 keys, t1 and t2, to use for transferring z1 and
>> z2 respectively.
>
> [Wandering off topic, perhaps]
>
> That seems to me a back-to-front way to do things.
>
> If the organization running the master is concerned to identify
> responsibility for purported slave access, the key needs to be
> provided by the organization responsible for running the slave,
> and accepted (or not) at the master end.
>
> That's what I expect from my slaves.
> None has revolted yet. 8-)
>
> One way or the other, using multiple keys to express what is
> intrinsically a single trust relationship seems to be both likely
> to increase the risk of compromise and certain to add administrative
> burden. Why do it?
Hi Niall,
You're probably right, and it does increase administrative burden.
However, this design isn't my choice, so I'm stuck with it.
Anyway, I discussed this with my colleague here, and we came up with a
solution that works. We have created 2 views of the master name servers:
masters m-key1 {ip1 key key1; ... };
masters m-key2 {ip1 key key2; ... };
zone z1 {
masters { m-key1; };
...
};
zone z2 {
masters { m-key2; };
...
};
Regards,
Anand Buddhdev
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: forward only not
-- Original Message --
From: "Len Conrad"
Reply-To: lcon...@go2france.com
Date: Wed, 29 Sep 2010 15:58:13 +0200
>FreeBSD 7.2-RELEASE
>
>BIND 9.6.0-P1
>
>resolv.conf:
>nameserver 127.0.0.1
>
>
>machine is postfix MX relay-only gateway
>
>on a separate machines, zen.dnsbld.domain.net on IPs 10.1.60.1 & 10.1.60.2,
>rbldnsd is running a local copy of zen.spamhaus
>
>nmap shows 10.1.60.1 and 10.1.60.2 with port 53 UDP open.
>
>dig @10.1.60.1 or .2 d.c.b.a.zen.dnsbld.domain.net works.
>
>named.conf:
>
>zone "zen.dnsbld.domain.net" { type forward; forwarders { 10.1.60.1 ;
>10.1.60.2 ; }; forward only; };
>
>and no other forwarding statements.
>
>named query logging shows client 127.0.0.1 (postfix/postscreen) sending
>queries to 127.0.0.1
>
>tshark capture shows the BIND machine sending queries to the NSs authoritative
>for domain.net, rather than forwarding to the above forwarders.
>
>The above situation on 3 different MXs. The weirdest is that when we fired up
>private zen and forwarding on the 3 MXs, they all worked immediately,
>perfectly, for about 24 hours, millions of queries, then within a few minutes,
>they all stopped working with the zen servers, and haven't worked since.
>stop/start postfix and named has not effect.
>
>What is overriding the zone forwarding?
>
fixed, was typo in the forward zone name. They typo was inconsequential and
worked for one day, until someone removed the NS delegation records for the zen
zone from the domain.net auth servers.
Len
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
forward only not
FreeBSD 7.2-RELEASE
BIND 9.6.0-P1
resolv.conf:
nameserver 127.0.0.1
machine is postfix MX relay-only gateway
on a separate machines, zen.dnsbld.domain.net on IPs 10.1.60.1 & 10.1.60.2,
rbldnsd is running a local copy of zen.spamhaus
nmap shows 10.1.60.1 and 10.1.60.2 with port 53 UDP open.
dig @10.1.60.1 or .2 d.c.b.a.zen.dnsbld.domain.net works.
named.conf:
zone "zen.dnsbld.domain.net" { type forward; forwarders { 10.1.60.1 ; 10.1.60.2
; }; forward only; };
and no other forwarding statements.
named query logging shows client 127.0.0.1 (postfix/postscreen) sending queries
to 127.0.0.1
tshark capture shows the BIND machine sending queries to the NSs authoritative
for domain.net, rather than forwarding to the above forwarders.
The above situation on 3 different MXs. The weirdest is that when we fired up
private zen and forwarding on the 3 MXs, they all worked immediately,
perfectly, for about 24 hours, millions of queries, then within a few minutes,
they all stopped working with the zen servers, and haven't worked since.
stop/start postfix and named has not effect.
What is overriding the zone forwarding?
Len
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: How does BIND 9 scale with multithreading?
2010/9/29 Eivind Olsen > Does anyone know if there are any benchmarks out in the public, which > could give some insight into how well BIND 9 scales with multithreading? > I've tried looking on this list, and googling, but haven't found anything > yet. > > To be a bit more specific - I'm not sure what a good option for server > hardware would be for a recursive DNS server. On one hand, the Sun (ok, > Oracle) Niagara/Coolthreads architecture seems to work nicely enough, but > maybe I'd be better off with some generic Intel/AMD based solution with > fewer threads/cores but higher GHz per thread? > i did some test and Niagara (T1000 / T5240) performs badly (response time and rate) compared to Intel/AMD some numbers at 75% cpu T1000 6 cores / 24threads~10ms 600 queries/second 2-core AMD 1210 1.8ghz:~0.6ms 7000 queries/second 8-core Intel E5410 2.33ghz: ~0.6ms 7 queries/second -- Fabien ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Multiple masters and multiple TSIG keys
On 29 Sep 2010, at 09:34, Anand Buddhdev wrote: > Now, I have been given 2 keys, t1 and t2, to use for transferring z1 and > z2 respectively. [Wandering off topic, perhaps] That seems to me a back-to-front way to do things. If the organization running the master is concerned to identify responsibility for purported slave access, the key needs to be provided by the organization responsible for running the slave, and accepted (or not) at the master end. That's what I expect from my slaves. None has revolted yet. 8-) One way or the other, using multiple keys to express what is intrinsically a single trust relationship seems to be both likely to increase the risk of compromise and certain to add administrative burden. Why do it? ATB /Niall ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How does BIND 9 scale with multithreading?
I did some benchmarking on this about 1.5 yrs ago, here's a graph representing the results: http://sedoss.com/bind.png On Wed, Sep 29, 2010 at 10:37 AM, wrote: > Hi > > i read that 'old' bind version where better when threading was disabled. Load > balancing > between 2 processe was better. Is this always the case ? > http://zaphods.net/~zaphodb/high-performance-bind9.html > > some interesting links for DNS performance : > http://kb.linuxvirtualserver.org/wiki/Building_Scalable_DNS_Cluster_using_LVS > https://lists.isc.org/pipermail/bind-users/2006-September/063917.html > > Philippe > > > >> -Original Message- >> From: bind-users-bounces+philippe.simonet=swisscom@lists.isc.org >> [mailto:bind-users-bounces+philippe.simonet=swisscom@lists.isc.org] >> On Behalf Of Eivind Olsen >> Sent: Wednesday, September 29, 2010 09:56 >> To: bind-us...@isc.org >> Subject: How does BIND 9 scale with multithreading? >> >> Does anyone know if there are any benchmarks out in the public, which >> could give some insight into how well BIND 9 scales with multithreading? >> I've tried looking on this list, and googling, but haven't found anything >> yet. >> >> To be a bit more specific - I'm not sure what a good option for server >> hardware would be for a recursive DNS server. On one hand, the Sun (ok, >> Oracle) Niagara/Coolthreads architecture seems to work nicely enough, but >> maybe I'd be better off with some generic Intel/AMD based solution with >> fewer threads/cores but higher GHz per thread? >> >> Regards >> Eivind Olsen >> >> >> ___ >> 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 > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: How does BIND 9 scale with multithreading?
Hi i read that 'old' bind version where better when threading was disabled. Load balancing between 2 processe was better. Is this always the case ? http://zaphods.net/~zaphodb/high-performance-bind9.html some interesting links for DNS performance : http://kb.linuxvirtualserver.org/wiki/Building_Scalable_DNS_Cluster_using_LVS https://lists.isc.org/pipermail/bind-users/2006-September/063917.html Philippe > -Original Message- > From: bind-users-bounces+philippe.simonet=swisscom@lists.isc.org > [mailto:bind-users-bounces+philippe.simonet=swisscom@lists.isc.org] > On Behalf Of Eivind Olsen > Sent: Wednesday, September 29, 2010 09:56 > To: bind-us...@isc.org > Subject: How does BIND 9 scale with multithreading? > > Does anyone know if there are any benchmarks out in the public, which > could give some insight into how well BIND 9 scales with multithreading? > I've tried looking on this list, and googling, but haven't found anything > yet. > > To be a bit more specific - I'm not sure what a good option for server > hardware would be for a recursive DNS server. On one hand, the Sun (ok, > Oracle) Niagara/Coolthreads architecture seems to work nicely enough, but > maybe I'd be better off with some generic Intel/AMD based solution with > fewer threads/cores but higher GHz per thread? > > Regards > Eivind Olsen > > > ___ > 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
Multiple masters and multiple TSIG keys
Hello BIND users,
I'm using BIND 9.7.1-P2. I have the following configuration in my
named.conf:
masters "m" { ip1; ip2; ip3; ip4; };
zone "z1" {
type slave;
file "z1";
masters { m; };
};
zone "z2" {
type slave;
file "z2";
masters { m; };
};
Now, I have been given 2 keys, t1 and t2, to use for transferring z1 and
z2 respectively. I defined the keys in my configuration file, and then did:
zone "z1" {
type slave;
file "z1";
masters { m key t1; };
};
zone "z2" {
type slave;
file "z2";
masters { m key t2; };
};
However, BIND doesn't like this, and named-checkconf gives me the error
"unexpected token 't1'".
Is there any way to use different keys for different zones when using a
masters macro? Or will I have to abandon macros for this type of
configuration?
--
Anand Buddhdev
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
bind-dlz don't work
Bind-dlz(the latest Berkeley DB as a back-end),Services can start correctly,
but DNS is not returned to the correct value.
Related data:
dbsql> .tables
dns_client dns_datadns_xfr dns_zone
dbsql> select * from dns_client;
test.com|192.168.146.155
test.com|127.0.0.1
dbsql> select * from dns_data;
test.com @|1 @ 86400 SOA ns1.test.com. hostmaster.test.com. 2006112401 28800
7200 604800 86400
test.com download|18 download 600 A 192.168.1.15
test.com @|3 @ 600 A 192.168.1.1
dbsql> select * from dns_xfr;
test.com|@
test.com|download
dbsql> select * from dns_zone;
moc.tset|
[r...@lbbackup bdb]# dig @192.168.146.148 download.test.com
; <<>> DiG 9.7.1-P2 <<>> @192.168.146.148 download.test.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27487
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;download.test.com. IN A
;; AUTHORITY SECTION:
. 518400 IN NS H.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS E.ROOT-SERVERS.NET.
. 518400 IN NS M.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
. 518400 IN NS L.ROOT-SERVERS.NET.
. 518400 IN NS A.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS J.ROOT-SERVERS.NET.
;; Query time: 0 msec
;; SERVER: 192.168.146.148#53(192.168.146.148)
;; WHEN: Wed Sep 29 15:16:23 2010
;; MSG SIZE rcvd: 246
[r...@lbbackup bdb]# dig @192.168.146.148 test.com
; <<>> DiG 9.7.1-P2 <<>> @192.168.146.148 test.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40321
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;test.com. IN A
;; AUTHORITY SECTION:
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
. 518400 IN NS J.ROOT-SERVERS.NET.
. 518400 IN NS E.ROOT-SERVERS.NET.
. 518400 IN NS M.ROOT-SERVERS.NET.
. 518400 IN NS L.ROOT-SERVERS.NET.
. 518400 IN NS H.ROOT-SERVERS.NET.
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS A.ROOT-SERVERS.NET.
;; Query time: 6 msec
;; SERVER: 192.168.146.148#53(192.168.146.148)
;; WHEN: Wed Sep 29 15:54:41 2010
;; MSG SIZE rcvd: 237
[r...@lbbackup bdb]# cat /etc/named.conf
options {
directory "/var/named";
allow-query { any; };
allow-query-cache { any; };
recursion no;
pid-file "/var/named/named.pid";
};
logging
{
channel query_log
{
file "query.log" versions 3 size 20m;
severity info;
print-time yes;
print-category yes;
};
category queries
{
query_log;
};
};
controls {
inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
};
zone "." IN {
type hint;
file "named.ca";
};
dlz "bdbhpt zone" {
database "bdbhpt P /var/named dnsdata.db";
};
include "/etc/rndc.key";
[r...@drbd_148 named]# named -u named -c /etc/named.conf -g -d 1
29-Sep-2010 15:42:42.002 starting BIND 9.7.2-P2 -u named -c /etc/named.conf -g
-d 1
29-Sep-2010 15:42:42.003 built with '--enable-threads'
'--with-dlz-bdb=/usr/local/BerkeleyDB.5.1'
29-Sep-2010 15:42:42.004 adjusted limit on open files from 1024 to 1048576
29-Sep-2010 15:42:42.004 found 1 CPU, using 1 worker thread
29-Sep-2010 15:42:42.006 using up to 4096 sockets
29-Sep-2010 15:42:42.022 loading configuration from '/etc/named.conf'
29-Sep-2010 15:42:42.026 reading built-in trusted keys from file
'/etc/bind.keys'
29-Sep-2010 15:42:42.028 using default UDP/IPv4 port range: [1024, 65535]
29-Sep-2010 15:42:42.030 using default UDP/IPv6 port range: [1024, 65535]
29-Sep-2010 15:42:42.038 listening o
How does BIND 9 scale with multithreading?
Does anyone know if there are any benchmarks out in the public, which could give some insight into how well BIND 9 scales with multithreading? I've tried looking on this list, and googling, but haven't found anything yet. To be a bit more specific - I'm not sure what a good option for server hardware would be for a recursive DNS server. On one hand, the Sun (ok, Oracle) Niagara/Coolthreads architecture seems to work nicely enough, but maybe I'd be better off with some generic Intel/AMD based solution with fewer threads/cores but higher GHz per thread? Regards Eivind Olsen ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Round robin DNS query response
> Is there a way to make BIND respond DNS query in sequence? Someone else can probably give a more authoritative answer. My understanding is that BIND will rotate the answers it gives out when there's more than one similar record in a rrset. And yes, this can help spread the load a bit. Whether that's good enough for your projoect - I can't say. Keep in mind that your main DNS servers won't see most of the client queries, if your clients ask other recursive DNS servers (like their ISPs servers etc). Also depending on your requirements: doing this simple "load spreading" won't account for servers being down etc, the only failover mechanism is if whatever your clients are using is capable of retrying on a different IP-address if the first one doesn't answer. Regards Eivind Olsen ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
