Re: dnsperf and BIND memory consumption
Doug Barton wrote: > Vinny Abello wrote: >> Just for clarification, is there any downside to this autoconf fix >> vs. how it was previously working? > > It was not working correctly previously, so no. > >> Does autoconf still not understand AMD64 on FreeBSD > > You're confusing "autoconf" and "the configure script provided in the > sources for BIND >= 9.5.x." There is also a variable of "what the > FreeBSD ports provide to configure by default" that I have deliberately > omitted for the sake of clarity. > >> and is your fix just defaulting to something lesser? > > No. > >> It appeared that the switches being run were for 32 bit after this >> fix, but I'm no expert on compilers by far. > > You'd have to dig into the source and really understand what's happening > now vs. what was happening before in order for me to answer this > question, and by the time you had done that work I would not need to > answer this question for you. :) You would have a very hard time finding it just using code inspection since the bug was found several levels under the code since there were a number of Macros in place and the source of the problem was in the creation but the fix had to be elsewhere. I only found this leak because I had accidentally left on a debugging tool when test running on a Windows box and the debugging tool was causing it to break at the creation point. It took me quite a while to peel back the layers and find out why it was really complaining. The fix was easy, but understanding what needed to be fixed and why was not. Danny > The short version is that right now the port is doing what it should be. > > > hth, > > Doug > > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: error compiling bind 9.5.1 with static
At Mon, 5 Jan 2009 19:52:54 +0800, mingdawang wrote: > > [1.1 ] > I'm trying to install bind 9.5.1 on redhat as 4.5, but am having problems > with the configure statement: > > STD_CDEFINES='-DISC_MEM_USE_INTERNAL_MALLOC=1' ./configure > --prefix=/home/named --enable-epoll --disable-threads --enable-largefile > --disable-ipv6 --with-openssl=yes CFLAGS='-static -march=pentium4 -O2 -pipe' [snip] > why? Can you show the content of config.log? --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnsperf and BIND memory consumption
At Mon, 5 Jan 2009 18:58:07 -0500, Vinny Abello wrote: > My basic question is: Is there any advantage to compiling BIND in > the previous manner now that there is a fix in the BIND source code? Do you mean compiling BIND with the memory leak fix and without the FreeBSD port change by "in the previous manner"? For this particular memory leak problem, there's nothing wrong with it. But then you won't benefit from the other (main) advantage of atomic operations: performance improvement. So, you'll still be happier with applying two patches. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Dynamic update of TXT record?
At Thu, 1 Jan 2009 12:23:02 +0100, Michelle Konzack wrote: > Q 1:Which setting is missing? > > Q2: Can someone tell me how to update a TXT record? Please show named.conf of the authoritative server (the one accepting dynamic updates). It's also helpful to debug it to show log messages of the server when it refused the request. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnsperf and BIND memory consumption
At Thu, 1 Jan 2009 00:47:10 -0500, Vinny Abello wrote: > I just loaded up the BIND 9.5.1 port on FreeBSD 7.0 AMD64 with > threads. I don't see the prominent memory leak present on my system > any longer. I lost track of this thread and think two different > changes might have been made, however. One via the port and one in > BIND itself, so I don't know which fix is actually in effect here, > but the results seem good so far. Maybe Doug and Jinmei and comment > on their respective changes just for the record. The memory leak only happens when autoconf fails to detect the availability of hardware-dependent atomic operations. The patch for the FreeBSD port fixes the autoconf problem. The patch I mentioned fixes the memory leak itself. The result is the same either way; the leak will disappear. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnsperf and BIND memory consumption
At Thu, 01 Jan 2009 00:04:49 -0500, Danny Mayer wrote: > Personally, I'm not convinced that it will make a difference outside of > Windows. The fix is to make sure a lock gets destroyed when done and the > function exits. On Windows the lock gets created and memory is allocated > for it outside of the function using it and needs to be explicitly > destroyed, but my understanding of pthreads was that this worked > differently on Unix and the lock structure would be automatically > destroyed when the function is exited since the lock was local to the > function. The pthread implementation of FreeBSD I tested allocated memory for a lock. That was the reason for the leak, and that was why the "Windows-specific" fix also helps FreeBSD (that happens to use pthread locks instead of atomic operations). --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: editing rc.d/named?
bind user wrote: > Thanks for that detailed explanation, Doug...after years of running > Unix/Bind blind (because it just worked), I'm finally understanding why > things are the way they are. -AK You're welcome, and I'll take the latter as a compliment. I try very hard to make things "just work" for our users, so if you've gone this long without having to dig too much deeper I hope that means I'm doing something right. :) Doug ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Fresh (non cached) dig
On Mon, 5 Jan 2009, Stephen Ward wrote: > On Mon, 05 Jan 2009 16:24:04 +, Chris Thompson wrote: > > > On Jan 5 2009, John Wobus wrote: > > > >>[...] There is no nameserver > >>operation > >>that dig could do to tell a caching nameserver to act differently for > >>one query. You could clear the nameserver's cache, or even clear the > >>one name you are interested in out of the cache. > > > > You can use +norecurse and check whether the AA bit is set in the reply. > > Even quite old versions of BIND will not set the AA bit in the response > > if the answer is from the cache, in this case. > > Thanks for this Chris. I never knew that. And Todd, that is just what the > doctor ordered! Do some tests with data already cached. And watch the TTL of the records as you do multiple same digs. Jeremy C. Reed ISC Sales & Support Engineer ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Fresh (non cached) dig
On Mon, 05 Jan 2009 16:24:04 +, Chris Thompson wrote: > On Jan 5 2009, John Wobus wrote: > >>[...] There is no nameserver >>operation >>that dig could do to tell a caching nameserver to act differently for >>one query. You could clear the nameserver's cache, or even clear the >>one name you are interested in out of the cache. > > You can use +norecurse and check whether the AA bit is set in the reply. > Even quite old versions of BIND will not set the AA bit in the response > if the answer is from the cache, in this case. Thanks for this Chris. I never knew that. And Todd, that is just what the doctor ordered! -- . . . ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Magic for NSEC3
On Jan 3, 6:28 pm, Jonathan Petersson wrote: > Thanks for your input > > /Jonathan > > On Jan 3, 2009, at 16:13, Mark Andrews wrote: > > > > > > > In message > > , > > "Jonathan Petersson" > > writes: > >> Hi all, > > >> Hopefully this post wont cause as much SPAM as my last one. About a > >> year ago I started looking into DNSSEC and how to work with it for > >> dynamic updates etc. Since only NSEC was supported, allowing whomever > >> to do a unauthorized zone-transfer I canceled my projects later > >> finding out that NSEC3 would stop the behavior. > > >One really needs to look at the cost benefit analysis to > >decide whether to use NSEC or NSEC3. NSEC3 is much more > >expensive than NSEC3 for both authoritative servers and > >validators than NSEC. There are almost no zone that need > >that level of protection. > > >Stopping AXFR/IXFR has almost zero cost so for many people > >it has become reflex without any need to justify it. Stopping > >zone enumeration has a relatively high cost. > > >Note for many servers stopping AXFR/IXFR was not about the > >zone content and more about preserving file descriptors for > >use by the slaves and legitimate TCP clients rather than the > >curious. > > >> With the release of BIND 9.6 my understanding is that NSEC3 is now > >> supported, however, after reading the DNSSEC ARM for 9.6 I'm pretty > >> clueless as whether there's any magic sauce to get NSEC3 records vs. > >> NSEC. > > >> If anyone has a pointer that would be of help, I've tried using > >> NSEC3RSASHA1 keys without success of getting NSEC3 records. > > >NSEC3RSASHA1 allows the use of either NSEC and NSEC3 when > >signing the zone. You need to tell dnssec-signzone which > >one to use. > > >dnssec-signzone -3 salt [-H iterations] [-A] > > >> Thx > > >> /Jonathan > >> ___ > >> bind-users mailing list > >> bind-us...@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: mark_andr...@isc.org > > ___ > bind-users mailing list > bind-us...@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users While testing our DNSSEC signing product, I found that the expense of signing with NSEC3 versus NSEC was very data dependent. In TLD type zones with a sparse number of records that needed to be signed, signing time could be reduced from hours to minutes by specifying NSEC3. The resultant data files were much smaller than those signed with NSEC. On the other hand zones that predominately needed to be signed by NSEC3 are as expensive or even more expensive that NSEC signing. The other advantage of NSEC3 is “increased” privacy over NSEC by preventing zone walking. As results are data dependent you should evaluate both signing types and use the one that meets your needs for both speed of signing and data size as well a privacy. Jim Jackson Senior Test Engineer Secure64 Software Corp. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Fresh (non cached) dig
On Jan 5 2009, John Wobus wrote: [...] There is no nameserver operation that dig could do to tell a caching nameserver to act differently for one query. You could clear the nameserver's cache, or even clear the one name you are interested in out of the cache. You can use +norecurse and check whether the AA bit is set in the reply. Even quite old versions of BIND will not set the AA bit in the response if the answer is from the cache, in this case. -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Fresh (non cached) dig
I've been doing some testing lately on query times. What I did was create a new zone and create a * record within it. Then, from a shell, I do "dig @server $RANDOM.test.testdomain.com". For more randomness, you can combine: "dig @server $RANDOM.$RANDOM.test.testdomain.com" That's how I've worked around the caching issue. I also set the TTL on the * record to be 1 second, to ensure that I don't hit any cache. Cheers, Todd. > > If you're referring to your local system's cache, you can bypass this > by specifying a DNS server for dig to query. use @dns.server.domain or > @4.2.2.2(for example) for this. > > If you're referring to the cache on the server you're trying to query, > sorry, that's beyond your control, unless you have root on that server. > > -wes > > On Fri, Jan 2, 2009 at 12:11 PM, Stephen Ward < > stephen.usenet.w...@wibblywobblyteapot.co.uk> wrote: > >> For all my attempts to read the manual on DIG I can't find a way to >> do something really simple. >> >> Is there a way to dig a domain name so even if the results are in >> cache, it will ignore these and re-read them? It's really from a >> testing perspective I'm looking at this. I can mash the keyboard each >> time to try and get a better handle on the query time, but there has >> got to be an easy way to do this? >> >> >> >> -- >> . . . >> ___ bind-users mailing >> list bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users >> >> > --=_Part_21674_19533272.1230941795123 Content-Type: text/html; > charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > If you're referring to your local system's cache, you can > bypass this by specifying a DNS server for dig to query. use > @dns.server.domain or @http://4.2.2.2";>4.2.2.2 (for > example) for this.If you're referring to the cache on the > server you're trying to query, sorry, that's beyond your > control, unless you have root on that server. -wes class="gmail_quote">On Fri, Jan 2, 2009 at 12:11 PM, Stephen Ward > < href="mailto:stephen.usenet.w...@wibblywobblyteapot.co.uk";>stephen.usene t.w...@wibblywobblyteapot.co.uk> > wrote: For all my attempts to read the manual on DIG I can't find a > way to do something really simple. Is there a way to dig > a domain name so even if the results are in cache, it will ignore > these and re-read them? It's really from a testing perspective > I'm looking at this. I can mash the keyboard each time to try > and get a better handle on the query time, but there has got to be > an easy way to do this? > -- . . . ___ > bind-users mailing list href="mailto:bind-users@lists.isc.org";>bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users"; > target="_blank">https://lists.isc.org/mailman/listinfo/bind-users > > > --=_Part_21674_19533272.1230941795123-- > > --===3579383764054783402== 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 > --===3579383764054783402==-- I had a feeling forcing lookups against other servers was all I could do. Problem is, once you've done that it's cached there too. Not a major issue, just wanted to be sure it was not easily doable. -- . . . ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Fresh (non cached) dig
I'm imagining you want a way to make dig act like the caching nameserver and do what it would do and show you the answer. dig +trace does something similar to this. There is no nameserver operation that dig could do to tell a caching nameserver to act differently for one query. You could clear the nameserver's cache, or even clear the one name you are interested in out of the cache. Sometimes querying another name in the domain you are interested in is sufficient for whatever you are checking. In certain situations, it can be very helpful to check someone else's caching nameserver, so it is helpful to have a few such addresses on hand. These days, a lot of sites are closing their caching servers (go figure!), and I've been using OpenDNS's servers. On Jan 2, 2009, at 8:11 PM, Stephen Ward wrote: For all my attempts to read the manual on DIG I can't find a way to do something really simple. Is there a way to dig a domain name so even if the results are in cache, it will ignore these and re-read them? It's really from a testing perspective I'm looking at this. I can mash the keyboard each time to try and get a better handle on the query time, but there has got to be an easy way to do this? -- . . . ___ 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: checkzone
Running an awk or perl script along with checkzones should be able to do this site-specific check (and others you might find helpful) quite easily. On Dec 30, 2008, at 7:51 PM, Mark Andrews wrote: In message <7227c6c70812300937s7a4be464h16db91c6ead84...@mail.gmail.com>, "Mike Zupan" writes: I know of named-checkzone but it doesn't handle missing trailing periods on CNAME's like I want it to Are there any scripts out there that can better verify if a zone file is correct. For example named-checkzone says this line is ok host IN CNAME host.domain.com I know technically it is valid.. but anything out there that might check for it? Thanks again mike You want the "do what I mean not what I say instuction". If someone want's to add code to check of for CNAME to non-existant checks it should be easy. Remember however that CNAME to non-existant is normal for some zones. RFC 2317 "parent" zones have lots of such CNAMEs. The "host" example above would normally result in a CNAME to name within the zone itself. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ 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: Fresh (non cached) dig
On Fri, 02 Jan 2009 16:16:35 -0800, wes wrote: > --===3579383764054783402== Content-Type: > multipart/alternative; > boundary="=_Part_21674_19533272.1230941795123" > > --=_Part_21674_19533272.1230941795123 Content-Type: text/plain; > charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > If you're referring to your local system's cache, you can bypass this by > specifying a DNS server for dig to query. use @dns.server.domain or > @4.2.2.2(for example) for this. > > If you're referring to the cache on the server you're trying to query, > sorry, that's beyond your control, unless you have root on that server. > > -wes > > On Fri, Jan 2, 2009 at 12:11 PM, Stephen Ward < > stephen.usenet.w...@wibblywobblyteapot.co.uk> wrote: > >> For all my attempts to read the manual on DIG I can't find a way to do >> something really simple. >> >> Is there a way to dig a domain name so even if the results are in >> cache, it will ignore these and re-read them? It's really from a >> testing perspective I'm looking at this. I can mash the keyboard each >> time to try and get a better handle on the query time, but there has >> got to be an easy way to do this? >> >> >> >> -- >> . . . >> ___ bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users >> >> > --=_Part_21674_19533272.1230941795123 Content-Type: text/html; > charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > If you're referring to your local system's cache, you can bypass > this by specifying a DNS server for dig to query. use @dns.server.domain > or @http://4.2.2.2";>4.2.2.2 (for example) for > this.If you're referring to the cache on the server > you're trying to query, sorry, that's beyond your control, > unless you have root on that server. -wes class="gmail_quote">On Fri, Jan 2, 2009 at 12:11 PM, Stephen Ward dir="ltr">< href="mailto:stephen.usenet.w...@wibblywobblyteapot.co.uk";>stephen.usenet.w...@wibblywobblyteapot.co.uk> > wrote: For > all my attempts to read the manual on DIG I can't find a way to > do something really simple. > > Is there a way to dig a domain name so even if the results are in > cache, it will ignore these and re-read them? It's really from a > testing perspective I'm looking at this. I can mash the keyboard > each time to try and get a better handle on the query time, but > there has got to be an easy way to do this? > > > > -- > . . . > ___ bind-users mailing > list > href="mailto:bind-users@lists.isc.org";>bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users"; > target="_blank">https://lists.isc.org/mailman/listinfo/bind-users > > > --=_Part_21674_19533272.1230941795123-- > > --===3579383764054783402== 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 > --===3579383764054783402==-- I had a feeling forcing lookups against other servers was all I could do. Problem is, once you've done that it's cached there too. Not a major issue, just wanted to be sure it was not easily doable. -- . . . ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: editing rc.d/named?
bind user wrote: Hi All: I installed 9.6.0 alongside FreeBSD7's default 9.4.2, and it's working fine when i start it manually, but I'm having trouble getting it to start automatically. I edited etc/rc.d/named Don't do that. :) The rc.d system is designed to be configured with rc.conf. You probably want to do this: grep named /etc/defaults/rc.conf >> /etc/rc.conf Make sure that you only have one set of entries for named in /etc/rc.conf and then make your changes there. You probably want to uncomment the named_flags example for the -c option to named. to: command="/usr/local/sbin/named -c /etc/namedb/named.conf" but when I restart the server, the default 9.4.2 install in /usr/sbin/named starts instead of the path to 9.6 above? It's being overridden by rc.conf, which is how it's supposed to work. Thanks for that detailed explanation, Doug...after years of running Unix/Bind blind (because it just worked), I'm finally understanding why things are the way they are. -AK ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Using bind 9.5.0 with Active directory
I already tried ms-self and ms-subdomain. Unfortunately that doesn't
seem to make any difference.
Nico
On Tue, 2008-12-30 at 13:44 -0500, Rob Austein wrote:
> At Tue, 30 Dec 2008 16:05:10 +0100, Nico De Ranter wrote:
> >
> > update-policy {
> > grant TEST.NET krb5-subdomain * A;
> > };
>
> Microsoft invented their own naming scheme for host principals
> ("machi...@realm" instead of "host/mach...@realm").
>
> Try "ms-subdomain" instead of "krb5-subdomain".
> ___
> 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
error compiling bind 9.5.1 with static
I'm trying to install bind 9.5.1 on redhat as 4.5, but am having problems with the configure statement: STD_CDEFINES='-DISC_MEM_USE_INTERNAL_MALLOC=1' ./configure --prefix=/home/named --enable-epoll --disable-threads --enable-largefile --disable-ipv6 --with-openssl=yes CFLAGS='-static -march=pentium4 -O2 -pipe' make[3]: Entering directory `/home/wangmd/bind-9.5.1/bin/named/unix' gcc -I/home/wangmd/bind-9.5.1 -I./include -I./../include -I/home/wangmd/bind-9.5.1/lib/dns/include -I../../../lib/dns/include -I/home/wangmd/bind-9.5.1/lib/isc/include -I../../../lib/isc -I../../../lib/isc/include -I../../../lib/isc/unix/include -I../../../lib/isc/nothreads/include -I../../../lib/isc/x86_32/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DISC_MEM_USE_INTERNAL_MALLOC=1 -D_GNU_SOURCE -static -march=pentium4 -O2 -pipe -I/usr/include/libxml2 -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -c os.c os.c:158: error: conflicting types for 'cap_t' /usr/include/sys/capability.h:44: error: previous declaration of 'cap_t' was here os.c: In function `linux_setcaps': os.c:184: error: `SYS_capset' undeclared (first use in this function) os.c:184: error: (Each undeclared identifier is reported only once os.c:184: error: for each function it appears in.) make[3]: *** [os.o] Error 1 why? Thanks in advance for your response! Regards, ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: cache poisoning counter-measures
On 05.01.09 15:29, Chris Henderson wrote: > I'm trying to implement some basic counter-measures against the > Kaminsky bug. I have had to configure my switch to allow any incoming > query to TCP and UDP port 53 on my slave DNS server. I was wondering > if this is going to cause any problem as far as security is concerned. > > Bind version 9.4.1 running in chroot jail. The bug does not lie server operations. It lies in client operations. While people are querying your slave server, you have no problem. If you send recursive queries to the mentioned name server, and it sends queries out, that is a problem. It must send queries from randomised ports, which means, that not only packets to tcp/udp port 53 from outside must be allowed, but packets from any port on your server to tcp/udp 53 anywhere must be allowed and also packets from tcp/udp port 53 anywhere to any port on your server must be allowed. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux IS user friendly, it's just selective who its friends are... ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind open to query from anyone
In general I would think that it isn't recommended unless it's intended, you probably don't want random client querying your servers for content you don't control. To kill this add "recursion no;" in options, if you do want this enables for certain prefixes have a look at "allow-recursion". Good luck, /Jonathan On Mon, Jan 5, 2009 at 3:15 AM, Chris Henderson wrote: > I've setup a secondary name server which works as a secondary or slave > name server for my zone or domain name. However, I have tested and > noticed that I can query for non-authoritative answers from my > secondary or slave name server from outside my network. That is, any > one can use my name server to query any host name, eg. www.google.com, > www.yahoo.com etc. Is this a bad idea? How can I stop this? > > Thanks for any suggestions. > ___ > 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 open to query from anyone
I've setup a secondary name server which works as a secondary or slave name server for my zone or domain name. However, I have tested and noticed that I can query for non-authoritative answers from my secondary or slave name server from outside my network. That is, any one can use my name server to query any host name, eg. www.google.com, www.yahoo.com etc. Is this a bad idea? How can I stop this? Thanks for any suggestions. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
error compiling bind 9.5.1 with static
I'm trying to install bind 9.5.1 on redhat as 4.5, but i am having problems with the configure statement: STD_CDEFINES='-DISC_MEM_USE_INTERNAL_MALLOC=1' ./configure --prefix=/home/named --enable-epoll --disable-threads --enable-largefile --disable-ipv6 --with-openssl=yes CFLAGS='-static -march=pentium4 -O2 -pipe' make[3]: Entering directory `/home/wangmd/bind-9.5.1/bin/named/unix' gcc -I/home/wangmd/bind-9.5.1 -I./include -I./../include -I/home/wangmd/bind-9.5.1/lib/dns/include -I../../../lib/dns/include -I/home/wangmd/bind-9.5.1/lib/isc/include -I../../../lib/isc -I../../../lib/isc/include -I../../../lib/isc/unix/include -I../../../lib/isc/nothreads/include -I../../../lib/isc/x86_32/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DISC_MEM_USE_INTERNAL_MALLOC=1 -D_GNU_SOURCE -static -march=pentium4 -O2 -pipe -I/usr/include/libxml2 -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -c os.c os.c:158: error: conflicting types for 'cap_t' /usr/include/sys/capability.h:44: error: previous declaration of 'cap_t' was here os.c: In function `linux_setcaps': os.c:184: error: `SYS_capset' undeclared (first use in this function) os.c:184: error: (Each undeclared identifier is reported only once os.c:184: error: for each function it appears in.) make[3]: *** [os.o] Error 1 why? Thanks in advance for your response! Regards, ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: split view dns, with a shared dynamic zone?
On Tue, Dec 30, 2008 at 08:28:06PM -0800, Paul B. Henson wrote: > On Tue, 30 Dec 2008, [iso-2022-jp] JINMEI Tatuya / � wrote: > > > So, you at least need to fix one on-memory zone image that can be > > dynamically updated. You'll then have to configure the other view where > > the "shared" zone is a secondary of the real dynamic zone in the other > > view, or a forward zone for which all queries to be forwarded to the real > > zone. (I've not tried this configuration by myself, so I'm not 100% sure > > if this can implement what you need). > > It's making my brain hurt ;), but I kind of see what you're suggesting. A > single server both master and secondary for the same zone in different > views. That should work for the "both the same" part. Then if I configure > the secondary zone to forward updates to the primary zone both views would > be the same and clients in either view could update. I guess the primary > zone would have to be in the view in which the IP of the actual server > resides, so the forwarded update from the server to itself ( 8-/, will that > even work?) hits the primary. > > I think it's kind of a deficiency of bind not to support this type of > configuration more cleanly. It would be nice if you could have both split > view zones and standalone zones on the same server. Perhaps a feature > request :)? > > Thanks for the suggestion, I'll play with it and see what happens. > Btw setup with slave zone in second view is described in FAQ as well: - https://www.isc.org/faq/bind - Configuration and Setup Questions -> "How do I share a dynamic zone between multiple views?" Adam -- Adam Tkac, Red Hat, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
