Problem with rndc
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. But if I try one of these two commands: rndc refresh example.com rndc retransfer example.com I get an errormessage from rndc: rndc: 'refresh' failed: not found or rndc: 'retransfer' failed: not found I get this with every domain I tried. I checked if I use the correct rndc and the version is 9.6.1-P1. Can anyone give me a hint what I'm doing wrong? Thanks, Tom. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
what does dig +trace do?
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 example.com I get something like this: ; <<>> DiG 9.8.0-P4 <<>> +trace example.com ;; global options: +cmd . 10800 IN NS root1. . 10800 IN NS root2. . 10800 IN NS root3. . 10800 IN NS root4. ;; Received 159 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms ;; connection timed out; no servers could be reached I don't understand why there is a timeout. Next zone on the trace should be the com. domain which is hosted on the same servers as the rootzone. I don't see any DNS-problems at all, only the +trace-option is behaving weird. Can anybode tell me why? What does this option what normal DNS queries don't do? Tom. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
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. > 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 IN NS root1. . 10800 IN NS root2. . 10800 IN NS root3. . 10800 IN NS root4. root1. 10800 IN A 10.111.111.111 root2. 10800 IN A 10.111.112.112 root3. 10800 IN A 10.111.113.113 root4. 10800 IN A 10.111.114.114 com. 10800 IN NS root3. com. 10800 IN NS root4. All these records I can query with dig without any problem, but dig +trace still fails. :-( -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RE: RE: what does dig +trace do?
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 your local nameservers, it seems to me they don't > have access to the Internet or a firewall is blocking some of the > response or you don't have the root cache file to do hints or > combination of all the above. Hi Gary, yes, all of the above. But this is no mistake, it's the intended architecture. My DNS-server is an internal one without any conection to the internet. There is no root hint file because I have a internal root zone on my own. And my root servers have the glue records in this root zone and the NS records for the TLDs as well. So dig +trace should work. Or has the trace-option the IP-addresses of the Internet-root-servers hardwired in the the sourcecode? -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
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 right, thank you. With this I see the glue records: ; <<>> DiG 9.8.0-P4 <<>> +trace example.com ;; global options: +cmd . 10800 IN NS root1. . 10800 IN NS root2. . 10800 IN NS root3. . 10800 IN NS root4. root1. 10800 IN A 10.111.111.111 root2. 10800 IN A 10.111.112.112 root3. 10800 IN A 10.111.113.113 root4. 10800 IN A 10.111.114.114 ;; Received 159 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms ;; connection timed out; no servers could be reached The main problem is still the same though. The trace option fails with a timeout. Even thought I'm operating on the shell of one of the root-servers itself (so there is not much network in between to cause trouble). -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
[Solved] was: what does dig +trace do?
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 to use IPv6 addresses. [RT #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 right, thank you. With this I see the glue records: > > ; <<>> DiG 9.8.0-P4 <<>> +trace example.com > ;; global options: +cmd > . 10800 IN NS root1. > . 10800 IN NS root2. > . 10800 IN NS root3. > . 10800 IN NS root4. > root1. 10800 IN A 10.111.111.111 > root2. 10800 IN A 10.111.112.112 > root3. 10800 IN A 10.111.113.113 > root4. 10800 IN A 10.111.114.114 > ;; Received 159 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms > > ;; connection timed out; no servers could be reached > > > The main problem is still the same though. The trace option fails with a > timeout. Even thought I'm operating on the shell of one of the root-servers > itself (so there is not much network in between to cause trouble). > > -- > NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! > Jetzt informieren: http://www.gmx.net/de/go/freephone > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
[UNsolved] was: what does dig +trace do?
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 to >use IPv6 addresses. [RT #23297] > > So I only have to update to the new version of named and dig +trace will > work. :-) > I thought this has to be it, because I don't find any error in my config and my (linux)server has IPv6 assigned to it's IPv4 interfaces without me using IPv6 at all (nor does my network). But: The problem still persists. The only difference is the errormessage. With 9.8.0-P4 I got this error: ;; connection timed out; no servers could be reached With version 9.8.1 I now get this error: dig: couldn't get address for 'root1': not found But of course, when I do a dig for root1 I get the IP for it just fine. The trace-option does something strange which is not happening if I do all the steps of a trace with dig one by one manually. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [UNsolved] was: what does dig +trace do?
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 destination is reached. 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 asking for the A-record of root1. And of course I get the correct answer from named. The +trace option does not do this! Instead, the +trace-option is using the searchsuffix in the resolv.conf and is asking for root1.my.search.suffix. and NOT for root1. This is why the +trace option fails every time. After deleting the searchsuffix in resolv.conf, dig +trace is working fine without any error. In my oppinion it's a bug that dig +trace behave in a differrent way than doing the queries with dig one by one. Tom. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [UNsolved] was: what does dig +trace do?
> > 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 asking for the > > A-record of root1. And of course I get the correct answer from named. > > > > The +trace option does not do this! > > Instead, the +trace-option is using the searchsuffix in the > > resolv.conf > > and is asking for root1.my.search.suffix. and NOT for root1. > > This is why the +trace option fails every time. > > > > No, IMHO, it's a bug in your root zone. > Names without dot at end are relative. Change your root zone to say > . IN NS root1. > . IN NS root2. > > (with dots appended) and you should be home. > No. Sorry: The answer quoted above I typed by hand instead of copy&paste and so I forgot the dots at the end. In my root zone there are of course dots at the end of the names. But the +trace option is ignoring these dots. As this bug is only visible if you have your own root-zone and Nameservers directly in this zone, I think there are not many people out there who will stumble over this. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [UNsolved] was: what does dig +trace do?
> "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 being a flat namespace (names without dots) > for hostnames to a heirachical namespace (names with *internal* > dots) a 1/4 century ago. http://tools.ietf.org/html/rfc921 > > Hostnames without dots are now local (e.g. localhost) or need to > be qualified (resolv.conf: search). > Yes, I heard something about a Internet that was invented some time ago... :-) But seriously: I don't see in the RFC that it is forbidden to have a hostname directly in the root-zone (without a internal dot). -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
updating Bind made it slower
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 server with the exact same config & hardware to compare it. Updating from version 9.4.1 to version 9.8.0-P4 brought a increase for "rndc reload" from 25 seconds (yes, I have a lot of zones and quite big ones) to 45 seconds (these numbers are from a slower server, Sun T2000, for my faster servers I have no old servers to compare the numbers). Is this a knwon issue with the newer versions of named? Is there something I can do about it to tweak the numbers? Tom. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: updating Bind made it slower
> > 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 really need "reload", or > would "reconfig" suffice? > I will try it if this is reducing the times and if a reload is realy not needed. If it works, I will change my updating-scripts. Thank you! -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: updating Bind made it slower
> 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 "rndc reload" to make this new config activ. This process is now taking much more time, leading to outages in the DNS-service :-( I'll try to replace it with rndc reconfig. Not sure if this really is sufficient. Tom. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: updating Bind made it slower
> 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 "rndc reconfig" on five differrent servers, Solaris and Linux, 9.8.0 and 9.4.1. On all servers the same result: Both commands take roughly the same amount of time! Sometime rndc reconfig even took a bit longer. 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. But the results are clear: rndc reconfig is no solution for me. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-transfer not covering ixfr requests?
> > 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 query for the SOA of the zone to determine if a update is necessary. If your servers aren't allowed to do a query, how should they get the SOA? And without a SOA, you don't have the serial number of the zone, so you can't do IXFR. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: updating Bind made it slower
> > 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 long do things take? about 40 seconds. (I have two boxes with newer hardware where it is faster) > How big is your config? about 200k lines and about 30k zones. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: updating Bind made it slower
> > 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 affect my my servers, at lease not when I do rndc reconfig or reload. > > When there are blog posts from ISC which essentially address this issue, > it > would be good to at least try the suggested solution before complaining > too > loudly. > To which solution you are referring to? -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Defense against a client?
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 mostly solved in short time. One of these cases my DNS server can handle, but sometimes there is more than one of these cases at the same time and I have a load problem which causing problems for all clients of my DNS servers. My question: Is there any possibility in Bind to give a quoata to a client? e.g. that from a given IP no more than houndred queries per second are allowed and the rest is to be blackholed. That way only the client causing the load would have a problem but not all other clients. Is there such a possibility? I found nothing in the documentation. Or are there other ways to achive this? How do you guys do this? Tom. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Defense against a client?
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-limit-incoming.html > thank you, this is very helpfull. I will try it this way. -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Logging issue with bind
> 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 0 i.e. off.
correct.
> >
> > Just remove the "severity" line.
No, let it be, it's nothing wrong with it.
> Still not working I'm afraid.
> What else could it be? Some debian-specific bug?
No, nothing Debian-specific :-)
You told Bind how to log queries in the config.
Now you have to tell Bind that he should start with the querylogging.
Do:
rndc querylog
Tom.
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: block ddns by name
> 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 the doc for
update-policy:
I have a few DHCP-clients which are sending really stupid hostnames to the DHCP
and via DHCP they got into my DNS zones.
Example: A few IP-phones are sending as their hostname eight times xFF. And
this not printable name is then in DNS where I (and a few older nameserver)
don't want it.
So is there something possible like
update-policy { deny "*" name /^a-zA-Z0-9_\-/; };
?
(For thos who don't speak regex: deny all names with something in it what is no
letter or digit or underscore or dash.
Tom.
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Views on differrent interfaces
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 answers from view number one and all other from view number two. Now what I want to do: The queries coming via the first network interface should still go to differrent views depending on the source IP like their do now. But queries coming via the second interface should always get their answer from the second view no matter what the source IP is. Please tell me that this is easy :-) Tom. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Views on differrent interfaces
Thank you for your answer.
But this doesn't work: With match-destination and match-clients I can only
define the same match-clients statement for both destionation interfaces, not
differrent one.
The only workaround I see how to rech my goal by only using these commands is
to define a third view which has the exactly same data like the first view.
Then I could use machting rules like this:
view 1 { match-destination { interface1 }; };
view 2 { match-clients ( trusted_nets }; match-destination { interface2 }; };
view 3 { match-clients { non-trusted_nets }; match-destination { interface2 };
};
I hoped there would be a way to do this whith only two views. Like inserting
some logic: matchif( destination=interface1 OR (destination=interface2 AND
client=non-trusted_nets) )
Original-Nachricht
> Datum: Wed, 21 Apr 2010 17:24:55 +1000
> Von: Mark Andrews
> 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...@isc.org
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind says 'clocks are unsynchronized' but they are not
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 > unsynchronized' when doing zone transfers with TSIG. The problem is the > clocks are correct, synced with ntp and everything. Maybe one of the two servers doing the zone transfer is running in a chroot where it has another time setting than the server itself? > > The problems seems to occur mostly on zone transfers that take a long > time (ie. hours). > HOURS?? There is defnitly something wrong. I cannot imagine a zone so big or a connection so slow that a zonetransfer could take hours. Or do you make a axfr of the tld com. over a serial connection? ;-) Tom. -- GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RT-Number?
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? (wouldn't make much sense to publish their numbers if the tickets themself couldn't be read, but I couldn't find them on the ISC homepage) -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
