On Fri, Apr 8, 2011 at 4:04 PM, Doug Barton wrote:
> s/impossible/a matter of actually doing the work/
>
> Please stop foisting your broken stuff on the rest of the Internet. In the
> amount of time you've spent discussing this on the list you could have fixed
> several dozen of those broken zones
the implementation of resolution dnssec for the bind dns dry this
natively in the distribution centos 5.5 is feasible
try a simple config
Le vendredi 08 avril 2011 à 18:38 +0200, fddi a écrit :
> Hello,
> I was trying to add DLZ support to bind on CentOS 5.5 so it's
> bind-9.3.6-4.P1.el5_5
>
>
On Apr 8, 2011, at 2:23 PM, kapetr wrote:
>> What does:
>>
>> dig +short rs.dns-oarc.net txt
>>
>> ...do when your VPN tunnel is up?
>
> After VPN up and restart of BIND:
>
> hugo@duron650:~$ dig +short rs.dns-oarc.net txt
> ;; connection timed out; no servers could be reached
> hugo@duron650:~
> If you think that the adding of a new route is the
> issue, then just
> restart named.
As I wrote - it do not help.
>
> It might help if you post your named.conf to see
> if you have something
> wrong set in there.
In attachment.
(BTW - I have try it also without DNSSEC adds - so with "out
Thanks for replay,
> > The VPN must be used as target - default route.
> > It is standard in
> > > usage of such services, it is what I need and
> > want.
> >
> It's not standard behavior, but if it is what you
> want, very well.
I had mean only standard in usage of such services - all of them
On Apr 8, 2011, at 1:07 PM, kapetr wrote:
> I absolutely do not understand your answer.
OK.
> I use the VPT to anonymisation. I need all traffic to go over the VPN.
OK. That's not the usual method of operation for a routed VPN, but is more
commonly used when doing bridging.
> The VPN must be
On 4/8/2011 5:07 AM, Rodney Hives wrote:
When you have hundreds / thousands of existing zones (from shared
hosting) from users it is sometimes impossible to go in a fix all of the
mistakes.
s/impossible/a matter of actually doing the work/
Please stop foisting your broken stuff on the rest of
On 4/7/2011 11:41 PM, Dennis Perisa wrote:
Hi all,
We are running a couple of resolvers using BIND 9.6.2-p2 on FreeBSD 7.1
You are running an old BIND on an unsupported version of FreeBSD
(http://www.freebsd.org/security/security.html#sup). Your best bet at
this point would be to upgrade the
Hello,
I absolutely do not understand your answer.
I use the VPT to anonymisation. I need all traffic to go over the
VPN.
Not just packets to "LAN" of VPN. I am not interesting at all about
communication with other PCs in that VPN.
The VPN must be used as target - default route. It is standard i
John Wobus writes:
> I think you want a *.com entry as well as the * entry.
I have now put in an entry like:
*.com. IN A 139.78.6.193
I still have the same behavior as before. The allowed
domain succeeds and all others get a SERVFAIL where they should
resolve to 139.78.2.193 whic
All the previously-mentioned issues apply, but (obviously)
round robin could be made to offer a select server twice as
often by giving that server an additional address and
A record. Something similar for nameservers could
be devised.
I had a vague recollection that one could simply
duplicate an
On Apr 8, 2011, at 10:58 AM, Martin McCormick wrote:
I am trying to set up bind9.7.2P3 in a special manner such as is
used in network registration setups in which named always
returns the address of a registration server except for a few
other domains that supply updates and antivirus scans, etc
Hi--
On Apr 8, 2011, at 10:27 AM, kapetr wrote:
> After connect to them (new network device created - tun or tap and
> default route changes) my BIND is not able to reach other (root)
> nameservers. And resolve requests fails.
This is due to how you are operating your VPN. Change it to only add
Hello,
[first sorry please my English]
I have installed Bind9 on Ubuntu 10.10 - just for personal use (no
zones, ...).
I did not have any problems until I now try to use some free VPN
services based on PPTP or OpenVPN.
After connect to them (new network device created - tun or tap and
default r
Hello,
I was trying to add DLZ support to bind on CentOS 5.5 so it's
bind-9.3.6-4.P1.el5_5
I found out that the CentOS rpm does not have DLZ support built in and
trying to patch bind manually
the patch looks like to be for 9.2.2 version so it does not work on 9.3.6
anyone has a solution on h
In message , Rodney Hives w
rites:
>
> On Fri, Apr 8, 2011 at 1:49 AM, Mark Andrews wrote:
>
> > Please explain the operating conditions under which when you think
> > this is a sensible thing to do?
> >
> > A nameserver without address records is pointless.
> > A nameserver pointing to a CNAME
I am trying to set up bind9.7.2P3 in a special manner such as is
used in network registration setups in which named always
returns the address of a registration server except for a few
other domains that supply updates and antivirus scans, etc.
In this case, I have microsoft.com as the one
greetings,
is there a way to programmatically determine if there are any zones
frozen? if so, any way to determine the specific zone(s)?
what i'm wanting to do is write a monitoring script to sound an alert if
there are any zones that have been frozen for more then x minutes.
rndc doesn't provi
On 8 April 2011 12:00, Patrick Rynhart wrote:
> (where the host 192.168.239.2 is "upstream" DNS in my case), then DNS
> queries are resolved by the client but do not appear to be cached, i.e.:
>
> # rndc dumpdb
> #
>
> What am I missing ?
>
Remember that rndc dumpdb doesn't actually dump the cac
On Fri, Apr 8, 2011 at 1:49 AM, Mark Andrews wrote:
> Please explain the operating conditions under which when you think
> this is a sensible thing to do?
>
> A nameserver without address records is pointless.
> A nameserver pointing to a CNAME/DNAME causes resolution problems.
>
Here is an exa
> Can you explain why you need that?
>
When you have hundreds / thousands of existing zones (from shared hosting)
from users it is sometimes impossible to go in a fix all of the mistakes.
Right now these zones work (queries are answered in 9.6) but the domains
are not even loaded when trying to u
Dnia 2011-04-08 23:00 Patrick Rynhart napisał(a):
>On 8/04/2011 10:11 p.m., Tony Finch wrote:
>
>> No, only DNS requests that are handled by the server itself are cached.
>> There is no sniffing going on.
>>
>> Tony.
>
>Thank you for the clarification. If I add "nameserver 127.0.0.1" to the
>V
Hi Dennis,
There are some fixes for cache management issues on recursive servers
that have been released recently. This sounds like it might have been
one of those problems.
If you want to stay on 9.6, then I'd recommend 9.6-ESV-R4 to you
Otherwise you might like to take a look at 9.7.3.
Cathy
Dnia 2011-04-08 21:58 Patrick Rynhart napisał(a):
>I am new to using BIND and thought that I would start by setting up a
>caching-only name server on a VM running CentOS 5.5. While in this
>mode, my understanding is that named should be passively listening for
>any DNS requests that are resolve
On 8/04/2011 10:11 p.m., Tony Finch wrote:
> No, only DNS requests that are handled by the server itself are cached.
> There is no sniffing going on.
>
> Tony.
Thank you for the clarification. If I add "nameserver 127.0.0.1" to the
VM (and comment out the existing name servers) and attempt to r
Patrick Rynhart wrote:
> I am new to using BIND and thought that I would start by setting up a
> caching-only name server on a VM running CentOS 5.5. While in this
> mode, my understanding is that named should be passively listening for
> any DNS requests that are resolved and be adding them to
I am new to using BIND and thought that I would start by setting up a
caching-only name server on a VM running CentOS 5.5. While in this
mode, my understanding is that named should be passively listening for
any DNS requests that are resolved and be adding them to its local DB.
Adding localhost t
Dnia 2011-04-08 09:11 Flex Banana napisał(a):
>hello floks,
>
>i have a DNS server running bind-9.7.3 on a linux box, 3 differents
networks connected to 3 ethernet cards:
>
>eth0: 192.168.1.1/24
>eth1: 172.16.1.1/24
>eth2: 10.140.27.1/24
>
>i would like to have the same DNS resolving the goo
On 08.04.11 09:11, Flex Banana wrote:
> how to resolve this ? i would like to have the same results but in the
> order that i can ping the server with i's hostname:
>
> from eth0 network (192.168.1.1/24)
> $ host mydns.example.com
> mydns.example.com has address 192.168.1.10
> mydns.example.com h
hello floks,
i have a DNS server running bind-9.7.3 on a linux box, 3 differents networks
connected to 3 ethernet cards:
eth0: 192.168.1.1/24
eth1: 172.16.1.1/24
eth2: 10.140.27.1/24
i would like to have the same DNS resolving the good address from the good
network, example:
from the 19
Hi all,
We are running a couple of resolvers using BIND 9.6.2-p2 on FreeBSD 7.1 and
are peaking at 10,000 queries per second (qps).
Recently, the qps on one resolver dropped dramatically to 3000 during the
peak period. The secondary picked up the additional queries and we had a
few complaints ab
31 matches
Mail list logo