DDDNS - Delegated Dynamic DNS - ensures that if your dynamic DNS
name resolves, then it is because your server is present (i.e.
dialled out or connected). Your DNS name is delegated to your own name server
at your current IP address. If your server is not present, or if another
server has taken your former IP address, then the lookup fails, and the name
does not resolve. This is not a problem, because it indicates (correctly) that
you are not there.
Dynamic DNS (DDNS) is a well-worn technique for associating a
DNS name with a dynamic IP address, usually ADSL, but occasionally
dial-up as well. With DDNS, what happens if your machine is not
connected for some time? A person visiting your web site may see
another site. Mail to your domain may be rejected with a rude
message ("relay access denied") (or, even worse, it may be accepted).
DDDNS allows you to run a web site and mail server on a dynamic address
with the assurance that if your link is down your name will also be down.
Having a reliable DNS name means that you can do all the things
you should require a static IP address for:
- Reliably deliver mail directly to your dynamic internet link.
You can run your own mail server, and not pay per account or
per-MB of storage.
- Run a web server on your cheap and fast ADSL link, avoiding
expensive hosting charges.
- Run other services, e.g. intranet, VPNs, other remote control
How is a DNS lookup failure handled? Well, DNS servers (according to the RFC)
cache that a particular IP address is not a valid DNS server for a domain for
10 minutes. When you NS records time out, your new address is used
immediately, provided you have a new dynamic address.
To configure an ETRN mail spool, the dsmtp mailer for sendmail works
quite nicely. Configuration of exim, postfix, qmail and MSEXCH for spooling
mail to dddns is left as an
exercise to the reader.
Our technique is quite similar to the approach of registering
your domain using a dynamic DNS provider to point to you as the
DNS server. This is described by the GnuDIP
project. In that approach, you also run a DNS server at your dynamic address.
It is a fail-safe arrangement, but mail to you may bounce immediately if your
line is down (I think), since your MX records do not even exist if your system
is not connected. (This can spoil your day.)
Just in case you wanted to know, the biggest reason we switched to DDDNS is
that we had endless hassles with POP3. One of the big reasons to use DDDNS is
that POP3 has a fundamental problem. What do you do with a mail in your
mailbox that cannot be delivered -- 450 Temporary Failure? You try again, but
often enough, that temporary failure is permanent. So you retry. How many
times? Well, in most cases, you will probably retry that mail indefinitely.
Since fetchmail does not have a local queueing mechanism, this means repeatedly
downloading the mail, and attempting to deliver it repeatedly. It is really
easy to kill your stable fetchmail implementation this way. Even worse is if
you run postfix configured with unknown_local_recipient_reject_code =
450. In this case, fetchmail appears to work initially, but begins to
loop as soon as someone drops mail for a user that doesn't exist. (Very sad,
and sometimes very expensive.)
Audience: Wireless and ADSL users. Dial-up users may be
System requirements: bind 9, nsupdate and `host'. netdate
is recommended if you are not keeping your clock in sync with ntpd
Source license: GPL
If you are interested in this software, you may like to send us a large
payment, or make use our related services:
DNS hosting for dyn.ledge.co.za subdomain: Free for South African users*
1 year DNS hosting with DDDNS update: Our DNS servers host your domain
(e.g. wallpaperremovals.co.za) and accept updates from you. R128.00 (excl.
Backup MX server accepting ETRN: R110.00 (excl. VAT) per month for
dial-up, R100.00 (excl. VAT) per month for ADSL. This applies per domain.
Client installation fee R972.00 (excl. VAT) (installation of
DDDNS software on existing Linux gateway machine).
Free? Yes, free, as in beer. We know that a good
proportion of people will (a) buy the backup mail spooling offer and (b) pay us
to set it up and (c) DNS is not really bandwidth intensive.
Download and documentation
Automatic account failover
We have included our failover scripts to handle multiple simultaneous pppoe
connections. This is to overcome the 3GB traffic quota offered in South
- Initially you use a single account for internet
- When the first account is bandlimited, you bring up an additional
- You continue to use the limited account for South African
traffic, and use the additional account for all other
- If / when you exceed the traffic limit on your second
account, then the system will keep switching accounts until it
finds an unlimited one. (If someone can add logic to detect that
all accounts are bandlimited, please do so).
There are a number of complications that the scripts take care of -
- Handling inbound connections to two different addresses
without having asymmetric routing (Linux advanced routing rules)
- Keeping dddns up to date for multiple interfaces, and also
handling the case of two names referring to one interface -- well, it used to,
but that's now integrated into the standard dddns.