dyndns

Check-in [99d81d3502]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:More details in the doc
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | master | trunk
Files: files | file ages | folders
SHA3-256:99d81d3502d3270e74a0002c7c8cb9b7000fa8f7003b119b63d4f8e66c164992
User & Date: ajv-899-334-8894@vsta.org 2017-06-15 04:45:56
Context
2017-06-15
04:46
Some interim work for a Python3 client; micropython on the ESP32 is what I have specifically in mind. check-in: c0cb1c4af6 user: ajv-899-334-8894@vsta.org tags: master, trunk
04:45
More details in the doc check-in: 99d81d3502 user: ajv-899-334-8894@vsta.org tags: master, trunk
2017-05-13
16:51
Can't cache, sigh--there's a per-request ID which changes. We want the client to be a standalone bit of python, so also drop the utils.py factoring. check-in: 68e0d11ff8 user: ajv-899-334-8894@vsta.org tags: master, trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to README.md.

8
9
10
11
12
13
14


15
16
17
18
19
20
21


22
23
24
25
26

27
28
29
30
31
32
33
34
35

The client is also a Python script; it periodically sends a UDP packet
(which is cryptographically signed) to the server.  The server uses the
packet's source as the current IP address, and if it has changed (with
the update from a source which has correctly signed this update), notes
the new IP address.



The other server port is a simple DNS server.  It is intended to be used
as a sub-zone of your main domain, and answers A requests with the
current IP address of any registered host.  In your main zone you want
to define both the serving host (it requires its own IP address; NS
records do not specify a port, alas):

$ORIGIN example.com.


ns3	IN	A	a.b.c.d

and then you need to delegate your dynamic DNS sub-domain:

dyn	IN	NS	ns3.example.com.


Now the host at a.b.c.d receives DNS questions about hosts under
dyn.example.com ("joe.dyn.example.com", "home.dyn.example.com", etc.).

Hosts are managed by a simple file mapping host name to pre-shared key.
Nonces are used, but are not saved on disk; the security here is intended
to be enough to deflect casual vandalism, not to hold off a nation-state.
Similarly, host state is not saved to disk; if the host is not sending an
update, presumably it's offline, so why bother giving its old IP address?







>
>



|
|


>
>
|

<
<
|
>

|







8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


28
29
30
31
32
33
34
35
36
37
38

The client is also a Python script; it periodically sends a UDP packet
(which is cryptographically signed) to the server.  The server uses the
packet's source as the current IP address, and if it has changed (with
the update from a source which has correctly signed this update), notes
the new IP address.

So the server has one port which listens to one or more of these clients.

The other server port is a simple DNS server.  It is intended to be used
as a sub-zone of your main domain, and answers A requests with the
current IP address of any registered host.  In your main zone you want
to define both this server (it requires its own IP address; NS
records do not specify a port, alas) and its domain.

$ORIGIN example.com.
(...)
dyn	IN	NS	ns1.dyn.example.com.
ns1.dyn	IN	A	a.b.c.d



(By convention, our dynamic DNS server is "ns1" under its own
dynamic part of the domain.)

Now this server at a.b.c.d receives DNS questions about hosts under
dyn.example.com ("joe.dyn.example.com", "home.dyn.example.com", etc.).

Hosts are managed by a simple file mapping host name to pre-shared key.
Nonces are used, but are not saved on disk; the security here is intended
to be enough to deflect casual vandalism, not to hold off a nation-state.
Similarly, host state is not saved to disk; if the host is not sending an
update, presumably it's offline, so why bother giving its old IP address?