Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
skx opened this issue May 30, 2016 · 1 comment
Closed

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

skx opened this issue May 30, 2016 · 1 comment

Comments

@skx
Copy link
Owner

skx commented May 30, 2016

sigh
@skx skx mentioned this issue May 30, 2016
Closed
@skx
Copy link
Owner Author

skx commented Jun 2, 2016 •
edited

With the newer interface we can change the way we work significantly:

  • We send a command that says "set foo.dhcp.io to IP 1.2.3.4".

We explicitly don't need to download all the existing/current values. (The current behaviour is: Download all the DNS names & values. If they differ delete the old record by name. Then add the new record. If they're the same do nothing.)

The /home page currently lists all known-names for a user, along with the current DNS values. There are two ways to go:

  • Query from Amazon.
  • Query via DNS lookups.

Assuming a user has one name they will have at most two DNS lookups (A + AAAA). Assuming they have the maximum number of names, 5, there are potentially 10 values to lookup.

For the single-case it is clearly a net-win to perform two DNS lookups rather than fetching 1000+ entries from the zone, via the Amazon API. For the case where somebody has five names? The case become less clear.

Although caching will happen with the Amazon API lookup that will need to be flushed every time any user makes a change. Which means in practice the cache is good for 1-3 minutes at the most. Running a DNS lookup will also involve caching, subject to the TTL, on the local node.

Conclusion:

  • It is definitely preferable to use the newer API to update records.
  • For fetching records it is probably simpler to perform DNS lookups.

skx added a commit that referenced this issue Jun 3, 2016
@skx
Simplified DNS lookup, by avoiding the Amazon API.
c900412 
This commit updates #14, by changing the way we lookup the
current value(s) of the given names.  Rather than fetching
the live data from the Amazon API we lookup via DNS.

If a user is registered and has `foo.dhcp.io` we do a
lookup of the name `foo.dhcp.io`, and rely on the caching
present in the local resolver.

This is more efficient than fetching the contents of the complete
`dhcp.io` zone, then parsing each record to see if it matches
`foo`.

TODO:

* Update the API we bundle, such that we can use `upsert`.

Upsert allows us to send a message which says:

* Set foo.dhcp.io (A) -> 1.2.3.4

Rather than having to :

* Download the zone.
* Find the current value.
    * Delete the value, explicitly.
    * Add the value with the new IP.

The whole thing we're trying to avoid is having to download
the zone, because internally the Amazon API allows you to only
do that in stages:

* Download the first 50 records.
   * Download the next 50 records.
   * Download the next 50 records.
   * Are we done?  If not download the next records.
   * etc.
skx added a commit that referenced this issue Jun 3, 2016
@skx
Updated the Amazon API.
c64c27d 
This updates #14.
@skx skx closed this as completed in 3644364 Jun 3, 2016
skx added a commit that referenced this issue Jun 3, 2016
@skx
Removed debugging code.
b3e9305 
Updates #14.
@skx skx mentioned this issue Jun 4, 2016
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@skx