[GH-ISSUE #146] invalid initial IPv4 address, won't go away #136

New issue

Open

opened 2026-02-26 09:36:00 +03:00 by kerem · 3 comments

kerem commented

2026-02-26 09:36:00 +03:00

Owner

Originally created by @barak on GitHub (May 22, 2014).
Original GitHub issue: https://github.com/nsupdate-info/nsupdate.info/issues/146

I registered a machine which has a proper (albeit dynamic) IPv6 address, but accesses IPv4 via NAT. I registered the host's IPv6 address via

wget -6 .../ipv6.nsupdate.info/...

and the AAAA record shows up correctly.
But there is an A record with the v4 address of the NAT of the host where the browser that was used to create the host entry was running.

The list of registered hosts, https://nsupdate.info/overview/, shows this:

samboy.nsupdate.info    yes 0/0 87.198.59.173 (unknown) 2001:0:53aa:64c:1c4e:36cd:a839:c452 (24 minutes, SSL)

Note the "unknown" as the source for the IPv4 address.

This suggests two issues.

There should be some way to remove an incorrect or obsolete A (or AAAA) entry, aside from the web interface DELETE button.
That IPv4 address shouldn't have been slammed in there in the first place.

Originally created by @barak on GitHub (May 22, 2014). Original GitHub issue: https://github.com/nsupdate-info/nsupdate.info/issues/146 I registered a machine which has a proper (albeit dynamic) IPv6 address, but accesses IPv4 via NAT. I registered the host's IPv6 address via ``` wget -6 .../ipv6.nsupdate.info/... ``` and the AAAA record shows up correctly. But there is an A record with the v4 address of the NAT of the host where the browser that was used to create the host entry was running. The list of registered hosts, https://nsupdate.info/overview/, shows this: ``` samboy.nsupdate.info yes 0/0 87.198.59.173 (unknown) 2001:0:53aa:64c:1c4e:36cd:a839:c452 (24 minutes, SSL) ``` Note the "unknown" as the source for the IPv4 address. This suggests two issues. - There should be some way to remove an incorrect or obsolete A (or AAAA) entry, aside from the web interface DELETE button. - That IPv4 address shouldn't have been slammed in there in the first place.

kerem added the

needs help

task

labels

2026-02-26 09:36:00 +03:00

kerem commented

2026-02-26 09:36:01 +03:00

Author

Owner

@ThomasWaldmann commented on GitHub (May 22, 2014):

Thanks for the feedback! Some comments:

Please avoid updating the ip address if it did not change. wget might not be the right tool for that, except if you are making sure by additional means (e.g. clients running wget in a cron job will be denied). There seems to be a patched ddclient for v6 and python-dyndnsc also can do v6.

First issue:

IIRC, the dyndns2 protocol specs do not specificy a means to delete a record.

Because of that, the current code has an additional /nic/delete URL (which is not really documented yet in the user docs, just in the code), see there:

https://github.com/nsupdate-info/nsupdate.info/blob/master/nsupdate/api/views.py#L232

Second issue:

Yes, we immediately put a host record if you register a host via the web interface. I agree with you that this should not be, but IIRC we did not do that at the beginning and then ran into problems because some update clients want to query before they send an update and somehow malfunctioned if there was no reponse at all.

@ThomasWaldmann commented on GitHub (May 22, 2014): Thanks for the feedback! Some comments: Please avoid updating the ip address if it did not change. wget might not be the right tool for that, except if you are making sure by additional means (e.g. clients running wget in a cron job will be denied). There seems to be a patched ddclient for v6 and python-dyndnsc also can do v6. First issue: IIRC, the dyndns2 protocol specs do not specificy a means to delete a record. Because of that, the current code has an additional /nic/delete URL (which is not really documented yet in the user docs, just in the code), see there: https://github.com/nsupdate-info/nsupdate.info/blob/master/nsupdate/api/views.py#L232 Second issue: Yes, we immediately put a host record if you register a host via the web interface. I agree with you that this should not be, but IIRC we did not do that at the beginning and then ran into problems because some update clients want to query before they send an update and somehow malfunctioned if there was no reponse at all.

kerem commented

2026-02-26 09:36:01 +03:00

Author

Owner

@ThomasWaldmann commented on GitHub (Aug 27, 2014):

delete api extension documented now, see a89d6353a8

@ThomasWaldmann commented on GitHub (Aug 27, 2014): delete api extension documented now, see a89d6353a8af1c08e427a992dec900d51145de71

kerem commented

2026-02-26 09:36:01 +03:00

Author

Owner

@ThomasWaldmann commented on GitHub (Aug 27, 2014):

about your primary issue: sadly, I do not exactly remember which update client it was that ran into troubles. As a workaround I suggest to manually deleted unwanted records either on the web UI or using the /nic/delete api - one only needs to do that once.

To remove the code that initially puts in these records, I guess we would need quite some testing against misc. update clients and document any issues we run into - but I guess unless we find some people volunteering to do that, I can't do that on my own.

Volunteers please speak up and state which update you offer to test against modified code.

@ThomasWaldmann commented on GitHub (Aug 27, 2014): about your primary issue: sadly, I do not exactly remember which update client it was that ran into troubles. As a workaround I suggest to manually deleted unwanted records either on the web UI or using the /nic/delete api - one only needs to do that once. To remove the code that initially puts in these records, I guess we would need quite some testing against misc. update clients and document any issues we run into - but I guess unless we find some people volunteering to do that, I can't do that on my own. Volunteers please speak up and state which update you offer to test against modified code.