On 21/12/13 14:10, Matus UHLAR - fantomas wrote:
> On 21.12.13 14:00, Daniel Lintott wrote:
>> I have pasted the output from running named as above here:
>> http://pastebin.com/FprFEkyb
>>
>> I had changed the zone on the master and reloaded named a coup
On 21/12/13 01:15, Mark Andrews wrote:
>
> I think this has got to the point of running named in the
> foreground with debugging on the master.
>
> named -g -d 100
>
> This will log everything to stderr.
>
I have pasted the output from running named as above here:
http://pastebin.com/Fp
On 20/12/13 21:59, Cathy Almond wrote:
> It might be a silly question - but have you checked how many instances
> of named you have running on the master (thinking that you might not be
> 'talking to' the one you think you are)?
>
There appears to only be one instance, from what I can see
[root@
On 20/12/13 11:40, Matus UHLAR - fantomas wrote:
>>> what's in logs on master?
>
> On 20.12.13 11:21, Daniel Lintott wrote:
>> Nothing seems to be logged for any transfers on the master... even with
>> the following logging statement added
>>
>> log
On 20/12/13 11:12, Matus UHLAR - fantomas wrote:
> On 19.12.13 19:27, Daniel Lintott wrote:
>> The following is logged on the slave:
>> Dec 19 17:51:48 server2 named[7866]: transfer of
>> '5.168.192.in-addr.arpa/IN' from 192.168.5.1#53: connected using
>> 19
On 20/12/13 09:16, Cathy Almond wrote:
> Noting this in the master zone:
>> allow-transfer {
>> 192.168.5.2;
>> };
>
> Check that the slave actually is using that source address for the TCP
> transfer (which I grant would be odd to be different, if your othe
I have now tried recreating the zone file on the master, removed and
re-added the configuration for the zone on both master and slave, yet
still I am unable to transfer the zone.
I have also added the following logging to the master server:
logging {
channel xfer {
file "/
On 19/12/13 19:44, David Forrest wrote:
> This is an unrouteable private zone. I slave root as you appear to do
> and serve your own 5.168.192.in-addr.arpa. as I do. I don't expect it
> to transfer out as it only has meaning in an internal view.
>
> Dave
I'm not expecting the zone to transfer
On 19/12/13 19:37, /dev/rob0 wrote:
> How about when the zone loaded initially? I suspect a problem in the
> master zone file itself. Try named-checkzone(8) on it.
>
named-checkzone seems to be happy:
zone 5.168.192.in-addr.arpa/IN: loaded serial 1234478001
OK
> Can you query SOA and PTR records
On 19/12/13 18:50, Matus UHLAR - fantomas wrote:
> Does the master answer SOA requests for all requests correctly?
It would appear so, yes:
dig @192.168.5.1 5.168.192.in-addr.arpa SOA
; <<>> DiG 9.9.4-P1 <<>> @192.168.5.1 5.168.192.in-addr.arpa SOA
; (1 server found)
;; global options: +cmd
;; G
On 19/12/13 18:37, Timothe Litt wrote:
> I doubt you'll get help without providing configuration data for
> master
> and slaves and exact log and error messages.
>
> But I'll take one blind guess. DNSSEC validation enabled and your
> in-addr.arpa zones are not delegated and not in DLV?
>
DNSS
reverse, 1 IPv4 Reverse) the IPv4
reverse zone is the only one which fails.
The configuration on the master is the same for all zones.
Any ideas?
Regards
Daniel Lintott
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
12 matches
Mail list logo
