ddns

Check-in [3595e603e0]
Login

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

Overview
Comment:README: fix minor typos
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 3595e603e03822c28c1ba92bbb5dbf5ba04d510d
User & Date: nat 2013-07-20 15:04:00
Context
2013-07-20
15:15
README.md: new prefaced and markdowned read-me for GitHub Leaf check-in: 67459cb834 user: nat tags: trunk
15:04
README: fix minor typos check-in: 3595e603e0 user: nat tags: trunk
2010-01-03
12:52
Client: improved resolution and connection error handling

- new option `resolv-retry` to specify a time (in seconds) before retrying a failed resolution - setting this option to 0 makes resolution and connection errors fatal check-in: 444c684cb0 user: nat tags: 1.0, trunk

Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to README.

1
2
3
4
5
6
7
8
9
10
11
12





Introduction
------------

The basic problem this software intend to solve is the notification of a
DNS server by a client with a dynamic IPv4 address. If I did not have my
own DNS, services from dyndns.org or no-ip.org or stuff like that would be
adapted, but as I run my own DNS I feel it would be lighter, safer, and
<
<
<
<
<












1
2
3
4
5
6
7





Introduction
------------

The basic problem this software intend to solve is the notification of a
DNS server by a client with a dynamic IPv4 address. If I did not have my
own DNS, services from dyndns.org or no-ip.org or stuff like that would be
adapted, but as I run my own DNS I feel it would be lighter, safer, and
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

65
66
67
68
69
70
71
address can be changed at any time depending on the whims of the ISP. This
is a common situation here in France.

The problem is to have a DNS record clientname.mydomain.example on the
server, pointing to the client's current public IP address.

The usual tool for remote DNS updates is nsupdate, however I am not
satisfied with i, mainly because of two issues :

 * the client can change anything in the DNS zone, not only its own record,
 * the client has to somehow find out its own IP address before updating

There used to be a third point in that I do not like pre-shared secrets,
especially in a protocol involving public-key cryptography (both the server
and nsupdate need the private key). I since realized that when the client
is compromised, the attacker can do anything the client could do anyway,
and when the server is compromised, the attacker can already do anything
to the DNS, but they can not do anythuing to the client because it does not
take any action. So using a public-key system would not be an improvement
over a pre-shared secret.

The first issue could be worked around by having the server delegate to
itself a clientname.mydomain.exmaple zone for each client. The client could
still do much more than I like, but at least the rest of mydomain.exmaple
or other client's zones can not be reached. That is still to heavy and not
secure enough for my taste.

The second issue has to be worked around either by reverse-engineering a
part of the NAT routr to extract its public IP address, or by asking some
box on the internet. That seems to be the purpose of
http://checkip.dyndns.org/

So at first I thought about adding a similar page to the web server on my
DNS box. Then I imagined what would be going on : the client asking its
public IP address to the server, and then handing back the address to the
same server for DNS update. That sounds like a waste of resources, why not
simply having the client send a message to the server, and the server using
the remote address embedded in the message to update the DNS record?

That is how this project began : writing a client sending messages once in
a while, and a server listening to this message and updating the records
accordingly, maybe through a nsupdate call. This way there is no need for
the client to find out its public IP, it involves only a single packet per
update, and the client cannot update anything besides its own A record.


That is exactly what this project does, when operating in "unsafe" mode. It
is unsafe because no matter what kind of message you craft, if the client
does not know its public IP address, any attacker can intercept the message
and send it as-is on their behalf, thus injecting their IP into one of my
DNS records. And actually this is exactly what I want to happen, except
with the NAT router instead of an attacker.







|


|

















|




|





|


|
|
>







16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
address can be changed at any time depending on the whims of the ISP. This
is a common situation here in France.

The problem is to have a DNS record clientname.mydomain.example on the
server, pointing to the client's current public IP address.

The usual tool for remote DNS updates is nsupdate, however I am not
satisfied with it, mainly because of two issues:

 * the client can change anything in the DNS zone, not only its own record,
 * the client has to somehow find out its own IP address before updating.

There used to be a third point in that I do not like pre-shared secrets,
especially in a protocol involving public-key cryptography (both the server
and nsupdate need the private key). I since realized that when the client
is compromised, the attacker can do anything the client could do anyway,
and when the server is compromised, the attacker can already do anything
to the DNS, but they can not do anythuing to the client because it does not
take any action. So using a public-key system would not be an improvement
over a pre-shared secret.

The first issue could be worked around by having the server delegate to
itself a clientname.mydomain.exmaple zone for each client. The client could
still do much more than I like, but at least the rest of mydomain.exmaple
or other client's zones can not be reached. That is still to heavy and not
secure enough for my taste.

The second issue has to be worked around either by reverse-engineering a
part of the NAT router to extract its public IP address, or by asking some
box on the internet. That seems to be the purpose of
http://checkip.dyndns.org/

So at first I thought about adding a similar page to the web server on my
DNS box. Then I imagined what would be going on: the client asking its
public IP address to the server, and then handing back the address to the
same server for DNS update. That sounds like a waste of resources, why not
simply having the client send a message to the server, and the server using
the remote address embedded in the message to update the DNS record?

That is how this project began: writing a client sending messages once in
a while, and a server listening to this message and updating the records
accordingly, maybe through a nsupdate call. This way there is no need for
the client to find out its public IP address, it involves only a single
packet per update, and the client cannot update anything besides its own
A record.

That is exactly what this project does, when operating in "unsafe" mode. It
is unsafe because no matter what kind of message you craft, if the client
does not know its public IP address, any attacker can intercept the message
and send it as-is on their behalf, thus injecting their IP into one of my
DNS records. And actually this is exactly what I want to happen, except
with the NAT router instead of an attacker.