[Idea] DNS-based service to determine public IPs

dynDNS at dedyn.io
1

Currently deSEC offers the HTTP-based service https://checkip.dedyn.io/, https://checkipv4.dedyn.io/ and https://checkipv6.dedyn.io/ to determine your current public IPs.

However they are most likely rather expensive on the server side if they are implemented using the same Python backend as the rest of the web services. (I could not find their implementation on GitHub though, so this is just an assumption. If this is not an issue then please ignore this post.)

Also in a typical scenario this service would need to be called much more often than the IP Update API. So if it does cause significant server load, finding ways to reduce this would have a significant effect.

I have seen that several large (US) companies seem to offer DNS-based services that do the same thing:

  • Google

    • $ dig @ns1.google.com. -4 +short o-o.myaddr.l.google.com. txt|cut -f2 -d'"'
    • $ dig @ns1.google.com. -6 +short o-o.myaddr.l.google.com. txt|cut -f2 -d'"'

  • Cloudflare

    • $ dig @one.one.one.one. -4 +short whoami.cloudflare. ch txt|cut -f2 -d'"'
    • $ dig @one.one.one.one. -6 +short whoami.cloudflare. ch txt|cut -f2 -d'"'

  • OpenDNS (Cisco)

    • $ dig @dns.opendns.com. -4 +short myip.opendns.com. a
    • $ dig @dns.opendns.com. -6 +short myip.opendns.com. aaaa

These services all return DNS records that contain the (public) IP of the caller, either as a TXT record or as A/AAAA records. They use short TTLs (0 or 60 in the case of Google).

Would something like this be feasible using the deSEC infrastructure (PowerDNS and anycast)?

If so could this help to reduce the load on the web servers?

fiwswe

[Update] One issue might be the DNSSEC signatures of the returned DNS records? They would probably force the requests to go to the master server that does the signing, negating the advantages of using the anycast frontend DNS servers.

1 Like
2

Thank you for this great suggestion!

They are not, but are answered directly by nginx: desec-stack/www/conf/sites-available/10-dedyn-checkip.conf.var at main · desec-io/desec-stack · GitHub (look for return)

This is about as cheap as sending a “429 Too Many Requests” response :wink:

Those are unprotected responses, so a capable attacker could spoof the response, and then cause your update client to make a request to place a malicious record in your domain’s DNS.

It would not be a big issue to make an exception for that specific query name to be signed on the secondaries.

We already do that for RFC 9615 bootstrapping records, those are signed on the fly on the secondary:

$ dig +short _dsboot.dedyn.io._signal.ns1.desec.io CDS +dnssec
35233 13 4 CE807E76229D64AAE886B2732355BDD68E2C9D1039609085DFE15933 FE031C71981A7FA77F45B22192F76724A9B29FB9
35233 13 2 9C672AE324884F9A0174330CA7644F6960172C1D94023F946F707639 BE6D3AB0

Stay secure,
Peter

1 Like
3

Found it. That is great! So I was worrying about (almost) nothing :wink:

Yes, and having a German/European service may also be seen as an advantage.

Good to know.

Thanks!
fiwswe

2 Likes