Re: odd behaviour on caching ns with views
Am Sun, 13 Jun 2010 14:45:22 -0700
schrieb JINMEI Tatuya / 神明達哉 :
> At Tue, 8 Jun 2010 11:03:55 +0200,
> Torsten wrote:
>
> > Everything works perfectly okay except queries for
> > 1.0.0.127.in-addr.arpa and 0.0.0.0.in-addr.arpa. These are refused
> > by the caching server (denied entries in default log).
> > Asking those queries on an identical server without views returns
> > the usual NXDOMAIN answer.
> >
> > Is there something special about 0.in-addr.arpa and
> > 127.in-addr.arpa in views I haven't seen yet?
>
> That sounds like something related to builtin "empty zones". But I
> have no idea how the existence/non-existence of views affects the
> behavior. That may be due to your separate configuration file:
>
> include "/named/default/private_netblocks.conf";
>
> and showing the content of this file may help.
>
Oh... sorry, that file should have been in the original post.
It contains forwardings for RFC1918 net blocks to our own blackhole
instances, since we had some problems with the generally available
servers located in Amsterdam in the past.
zone "10.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};
zone "16.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};
zone "17.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};
zone "18.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};
zone "19.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};
zone "20.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};
zone "21.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};
zone "22.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};
zone "23.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};
zone "24.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};
zone "25.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};
zone "26.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};
zone "27.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};
zone "28.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};
zone "29.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};
zone "30.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};
zone "31.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};
zone "168.192.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};
Ciao
Torsten
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Microsoft's nslookup Implementation Problems
On 06/13/10 15:55, Merton Campbell Crockett wrote: Providing access to the web-based tools to IT personnel might not be that big of a challenge; Excellent! however, the problem remains: Using "nslookup" is an ingrained behavior for the general user. I would assert that "the general user" has no idea what nslookup is, or even how to open a windows command line. I can't speak to what passes for "the general user" in your environment however. It produces the "wrong" answers. The result is unnecessary service requests that must be processed. In my mind, this is the problem that needs to be addressed. Then you're back to replacing and/or removing nslookup on each desktop (assuming of course that you've ruled out a preemptive user education program pointing users to the tool that you're going to create). Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Microsoft's nslookup Implementation Problems
On Jun 13, 2010, at 2:21 PM, Doug Barton wrote: >> The problem with the erroneous functioning of Microsoft's nslookup.exe >> is that it requires a corporate wide change. There are a number of >> reasonably intelligent users that assume nslookup.exe is providing them >> correct information. I would need to convince management that it needs >> to be replaced with the ISC version or convince them to deploy DiG to >> all systems. Deploying DiG might be the easier as it doesn't replace >> something distributed by Microsoft. At the same time, the tool that >> users are familiar with is broken. It needs to be replaced. This will be >> a "hard sale" to management. > > That's a different scale of problem than what you originally described. :) > Without knowing more about your internal political/support/etc. structure > it's hard to be sure what the "right" answer is. However if the scope is not > "replace/augment nslookup for a few support techs" but rather "find a way to > give a large number of, possibly non-technical users the right answers" then > I would suggest that perhaps setting up an internal web page that explains > the problem in the simplest possible terms, and provides a CGI with access to > a working version of nslookup and/or dig so that they can get the answers > they need might do the trick. It's interesting that you should mention web-based tools. I had developed several of these for a DoD customer in the latter half of the Nineties. As a proof of concept, they were implemented on my local network. They are still accessible after the last acquisition/merger of my company. It wouldn't take much work to modify the PHP code that I used to eliminate some features that are no longer available due to corporate security policies. Providing access to the web-based tools to IT personnel might not be that big of a challenge; however, the problem remains: Using "nslookup" is an ingrained behavior for the general user. It produces the "wrong" answers. The result is unnecessary service requests that must be processed. In my mind, this is the problem that needs to be addressed. I'm still an Engineer although I was surreptitiously transferred from Engineering to Information Technology 5 years ago to resolve a "political" issue. -- Merton Campbell Crockett m.c.crock...@roadrunner.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: odd behaviour on caching ns with views
At Tue, 8 Jun 2010 11:03:55 +0200, Torsten wrote: > Everything works perfectly okay except queries for > 1.0.0.127.in-addr.arpa and 0.0.0.0.in-addr.arpa. These are refused by > the caching server (denied entries in default log). > Asking those queries on an identical server without views returns the > usual NXDOMAIN answer. > > Is there something special about 0.in-addr.arpa and 127.in-addr.arpa in > views I haven't seen yet? That sounds like something related to builtin "empty zones". But I have no idea how the existence/non-existence of views affects the behavior. That may be due to your separate configuration file: include "/named/default/private_netblocks.conf"; and showing the content of this file may help. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Microsoft's nslookup Implementation Problems
On 06/13/10 14:08, Merton Campbell Crockett wrote: On Jun 13, 2010, at 1:08 PM, Doug Barton wrote: On 06/13/10 13:00, Merton Campbell Crockett wrote: Microsoft's nslookup is broken. What alternative applications that can be installed and used in a Windows XP environment that will continue to work in a Windows 7 environment after a decision is made to upgrade Windows? In the past I've installed nslookup and dig from the BIND package for windows to solve this problem. You wouldn't happen to know when Microsoft's implementation became hopelessly broken would you? Well given my anti-microsoft bias, my natural answer is "at conception" but that's not particularly helpful for you, sorry. :) Being, primarily, a Linux/Unix user; I tend not to use nslookup except when logged into a Windows system. It has to be several years since I last used nslookup until the last few days. http://dougbarton.us/DNS/bind-users-FAQ.html#nslookup-evil The problem with the erroneous functioning of Microsoft's nslookup.exe is that it requires a corporate wide change. There are a number of reasonably intelligent users that assume nslookup.exe is providing them correct information. I would need to convince management that it needs to be replaced with the ISC version or convince them to deploy DiG to all systems. Deploying DiG might be the easier as it doesn't replace something distributed by Microsoft. At the same time, the tool that users are familiar with is broken. It needs to be replaced. This will be a "hard sale" to management. That's a different scale of problem than what you originally described. :) Without knowing more about your internal political/support/etc. structure it's hard to be sure what the "right" answer is. However if the scope is not "replace/augment nslookup for a few support techs" but rather "find a way to give a large number of, possibly non-technical users the right answers" then I would suggest that perhaps setting up an internal web page that explains the problem in the simplest possible terms, and provides a CGI with access to a working version of nslookup and/or dig so that they can get the answers they need might do the trick. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Microsoft's nslookup Implementation Problems
On Jun 13, 2010, at 1:08 PM, Doug Barton wrote: > On 06/13/10 13:00, Merton Campbell Crockett wrote: >> Microsoft's nslookup is broken. What alternative applications that can >> be installed and used in a Windows XP environment that will continue to >> work in a Windows 7 environment after a decision is made to upgrade Windows? > > In the past I've installed nslookup and dig from the BIND package for windows > to solve this problem. You wouldn't happen to know when Microsoft's implementation became hopelessly broken would you? Being, primarily, a Linux/Unix user; I tend not to use nslookup except when logged into a Windows system. It has to be several years since I last used nslookup until the last few days. The problem with the erroneous functioning of Microsoft's nslookup.exe is that it requires a corporate wide change. There are a number of reasonably intelligent users that assume nslookup.exe is providing them correct information. I would need to convince management that it needs to be replaced with the ISC version or convince them to deploy DiG to all systems. Deploying DiG might be the easier as it doesn't replace something distributed by Microsoft. At the same time, the tool that users are familiar with is broken. It needs to be replaced. This will be a "hard sale" to management. -- Merton Campbell Crockett m.c.crock...@roadrunner.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Microsoft's nslookup Implementation Problems
On 06/13/10 13:00, Merton Campbell Crockett wrote: Microsoft's nslookup is broken. What alternative applications that can be installed and used in a Windows XP environment that will continue to work in a Windows 7 environment after a decision is made to upgrade Windows? In the past I've installed nslookup and dig from the BIND package for windows to solve this problem. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Microsoft's nslookup Implementation Problems
Recently, I implemented an instance of BIND that provides a "tailored" name services for a private network connection between two organization. This instance of BIND returns responses for a limited portion of our internal name and address space that the other organization is permitted to access. For names and addresses that they are not permitted to access, they are returned responses similar to what our external name servers would return along with the NS records for our external name servers. Using "dig" I have verified that the correct answers are being returned. A problem occurs with our Service Desk personnel that have Windows XP based systems. If they use Microsoft's nslookup tool to verify what is being returned to the other organization, they do not get the correct response even when the use "server ns.azsd01.gd-ais.com" to set the default name server to be used. While nslookup claims that it is accessing the correct server, the response received is from the user's stub resolver cache or from our normal internal name servers. Inspecting the query log on the name server indicates that BIND never services a request from the system running Microsoft's nslookup tool. In addition, using tcpdump in controlled tests, I find that Microsoft's nslookup implementation never sends any requests to any name server that is designated in a "server" command unless it is one of the default name servers that the system would normally use. At one time, I thought that the following commands worked. However, in recent tests, I've discovered that they are failing as well. nslookup alliance.gd-ais.com ns.azsd01.gd-ais.com nslookup alliance.gd-ais.com 10.21.101.2 Obviously, this is going to create a problem when Service Desk personnel need to assist user's at the other organization as they will be unable to verify how domain names and addresses are being resolved for the user. Microsoft's nslookup is broken. What alternative applications that can be installed and used in a Windows XP environment that will continue to work in a Windows 7 environment after a decision is made to upgrade Windows? -- Merton Campbell Crockett m.c.crock...@roadrunner.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Can't get BIND to use GSSAPI from /usr/local on FreeBSD
On 06/11/10 02:51, John Marshall wrote: BIND 9.7.1rc1 FreeBSD 8.1-PRERELEASE I've just stepped into the world of nsupdate (instead of doing the freeze/edit/thaw dance). I have had success using TSIG (nsupdate -k) but I would like to use TKEY-GSS (nsupdate -g). When I try to do that, nsupdate dumps core. $ /usr/bin/nsupdate -g -d > prereq nxdomain rwpc12.mby.riverwillow.net.au. > Reply from SOA query: < snip> Found zone name: mby.riverwillow.net.au The master is: ns1.mby.riverwillow.net.au start_gssrequest nsupdate: Failed to generate random block Abort trap (core dumped) I suspect the operating system at this point but want to build BIND against separate gssapi_krb5 and OpenSSL libraries in order to isolate the problem. Telling configure --with-openssl=/usr/local does the trick for OpenSSL. Telling configure --with-gssapi=/usr/local makes all the right kind of impressions on config.log, but the linker still ends up using the operating system's gssapi libraries under /usr/lib. Is there something else I need to do to nudge BIND in the direction of libgssapi_krb5 in /usr/local ? Until now I've never built BIND with gssapi, so I'm prepared to be told I've missed something basic. John, Don't worry, you haven't. There is a thread on freebsd-secur...@freebsd.org atm about the wacky state of our base system kerberos, and unfortunately my understanding is that simply installing kerberos from ports doesn't help much. I don't want to get too deep in the weeds on FreeBSD-specific stuff here, so you may want to follow up on -security for that stuff. I do want to leave the door open however for anyone to comment on BIND-specific issues with the configure script. FYI, there is also http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/139426 which suggests that installing cyrus-sasl2 rather than kerberos from ports may be the right way to go. I haven't even started evaluating that patch yet, but perhaps someone on this list who has implemented GSS-TSIG could comment? Personally I loathe kerberos almost as much as windows, so I haven't exactly been eager to dive into this, but because there is user demand for it I would like to get up to speed so this seems as good a time as any. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Upgrade path?
On 06/13/10 06:15, sasa sasa wrote: Hi list, Is it ok to upgrade from 9.4.2 to 9.7.0-P2 directly? Yes, but you should do some testing before you install the new version on your live, production system. There are some differences in the defaults for named.conf, and when upgrading to a new version it's always a good idea to run named-checkconf on your conf file, and named-checkzone on each of your zone files (if you are serving any). If you are setting up a resolver you should also read the ARM for the new defaults for things like allow-query, etc. But don't let this scare you, as long as things are in fairly good shape with your existing installation the upgrade should be fairly painless. :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
error on start: initializing DST: no engine (v9.7.0-P2)
sorry, forgot the subject. not very good on my first posting Hello, I'm seeing an unfamiliar error while attempting to start a newly built from source named instance. I've search on the net and within the bind-user list without luck, DST returns lots of hits, but nothing with "named DST". hoping someone here might know what its about. Is it really a Day Light related? thanks much for your time, greg the error: [r...@fido ~]# /etc/init.d/named start Starting named:[FAILED] [r...@fido ~]# grep named /var/log/messages Jun 13 10:20:00 fido named[2430]: starting BIND 9.7.0-P2 -u named Jun 13 10:20:00 fido named[2430]: built with '--build=i386-redhat-linux-gnu' '--host=i386-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--with-pic' '--disable-static' '--disable-openssl-version-check' '--with-pkcs11=/usr/lib/pkcs11/PKCS11_API.so' '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' 'build_alias=i386-redhat-linux-gnu' 'host_alias=i386-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables' 'CPPFLAGS= -DDIG_SIGCHASE' Jun 13 10:20:00 fido named[2430]: adjusted limit on open files from 1024 to 1048576 Jun 13 10:20:00 fido named[2430]: found 2 CPUs, using 2 worker threads Jun 13 10:20:00 fido named[2430]: using up to 4096 sockets Jun 13 10:20:00 fido named[2430]: initializing DST: no engine Jun 13 10:20:00 fido named[2430]: exiting (due to fatal error) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
[no subject]
Hello, I'm seeing an unfamiliar error while attempting to start a newly built from source named instance. I've search on the net and within the bind-user list without luck, DST returns lots of hits, but nothing with "named DST". hoping someone here might know what its about. Is it really a Day Light related? thanks much for your time, greg the error: [r...@fido ~]# /etc/init.d/named start Starting named:[FAILED] [r...@fido ~]# grep named /var/log/messages Jun 13 10:20:00 fido named[2430]: starting BIND 9.7.0-P2 -u named Jun 13 10:20:00 fido named[2430]: built with '--build=i386-redhat-linux-gnu' '--host=i386-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--with-pic' '--disable-static' '--disable-openssl-version-check' '--with-pkcs11=/usr/lib/pkcs11/PKCS11_API.so' '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' 'build_alias=i386-redhat-linux-gnu' 'host_alias=i386-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables' 'CPPFLAGS= -DDIG_SIGCHASE' Jun 13 10:20:00 fido named[2430]: adjusted limit on open files from 1024 to 1048576 Jun 13 10:20:00 fido named[2430]: found 2 CPUs, using 2 worker threads Jun 13 10:20:00 fido named[2430]: using up to 4096 sockets Jun 13 10:20:00 fido named[2430]: initializing DST: no engine Jun 13 10:20:00 fido named[2430]: exiting (due to fatal error) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Upgrade path?
Warren Kumari -- Please excuse typing, etc -- This was sent from a device with a tiny keyboard. On Jun 13, 2010, at 9:15 AM, sasa sasa wrote: Hi list, Is it ok to upgrade from 9.4.2 to 9.7.0-P2 directly? Yup, no worries... i mean i already have 9.4.2, i can install latest one with ./ configure, make and make install, is there a problem with this steps? please note i already tried it and it worked fine on a cache-only DNS. regards, Sasa ___ 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
Upgrade path?
Hi list, Is it ok to upgrade from 9.4.2 to 9.7.0-P2 directly? i mean i already have 9.4.2, i can install latest one with ./configure, make and make install, is there a problem with this steps? please note i already tried it and it worked fine on a cache-only DNS. regards, Sasa ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
