From: Artist on
My slave DNS servers are not able to do AXFR transfers from my Bind9
master. This is in spite of the slave's IP numbers being listed in the
master's allow-transfer directive. Should listing in the allow-transfer
directive be sufficient for the slaves to do AXFR? Or is there something
else that needs to be done?

--
To reply directly remove the sj. from my email address. This is a spam
jammer.
From: Pascal Hambourg on
Hello,

Artist a �crit :
> My slave DNS servers are not able to do AXFR transfers from my Bind9
> master.

Can you elaborate (e.g. error messages in logs of both master and slaves) ?

> This is in spite of the slave's IP numbers being listed in the
> master's allow-transfer directive. Should listing in the allow-transfer
> directive be sufficient for the slaves to do AXFR? Or is there something
> else that needs to be done?

I assume the slave zones definitions contain the proper "masters" list.
Does the master allow DNS queries over TCP port 53 (no firewall) ?
From: Artist on
Pascal Hambourg wrote:
> Hello,
>
> Artist a �crit :
>> My slave DNS servers are not able to do AXFR transfers from my Bind9
>> master.
>
> Can you elaborate (e.g. error messages in logs of both master and slaves) ?

I do not have access to the error logs of the slaves. Since I have only
one server, and bind9 does not allow both master and slave for the same
domain, I am running only the master and not the slaves. The slaves are
on free services at ns2.afraid.org and puck.nether.net.

>
>> This is in spite of the slave's IP numbers being listed in the
>> master's allow-transfer directive. Should listing in the allow-transfer
>> directive be sufficient for the slaves to do AXFR? Or is there something
>> else that needs to be done?
>
> I assume the slave zones definitions contain the proper "masters" list.
> Does the master allow DNS queries over TCP port 53 (no firewall) ?

I had made an effort at making sure the iptables firewall is not
blocking by executing these commands:
/sbin/iptables -A INPUT -p tcp -i eth0 -s 66.252.5.14/32 --dport 53 -j
ACCEPT
/sbin/iptables -A INPUT -p tcp -i eth0 -s 204.42.254.5/32 --dport 53 -j
ACCEPT

I have looked for error messages written by the master in
/var/log/syslog. There are't any from bind or named. There is in the
file etc/bind/named.conf.local the directive:

logging {
channel my_file {
file "/var/named/log.msgs" versions 3 size 3m;
severity info;
};
category general { my_file; };
};

But the file /var/named/log.msgs does not exist so there has been no
logging there.


--
If you desire to respond directly remove the "sj." from the domain name
part of my email address. It is a spam jammer.
From: Pascal Hambourg on
Artist a �crit :
> Pascal Hambourg wrote:
>>
>> Artist a �crit :
>>> My slave DNS servers are not able to do AXFR transfers from my Bind9
>>> master.
>> Can you elaborate (e.g. error messages in logs of both master and slaves) ?
>
> I do not have access to the error logs of the slaves. Since I have only
> one server, and bind9 does not allow both master and slave for the same
> domain, I am running only the master and not the slaves. The slaves are
> on free services at ns2.afraid.org and puck.nether.net.
>
>>> This is in spite of the slave's IP numbers being listed in the
>>> master's allow-transfer directive. Should listing in the allow-transfer
>>> directive be sufficient for the slaves to do AXFR? Or is there something
>>> else that needs to be done?
>> I assume the slave zones definitions contain the proper "masters" list.
>> Does the master allow DNS queries over TCP port 53 (no firewall) ?
>
> I had made an effort at making sure the iptables firewall is not
> blocking by executing these commands:
> /sbin/iptables -A INPUT -p tcp -i eth0 -s 66.252.5.14/32 --dport 53 -j
> ACCEPT
> /sbin/iptables -A INPUT -p tcp -i eth0 -s 204.42.254.5/32 --dport 53 -j
> ACCEPT

Are you sure that the AXFR queries come only from these addresses ?
Do you mean that you block DNS queries over TCP from anywhere else ? IMO
you should not do that, because there can be DNS queries other than AXFR
that require TCP transport.

