sun dhcp+ddns HELP

[Dave Miner]

Giovanni wrote:

> Dave,
>
> I did it but :( dhcpd does not update dns, yet :(
> I am sure dns performs dynamic zone update (checked by nsupdate).
>
> BTW, installing ISC dhcpd server everything works fine: but I still want to
> setup sun's dhcpd.
>
> Any ideas?
>

You can enable debugging output from the DNS update process by setting the
environment variable DHCP_DNS_OUTPUT to "stdout", "stderr", or the name of a
file in the filesystem. The log you posted before indicated it tried to do the
update, but it didn't complete; this additional logging should provide more
detail there.

Dave

[Giovanni]

Dave,

when /usr/lib/inet/in.dhcpd -l -d reports:
3efbf0b7: Datagram received on network device: iprb0
3efbf0b7: Reserved offer: 192.168.10.145
3efbf0b8: Unicasting datagram to 192.168.10.145 address.
3efbf0b8: Adding ARP entry: 192.168.10.145 == 000BCD6263A6
3efbf0b8: Updated offer: 192.168.10.145
3efbf0b8: Datagram received on network device: iprb0
3efbf0b8: name_avail: unqualified name
found CD_DNSDOMAIN and qualified: Maldive.fserver.locale.
3efbf0b8: name_avail(T): gethostbyname_r failed
3efbf0b8: do_nsupdate: unqualified name
found CD_DNSDOMAIN and qualified: Maldive.fserver.locale.
3efbf0bd: Datagram received on network device: iprb0
3efbf0c4: Datagram received on network device: iprb0
3efbf0cc: do_nsupdate: dns_puthostent returned 0
3efbf0cc: Client: 01000BCD6263A6 maps to IP: 192.168.10.145
3efbf0cc: Unicasting datagram to 192.168.10.145 address.
3efbf0cc: Adding ARP entry: 192.168.10.145 == 000BCD6263A6
3efbf0cc: 0004: Refreshed (0x8079880) to (0x807a890)
3efbf0cc: Freeing offer: 192.168.10.145
3efbf0cc: Offer expired for client: 01000BCD6263A6

the DHCP_DNS_OUTPUT log reports:
1: res_ninit() succeeded
4: dns_puthostent(Maldive.fserver.locale., 30)
4: thread 5 created
5: update_thread running
5: getNS("fserver.locale."):
5: qdcount 1
5: ancount 1
5: nscount 0
5: arcount 1
5: type T_NS
5: class C_IN
5: ttl 3600 secs
5: len 8 bytes
5: name frodo.fserver.locale
5: type T_A
5: class C_IN
5: ttl 3600 secs
5: len 4 bytes
5: update for Maldive.fserver.locale. goes to 192.168.10.2
5: delPTR Maldive.fserver.locale.: revname 192.168.10.145.in-addr.ARPA
5: res_nupdate (del PTR) failed - errno 145, h_errno 0
5: send_update failed
5: update for Maldive.fserver.locale. returning 0

So, it seems dns is not able to delete the PTR resource from 192.168.10.0
reverse address mapping zone.

A few ideas:
1) my subnet is a 192.168.10.0/24
2) when I created network by dhcpd config I used:
dhcpconfig -N 192.168.10.0 -m 255.255.255.0 -t 192.168.10.1

Maybe should I use dhcpconfig -N 192.168.10 etc... ??

Giovanni


Nell'articolo <bdadgp$7hj$[email protected]>, Dave Miner ha scritto:

> Giovanni wrote:

>> Dave,
>>
>> I did it but :( dhcpd does not update dns, yet :(
>> I am sure dns performs dynamic zone update (checked by nsupdate).
>>
>> BTW, installing ISC dhcpd server everything works fine: but I still want to
>> setup sun's dhcpd.
>>
>> Any ideas?
>>

>
> You can enable debugging output from the DNS update process by setting the
> environment variable DHCP_DNS_OUTPUT to "stdout", "stderr", or the name of a
> file in the filesystem. The log you posted before indicated it tried to do the
> update, but it didn't complete; this additional logging should provide more
> detail there.
>
> Dave
>

--
Giovanni Casano

[Dave Miner]

Giovanni wrote:
....

>
> So, it seems dns is not able to delete the PTR resource from 192.168.10.0
> reverse address mapping zone.
>

Yes, I agree.

> A few ideas:
> 1) my subnet is a 192.168.10.0/24
> 2) when I created network by dhcpd config I used:
> dhcpconfig -N 192.168.10.0 -m 255.255.255.0 -t 192.168.10.1
>
> Maybe should I use dhcpconfig -N 192.168.10 etc... ??
>

No, you seem to have done everything correctly, we appear to have a bug. This
line from the log:

> 5: delPTR Maldive.fserver.locale.: revname 192.168.10.145.in-addr.ARPA

indicates that we have a byte-ordering problem; the correct reverse name for the
PTR record would be 145.10.168.192.in-addr.ARPA. You're running on x86, and we
apparently forgot a host-to-network byte order conversion along the way; we
never have this problem on SPARC since its native ordering is the same as
network order.

If you need a patch (seems like you'd want one), the procedure would be to file
an escalation through your support account. I have filed the bug, it's 4885027,
which should get things moving along in the process, anyway.
Dave

[Giovanni]

All right Dave.

Thank you for your support... in the meantime I will be back to isc dhcpd :)

Giovanni

Nell'articolo <bdhqn9$oqb$[email protected]>, Dave Miner ha scritto:

> Giovanni wrote:
> ...

>>
>> So, it seems dns is not able to delete the PTR resource from 192.168.10.0
>> reverse address mapping zone.
>>

>
> Yes, I agree.
>

>> A few ideas:
>> 1) my subnet is a 192.168.10.0/24
>> 2) when I created network by dhcpd config I used:
>> dhcpconfig -N 192.168.10.0 -m 255.255.255.0 -t 192.168.10.1
>>
>> Maybe should I use dhcpconfig -N 192.168.10 etc... ??
>>

>
> No, you seem to have done everything correctly, we appear to have a bug. This
> line from the log:
>

>> 5: delPTR Maldive.fserver.locale.: revname 192.168.10.145.in-addr.ARPA

>
> indicates that we have a byte-ordering problem; the correct reverse name for the
> PTR record would be 145.10.168.192.in-addr.ARPA. You're running on x86, and we
> apparently forgot a host-to-network byte order conversion along the way; we
> never have this problem on SPARC since its native ordering is the same as
> network order.
>
> If you need a patch (seems like you'd want one), the procedure would be to file
> an escalation through your support account. I have filed the bug, it's 4885027,
> which should get things moving along in the process, anyway.
> Dave
>

--
Giovanni Casano