Real DDNS, Apple Airports, and Tunnels

[daedelus]

    I could really use a hand in trying to figure out the best way to approach this problem. Here are my initial conditions:

- My home network connects to the outside world via Bright House, so no native IPv6
- Bright House provides a dynamic IPv4 address
- My external router is an Apple Time Capsule, which supports RFC2136/RFC2845 "Real" TSIG based DDNS
- When I'm traveling I don't have a general purpose "home server" to run scripts/apps on inside the home net

   I've setup a HE Tunnel to the Time Capsule, and it works great. However, should I get readdressed while I'm traveling, the tunnel goes down and things are bad for the people at home.

   So, I've been looking at various options. It looks like I could easily setup a dynamic zone on my bind installation and have gw.home.example.com always resolve to the right address. Unfortunately, it doesn't look like the tunnel broker side will let me use a fqdn to define the v4 endpoint. (and then there's the whole issue of how often do you refresh it?)

  The next option would be to use the dns.he.net offering, which is quite nice, and it looks like you can have your tunnel endpoint swing with the Dyn-style HTTP update. Unfortunately, as far as I can tell dns.he.net doesn't do RFC2136/RFC2845 TSIG based DDNS, and I /FINALLY/ got rid of general computing equipment (infrastructure style) at home. I'd hate to spin up a new machine just to do Dyn-style HTTP updates.

   So, is there some option I'm missing?  Any suggestions would be greatly appreciated!

   - Jim

[kcochran]

   So, I've been looking at various options. It looks like I could easily setup a dynamic zone on my bind installation and have gw.home.example.com always resolve to the right address. Unfortunately, it doesn't look like the tunnel broker side will let me use a fqdn to define the v4 endpoint. (and then there's the whole issue of how often do you refresh it?)

The last bit is exactly why we don't do FQDNs for tunnel endpoints.

  The next option would be to use the dns.he.net offering, which is quite nice, and it looks like you can have your tunnel endpoint swing with the Dyn-style HTTP update. Unfortunately, as far as I can tell dns.he.net doesn't do RFC2136/RFC2845 TSIG based DDNS, and I /FINALLY/ got rid of general computing equipment (infrastructure style) at home. I'd hate to spin up a new machine just to do Dyn-style HTTP updates.

The sequence is actually the other way 'round.  You can do a tunnel endpoint update that pushes the update over to dns.he.net as well.  Alas, it's the Dyn-style updates or the older URL request endpoint updates for the moment.  Either mechanism at least doesn't require much of a system, so a Pi or simple plug-like systems would do the trick.

[daedelus]

  The next option would be to use the dns.he.net offering, which is quite nice, and it looks like you can have your tunnel endpoint swing with the Dyn-style HTTP update. Unfortunately, as far as I can tell dns.he.net doesn't do RFC2136/RFC2845 TSIG based DDNS, and I /FINALLY/ got rid of general computing equipment (infrastructure style) at home. I'd hate to spin up a new machine just to do Dyn-style HTTP updates.

The sequence is actually the other way 'round.  You can do a tunnel endpoint update that pushes the update over to dns.he.net as well.  Alas, it's the Dyn-style updates or the older URL request endpoint updates for the moment.  Either mechanism at least doesn't require much of a system, so a Pi or simple plug-like systems would do the trick.

Oh, ok ... I was confused then. So to make this work, I use https://ipv4.tunnelbroker.net/nic/update?username=<USERNAME>&password=<PASSWORD>&hostname=<TUNNEL_ID> to update the tunnel broker, and then IT pushes the new address over to dns.he.net, correct? I prototyped something this afternoon that updates dyn.dns.he.net and was expecting that to push over to the tunnel side, but if I'm understanding you that won't work, correct?

[kcochran]

Right.  The tunnelbroker update can be set to push the update to dns.he.net as well, all you need to do is add the appropriate items under the "Advanced" tab on the tunnel information page.  You can also trigger and check status on updates in the same place.

[kcochran]

I looked into this some more, and while the Airport sends some dynamic update information, it's mainly for itself.  It'll register a SRV record for itself, and then updated other associated DNS-SD records.  I didn't see a single A or AAAA sent upstream when I was testing.

[guylhem]

kcochran, if you do not see the A and AAAA you may have forgotten to create the SRV and the r PTR record, as explained on http://www.panix.com/~awhitema/2009/10/more-stupid-support-tricks/ OSX doesn't know where to send the updates unless you have some specific DNS records - so it doesn't send them at all.

I am trying to do the very same thing using dns.he.net and I *do* see packets with the correct information inside - my only problem is that the A and AAAA don't seem to be updated (a big problem indeed!)

If you are using for example mydomain.com, and your dynamic hostname is something_dyn_enabled.mydomain.com, you want to create in your zone:

_dns-update._udp IN SRV 0 0 53 dyn.dns.he.net.
b._dns-sd._udp IN PTR mydomain.com.
db._dns-sd._udp IN PTR mydomain.com.
dr._dns-sd._udp IN PTR mydomain.com.
lb._dns-sd._udp IN PTR mydomain.com.
r._dns-sd._udp IN PTR mydomain.com.

The first line with tell OSX where to send the DDNS updates to dyn.dns.he.net (the d db dr lb may be useless, I just added them for later use with bonjour advertising of the services), and the last line that updating A and AAAA records is indeed possible.

I suppose you have a DDNS enabled (tick the box!) A and AAAA record for something_dyn_enabled.mydomain.com on dns.he.net.

On OSX, in the global dynamic hostname, use :
hostname : something_dyn_enabled.mydomain.com
user: something_dyn_enabled.mydomain.com
password : whatever-I-set-with-the-2-arrows-on-dns-he-net

(If for the hostname you use only mydomain.com, then it won't do TSIG for whatever reason)

Finally, turn on and off the network interface (easy to do with wifi in the menu) and with tcpdump -Aevvv you will then see the packet sent to dyn.dns.he.net, containing the correct A and AAAA records and a TSIG field.

However, nothing happens - the records are not updated. If you want, we can try to debug that together? I'd love to see what the packets received by dyn.dns.he.net look like. My best bet at the moment is that the TSIG is incorrect.

Feel free to contact me by email if you want the full tcpdump records

[leevro]

    I could really use a hand in trying to figure out the best way to approach this problem. Here are my initial conditions:

- My home network connects to the outside world via Bright House, so no native IPv6
- Bright House provides a dynamic IPv4 address
- My external router is an Apple Time Capsule, which supports RFC2136/RFC2845 "Real" TSIG based DDNS
- When I'm traveling I don't have a general purpose "home server" to run scripts/apps on inside the home net

   I've setup a HE Tunnel to the Time Capsule, and it works great. However, should I get readdressed while I'm traveling, the tunnel goes down and things are bad for the people at home.

   So, I've been looking at various options. It looks like I could easily setup a dynamic zone on my bind installation and have gw.home.example.com always resolve to the right address. Unfortunately, it doesn't look like the tunnel broker side will let me use a fqdn to define the v4 endpoint. (and then there's the whole issue of how often do you refresh it?)

  The next option would be to use the dns.he.net offering, which is quite nice, and it looks like you can have your tunnel endpoint swing with the Dyn-style HTTP update. Unfortunately, as far as I can tell dns.he.net doesn't do RFC2136/RFC2845 TSIG based DDNS, and I /FINALLY/ got rid of general computing equipment (infrastructure style) at home. I'd hate to spin up a new machine just to do Dyn-style HTTP updates.

   So, is there some option I'm missing?  Any suggestions would be greatly appreciated!

   - Jim

You can use https://www.duiadns.net with your apple airport router for free, if you create an account before 01.01.2016. They also support newer firmware versions then 7.6.1. For accounts created after 01.01.2016 this feature will cost 3 EUR/year. More info here: https://www.duiadns.net/running-duiadns-on-apple-router