> I have looked for error messages written by the master in
> /var/log/syslog. There are't any from bind or named. There is in the
> file etc/bind/named.conf.local the directive:
>
> logging {
> channel my_file {
> file "/var/named/log.msgs" versions 3 size 3m;
> severity info;
> };
> category general { my_file; };
> };
>
> But the file /var/named/log.msgs does not exist so there has been no
> logging there.

IIUC, you have no trace at all. So how do you know if the slaves
actually send AXFR queries to your master ? You should fix that, and
enable logging of all queries. Can you at least capture DNS queries with
a packet sniffer on the master ? I understand that you don't have
access to the slaves logs, but don't you have access to some status on
the account interface ?
From: Artist on
Pascal Hambourg wrote:
> Artist a �crit :
>> Pascal Hambourg wrote:
>>>
>>> Artist a �crit :
>>>> My slave DNS servers are not able to do AXFR transfers from my Bind9
>>>> master.
>>> Can you elaborate (e.g. error messages in logs of both master and slaves) ?
>>
>> I do not have access to the error logs of the slaves. Since I have only
>> one server, and bind9 does not allow both master and slave for the same
>> domain, I am running only the master and not the slaves. The slaves are
>> on free services at ns2.afraid.org and puck.nether.net.
>>
>>>> This is in spite of the slave's IP numbers being listed in the
>>>> master's allow-transfer directive. Should listing in the allow-transfer
>>>> directive be sufficient for the slaves to do AXFR? Or is there something
>>>> else that needs to be done?
>>> I assume the slave zones definitions contain the proper "masters" list.
>>> Does the master allow DNS queries over TCP port 53 (no firewall) ?
>>
>> I had made an effort at making sure the iptables firewall is not
>> blocking by executing these commands:
>> /sbin/iptables -A INPUT -p tcp -i eth0 -s 66.252.5.14/32 --dport 53 -j
>> ACCEPT
>> /sbin/iptables -A INPUT -p tcp -i eth0 -s 204.42.254.5/32 --dport 53 -j
>> ACCEPT
>
> Are you sure that the AXFR queries come only from these addresses ?
> Do you mean that you block DNS queries over TCP from anywhere else ? IMO
> you should not do that, because there can be DNS queries other than AXFR
> that require TCP transport.

I executed these statement to make very sure it wasn't iptables that was
blocking access to the slaves. Actually I am pretty sure that there are
no IP restrictions on access to that port.

>
>> I have looked for error messages written by the master in
>> /var/log/syslog. There are't any from bind or named. There is in the
>> file etc/bind/named.conf.local the directive:
>>
>> logging {
>> channel my_file {
>> file "/var/named/log.msgs" versions 3 size 3m;
>> severity info;
>> };
>> category general { my_file; };
>> };
>>
>> But the file /var/named/log.msgs does not exist so there has been no
>> logging there.
>
> IIUC, you have no trace at all. So how do you know if the slaves
> actually send AXFR queries to your master ? You should fix that, and
> enable logging of all queries. Can you at least capture DNS queries with
> a packet sniffer on the master ? I understand that you don't have
> access to the slaves logs, but don't you have access to some status on
> the account interface ?

I know the queries are being sent because when logged into
ns2.afraid.org the time and date of the last query is displayed. When
logged in to puck.nether.net it does an immediate query upon entry of a
domain and if the query fails the domain is not added to the account.

I have attempted to add more logging to the logging directive. When I
attempt to do so bind9 quits. The logs in syslog show it is because
bind9 does not have the right permissions. But the directory permission
in the logging path given bind9 are the same for all other directories
containing log files in /var and its subdirectories. I have looked into
the possibility it is apparmor. But the bind9 logging directories are in
the apparmor profile file for named.

--
To reply directly remove the sj. from my email address. This is a spam
jammer.
 | 
Pages: 1
Prev: IMAP charset
Next: Livecd Ubuntu