Create an orphaned record, & use it for bogus accounts.

[skx]

We're moving to a situation where several users are going to need to be updated because their details are wrong, and we can't contact them.

Suggest we create:

• http://orphaned.dhcp.io/

All the records owned by bogus users will be remapped into CNAME records pointing to that, unless/until they update themselves. If they never update themselves we can delete the accounts after a month or two.

[skx]

Created an invalid.dhcp.io name, which only allows connections on :80.

I will change the code such that if a user submits an update, with no email address registered, their update will be denied with an error.

As a second step all records owned by users with no email address will be updated to become CNAME records for invalid.dhcp.io.

The end result will be:

• All users with no email will be pointed to the information page.
• All updates will fail until their email is updated, so this info-page remain.
• Once users mail me I can fix them up.

[skx]

This is embarrassing!

When the project was created we had one table of records, such that if you had the login foo you controlled the record foo.dhcp.io. You could not add any extra records at all.

Almost immediately users asked for more. So I split things up, and created the records table. This allowed a relationship to be defined such that a user would have an ID, and they could insert records.

To find records for a user:

   SELECT * FROM records WHERE owner=?

So why is this embarrassing? It turns out I didn't ever delete the records that matched the login name. When I added the records table I updated all users. So if in the past there was:

user: foo  id:1234

I inserted a record to cope with the change:

 insert into records:
     name:foo, owner:1234, token:blah-blah-blah

The only users in the database with missing emails were those who managed zero records. i.e.. There was no entry in records for the user, but there was a foo.dhcp.name for them. This had been orphaned in the dim and distant past. Deleting all of those users is 100% harmless, because they can't ever have been updated. (Because at the migration time the tokens were moved to the records table, rather than in the user table where they existed.)

This means there are no orphans to update - in the sense that this bug was original required to handle - only migration-orphans.

TODO:

• Delete the DNS records that match logins, for which there is no record-entry defined.
• Delete the user too.

[skx]

This is now complete; I've written a dumping utility to find all records not updated in 30 days, and set their values to be CNAME invalid.dhcp.io.

If the users restore their usage in the next month they can remain, if not I'll purge them at that time.

[mpol]

Hello and thank you for dhcp.io.

I guess this is the change that removed my bifrost.dhcp.io record over the weekend?
I get a theoretically changing IP from my provider via DHCP but it changes extremely rarely in practice. I can believe that it did not change since tokens disappeared from the users table, but I had seen it change before, that's why I started to use dhcp.io.

Unfortunately it seems that I cannot just reregister as no new users are allowed.

[skx]

I'm sorry for the removal, yes this issue and a couple of other changes were most likely to blame.

Drop me a mail, and I'll reinstate your account and your records this evening when I get home.

[mpol]

Thanks, I'll try. Although unfortunately you have .pl blacklisted.

[skx]

Tracked here now - will sort out this evening.

[skx]

(resolved)