[Dibbler] Problems with the FQDN-Snapshot

[Tomasz Mrugalski]

On Thu, 31 Aug 2006 somebody known as ml2h2 at web.de wrote:

> I changed the file and now I see that dibbler wants to make a zone 
>transfer. Why? Per default it is disabeled in our network because of 
>security reasons.
I'm not sure if I understand then nature of this problem. I'm no expert 
in the DNS Update protocol, so I might got something wrong. I'm using 
poslib library. Since I'm not its author, I don't know every detail of its 
functionality.

If dibbler indeed attempts to make zone transfer, I'll try to find out 
more about this.

For now, the easiest solution is to allow DNS server to perform updates 
(and possibly zone transfer). If dns server is BIND, make sure you have 
the following entries in your /etc/bind/named.conf.

     allow-update    { any; };
     allow-transfer  { any; };
     allow-query     { any; };

This is easy to set, but obviously it is insecure. So instead of any, you 
might want to specify your dhcpv6 server and allow updates only from that 
particular address.

Are you sure

>
> Here are the last output lines (server):
That is more descriptive. I have left only important lines (update for 
deleting entries fails in the same way):

> 0733s,849819us  Server Debug     FQDN: Performing DNS Update: Only PTR record.
> 0733s,850638us  Server Debug     FQDN: PTR record created: 9.f.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.1.c.d.c.8.3.c.1.4.b.d.f.ip6.arpa -> ipv6nr02.ip6.lab
> 0733s,927495us  Server Error     FQDN: Nameserver is not authoritative for this zone (NOTAUTH)
First update: add PTR record. Are you sure that you have your dns server 
configured to support 0.0.0.3.1.c.d.c.8.3.c.1.4.b.d.f.ip6.arpa zone?
(full address truncated to first 64 bits).

This might be possible bug in the Dibbler. I'm not sure if this is 
importabt, bu the name should end with ip6.arpa. not ip6.arpa (missing 
dot). If you want to test fix for this, edit Misc/addrpack.c file and 
modify function doRevDnsAddress(), line 225:
THERE IS:  sprintf(dst + strlen(dst), "ip6.arpa");
SHOULD BE: sprintf(dst + strlen(dst), "ip6.arpa.");

> 0733s,928084us  Server Debug     FQDN: Performing DNS Update: Only AAAA record.
> 0733s,928586us  Server Debug     FQDN: AAAA record created:ipv6nr02.ip6.lab. -> fdb4:1c38:cdc1:3000::42f9
> 0733s,931779us  Server Error     FQDN: Error not specified (SRVFAIL)
Second update: add AAAA record. There are few things, which might go 
wrong. Does your dns server support ipv6.lab. zone? Does it allow updates? 
For some reason, your dns server returned status SRVFAIL. As I said, I 
have limited experience with the dns update protocol, but maybe I will be 
able to find out what went wrong if you could send me captured packets 
(using ethereal or wireshark)?

Another tip: I had the same problem. When first update is performed for a 
zone, BIND server creates new file with extention .jnl. Note that it by 
default creates it in the same directory where zone files are created 
(usually somewhere in /etc/). In my system (Debian) bind process is run as 
bind user, which has no write rights for that directory. So BIND was 
unable to create journal file, so it refused to make update and returned 
SRVFAIL status.

Let me know if this helps.

-- 
Tomasz Mrugalski,              | "I think there is a world market for     |
thomson(at)klub(dot)com(dot)pl |  about five computers."                  |
                                |     Thomas J. Watson (Chairman, IBM) 1943|