> Von: Tony Finch
> > Does anyone know if there is a way to prevent the creation of certain
> > records - by name?
>
> update-policy {
> deny "*" name "internal.example.com";
> # ...
> };
Hi,
I have a quite similar question but can't figure it out from t
> Von: Raven
> > > I am currently trying to setup query logging with bind on a debian
> > > server, but I seem unable to.
> > > logging {
> > >channel munin_log {
> > > file "/var/log/bind9/query.log" versions 30 size 15m;
> > > severity dynamic;
> > "severity dynamic" starts at
Original-Nachricht
> Datum: Mon, 16 Jan 2012 11:49:46 +0100
> Von: Roel Wagenaar
> Betreff: Re: Defense against a client?
>
> In this case iptables is your friend.
>
> One of my solutions is partly based on this:
>
> http://codingfreak.blogspot.com/2010/01/iptables-rate-limi
Hi,
I have a problem with the load on my Bind. Normally it's fine, but from time to
time there are clients which causes through a misconfiguration or a failed
local service (not intentionally) a very high amount of queries. After finding
and informing the responsible person this problem is most
>
> Why not try the latest version, really? Pick a test host. Install
> 9.8.1+.
> Time it again. Then let's talk.
Such things take time.
Did it now, but it didn't changed anything.
It seemes that the performance optimization (which is mentioned in the
releasenotes for startup) doesn't affec
> > I have not the slightest clue why, I had suspected that rndc reconfig
> > would be much faster, especially is there is no altering in the
> > config at all.
>
>
> How are you testing this?
>
> 'time rndc reconfing'?
Yes.
> Or do you stop answering queries and time that?
No.
> How l
>
> The odd part is that both NS3 and NS4 weren't able to request ixfr
> transfers.
> Shouldn't allow-transfer cover these kind of transfer requests as well?
>
First: Do you have statements "provide ixfr;" and "request ixfr;" in your
config?
Second: To do a ixfr a server is first sending a
> In this case "rndc reconfig" should be sufficient. This command tells
> BIND to re-read config file and load all new zones without touching
> any previously loaded zones.
This was my understanding (after reading the text from rndc) as well.
But to my surprise:
I tested "rndc reload" against "r
> It is not clear in your question, are you use "rndc reload" or "rndc
> reload zone.name"? Latter will be faster in case if you change one or
> few zones in one pass of your updating-script.
I generate from my database the complete named.conf, especially including new
zones and then trigger a
> > I just updated a couple of my DNS-servers from the rather old version
> > 9.4.1 to a newer version 9.8.0-P4.
> >
> > After this I have problem with outages. Looking into it, I found that
> > the time for a "rndc reload" has nearly doubled!
>
> This has been pointed out to me before; do you re
Hi,
I just updated a couple of my DNS-servers from the rather old version 9.4.1 to
a newer version 9.8.0-P4.
After this I have problem with outages. Looking into it, I found that the time
for a "rndc reload" has nearly doubled!
I've made tests before the update and I have still a few old serv
> "dig +trace" calls getaddrinfo() and that needs to be able to resolve
> the hostname (without dots at the end). getaddrinfo() is called
> so that we don't have to have a full blown iterative resolver in
> dig.
>
I see. So no way to solve this one in dig itself.
> The Internet moved from bei
> > In my case, dig is asking for the nameservers of the root-zone and is
> > getting the answer:
> > . IN NS root1
> > . IN NS root2
> > etc
> >
> > Next dig is asking for the A-record of root1. And here is the
> > differrence:
> >
> > If I do "dig root1" dig is asking exactly this, it is ask
I found the cause of my problem (and a solution):
dig +trace actually has another behaviour than doing the trace manually step by
step with dig.
For a trace, dig is asking for the NS-records, then for the IP-address of the
nameserver found and then go on asking this nameserver. Till the desti
I spoke too soon :-(
>
> I think I found the reason why dig +trace always failed with a timeout.
> From the announcement of Bind 9.8.1 from earlier today:
>
> * If the server has an IPv6 address but does not have IPv6
>connectivity to the internet, dig +trace could fail attempting
#23297]
So I only have to update to the new version of named and dig +trace will work.
:-)
Original-Nachricht
> Datum: Wed, 31 Aug 2011 17:36:46 +0200
> Von: "Tom Schmitt"
> An: bind-users@lists.isc.org
> Betreff: Re: RE: what does dig +trace do?
>
> >> What strikes me as odd is that the first query does return 4 (internal)
> >> root servers, but no glue records ?
> >
> >I have no idea why this is this way.
>
> Because +trace only displays the answer section of the responses by
> default.
> Try "dig +trace +additional".
Hi Chris,
you are
Original-Nachricht
> I believe what is missing the root cache file.
>
> The root server would have glue records point to GTLDs, like this
>
> Then the GTLDs would have glue records pointing to nameserver of the
> domain you are trying to trace.
>
> What you are seeing is yo
>
> What strikes me as odd is that the first query does return 4 (internal)
> root servers, but no glue records ?
I have no idea why this is this way.
> Given those root name servers, do you have A-records for root[1234] in
> your root zone ?
Yes, of course. From my root-zone:
. 10800 I
Hi,
I have a question: What does dig +trace exactly do?
The reason for my question is:
I have a internal-only DNS in our company with my own root-zone. And normaly
all things are fine. But when there is an issue I would like to analyze with
dig +trace, the command fails.
If I do dig +trace exa
I just read the release notes from Bind 9.7.2-P3 and noticed that behind every
short description of a change there is a number beginning with RT.
I hope this is some kind of ticket number were more detailed information about
this change could be found?
My question:
Were do I find these tickets?
Original-Nachricht
> Datum: Wed, 07 Jul 2010 13:13:45 +0200
> Von: Niklas Jakobsson
> An: bind-us...@isc.org
> Betreff: bind says \'clocks are unsynchronized\' but they are not
> Hello,
>
> I have some problems with our bind servers complaining that 'clocks are
> unsynchronize
drews
> An: "Tom Schmitt"
> CC: bind-us...@isc.org
> Betreff: Re: Views on differrent interfaces
>
> match-destination.
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma.
Hi,
I have a simple configuration question and can't find an answer in
doc/arm/Bv9ARM.ch06.html :
I have a nameserver with two differrent views which is listening on two
differrent networkinterfaces. Till now its configured that all queries coming
from a defined IP-range are getting the answer
Hi,
I'm running Bind 9.6.1-P1 on a Solaris 10-Box as a slave with different views
and it is running fine.
Now I want to use rndc. I don't have a rndc.conf, only a rndc.key.
If I try something like
rndc reload
rndc reconfig
rndc stop
rndc halt
it is working fine and does what I expect it to do.
25 matches
Mail list logo
