skx/dhcp.io

Dynamic DNS - Via Redis, Perl, and Amazon Route53.

dhcp.io's Issues

Log updates ..

Allow updates to be logged.

As per feedback from joet3ch

Not possible to delete hostnames

Once you've claimed a sub-domain you cannot release it, or delete it.

You can delete the existing IP which is associated with the name, if any, though.

Update links to my homepage

Homepage links to steve.org.uk. I'm now using steve/kemp.fi since I live in Finland.

Be more explicit about the state of the project.

At the moment:

• Updates are capped a little.
  • Partly because of the overhead.
  • Partly because we're using the old API and all changes are heavyweight.
  • When we use the new API #14 we can just use UPSERT.
• Account registration(s) are closed.
  • Though I've given a few people new accounts on a one-off-basis.
• We have too many orphans.
  • Need to write a tool to identify accounts that haven't changed IP in months.
  • Consider marking such accounts as read-only unless/until they are changed.
• We don't have a good way of contacting users, because emails are option.
  • Disable all acounts without emails? Until they complain? Horrid, but workable ..

We should overhaul the user-interface.

At the moment the site looks pretty dated, and terrible.

Move over to a similar layout to that used in the commercial site - i.e. Use bootstrap and hope for the best.

UI: Password reset

The password-reset process is ugly and can be improved via more bootstrap.

Edit via web-page

Currently there are two ways to change the value of a record:

• For the admin, via bin/set-name.
• For a user, via curl.

It might be nice to add an Edit Record page. I've added a stub link in the live version - repository is out of date - but it is a NOP.

Password reset failure

Seems the docker-container doesn't have sendmail installed/configured.

We should cache the zone lookups.

Currently we pull the complete zone out, to get the most current records, for the /edit/ operation.

By contrast at /home/ we just use Net::DNS. At the time I considered this too expensive to lookup constantly, but Net::DNS isn't responsive enough.

Suggestion:

• Drop the use of Net::DNS.
• Update DHCP::Records to cache, in Redis, the return value of getRecords - with TTL of 60 seconds.

Invalidate on hits to /edit/ + /set obviously. (Or wait for cache to expire via TTL, if the cache-time is the same as the zone..?)

Not possible to delete accounts.

There is no ability to delete a user-account from the web-interface.

The site-admin can use bin/delete-user --username=foo to delete a user, and their associated records, manually though.

We need to update the code for the newer Amazon module.

sigh

Set both IPv4 and IPv6 at once.

It would be nice to be able to set IPv4 and IPv6 addresses for a record in one call.

This cannot be done unless both are specified though, because if no address is specified then the source is used - clearly a request may arrive at the dhcp.io host on either IPv4 or IPv6 but not both a once.

If we restrict ourselves to the case where both addresses are specified then it becomes a simple enough job. Something like :

  curl http://dhcp.io/set/$token/$ipv4/$ipv6

Or via the post:

 curl -X POST -data 'token=xx&ip4=1.2.3.4&ipv6=fe80::1'

The only thing to note is that we need to handle the case where the endpoint might receive only one argument, ip, as is currently the case. That means to set both they must be named appropriately (i.e. ipv4 + ipv6.)

Shouldn't be a big change, but no rush ..

UI: Profile-Change

The profile page shows the following fields which are directly editable:

• Login-name.
• Email-address.
• Password.

Rather than allowing these to be edited in-place we should make the profile page just show the details, and add two new routes for making changes:

• Change password
  • This must have confirmation.
• Change email.
  • This must have confirmation, and validity-checking done. (i.e. mx-record, or similar).

The specific problem we're trying to solve is twofold:

• Make the UI look better.
• Ensure we don't allow bogus updates - i.e. typos to be persisted - by forcing confirmation.

MX records?

This might involve a world of pain - but should we allow users to set an MX record too?

Again this is easy for a free v.s. paid discussion. Free users can have an A/AAAA record, but you must pay for MX.

Since we're not really going down that path ..

You cannot edit the value of a record which is empty.

This is regression, but if there is no value set for a given name you cannot edit it.

e.g. Create a new record foo.dhcp.io and it will be empty. After you run a curl command to set (any) value you can then edit it. But until then it is impossible.

Reinstate bifrost.dhcp.io

As per the comments on #17

Password reset.

The deployed code uses hashed passwords - this repository is a little out of date.

If a user forgets their password and has a registered email address we should allow a reset operation.

If the user has no registered email address they are out of luck. Or must mail me.

Sub-records should be supported.

A common request is the support for sub-records.

For example rather than restricting names to things such as skx.dhcp.io, me.dhcp.io users would like the ability to have names of the form:

• gateway.office.dhcp.io.
• printer.office.dhcp.io.

I won't add this support, and explicitly do not support sub-records.

Pull requests implementing this will be accepted providing the behaviour can be disabled via the configuration file lib/DHCP/Config.pm[.example].

(This issue just created for reference.)

Logging is broken. (Shows wrong hostname).

Assume you have the user-account "skx", which has the following records:

• deagol
• smeagol
• shelob

(Manually) edit the records for shelob, and it is logged deagol. Suspect this is an artefact of earlier releases where a single account was available - which in this case would be skx.

Redis: We don't use you as much.

As a result of #14 we no longer fetch the current value(s) of the complete hosted zone from Amazon.

Because we don't fetch the complete zone we no longer cache it in memory.

This means we can drop some of the redis-usage, as it is orphaned.

NOTE: We still use redis, we just use it for rate-limiting/throttling, and for storing transient password-reset tokens, etc. So while we can remove it in some places it does continue to be necessary (and awesome)!

IPv6 AAAA record missing.

That makes it hard, but not impossible, to set an IPv6 address to a specific value.

It can be done with curl, but it's only documented via the source-code.

(The record was dropped, but I didn't appreciate that would cause breakage. Dropped because the docker setup wasn't working with IPv6 at the time I handled the migration and I forgot to track it as a TODO)

Logs not updating sometimes/always?

A twitter user reports that logs aren't showing updates some/all of the time.

Secondly they say that they "can't connect". There are no details on that, so I assume that means the dynamic hostname they've set isn't reachable - that would be outside the scope of this issue and code.

Multiple names?

It might be the case that we want to allow users to have more than one name.

If so that requires a redesign of the home-page - perhaps a dropdown that will change the text in the home panel.

Alternatively we could use a tab-interface running across the top, with one tab for each name.

Implementation of either would be simple. I just need to decide whether it should be supported or not.

Were this commercial it would be easy to say "One domain for free, if you want more pay". Though I guess the obvious concern would be people registering N-accounts..

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

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.

Migrate to bcrypt passwords.

We don't expect a compromise, but using something better is absolutely 100% essential.

• Create a new passwords table, keyed on user_id.
• Update the login-code to query against the new table.
  • If there is no match use the old login code.
  • If the login succeeds create a bcrypt entry.

This will buy us per-user salting, and if we ever are compromised that'll reduce the risk of exposure.

UI: Login form

The login form is ugly and can be improved.