7

I'm needing to register some domains that have country code domain extensions, but noticed that those TLDs do not officially support (A) IPv6 or (B) DNSSEC... What limitations or pitfalls should I expect to run into because of this?

(A) No IPv6 support for TLD

I know this means that I won't be able to add an AAAA record to the domain, but what does this mean for reachability/compatibility/visibility from other IPv6-capable DNS servers?

(B) No DNSSEC support for TLD

I understand that DNSSEC is somehow important for authenticating DNS resolving, but have no idea if/how its implementation (or lack thereof) affects me as an application developer when it comes to security.

NOTE: Please forgive this potentially rudimentary question from a spoiled LAMP, MEAN, front-end, and native mobile dev who's rarely had to make network architecture decisions pivoting around the above. Thanks in advance!

Old McStopher
  • 209
  • 1
  • 8

5 Answers5

10

If the ccTLD does not have IPv6 addresses for its name servers, an IPv6-only user may not be able to resolve any names under that TLD, even if those names are in IPv6-competent zones. Resolving follows a chain down from root, and if one link doesn't work, the entire thing fails.

DNSSEC provides cryptographic authentication of DNS data. Like everything in DNS, it follows the normal tree starting at the root zone. And again, if one link doesn't work, the entire chain fails. So any names under a ccTLD that doesn't do DNSSEC will be vulnerable to spoofing (note: there is a technique for side-stepping the chain in this case, called DLV. It is, however, deprecated and ICANN's support for it will end in 2017).

I would consider using a better TLD :-)

Calle Dybedahl
  • 2,083
  • 12
  • 17
  • Curious how to see a schedule of if/when the TLD will support those. Guessing it is up to the country code applicants/registrars? (for lack of a better term) Does ICANN have that info anywhere or a way to contact whomever is supporting a given TLD? – Old McStopher Jan 26 '16 at 10:25
  • 2
    To answer my previous comment, here's a source with sponsoring organizations and their respective technical and administrative contact details: http://www.iana.org/domains/root/db – Old McStopher Jan 26 '16 at 10:39
  • 2
    The most commonly used DLV server is run by ISC, not by ICANN - that's the one that's getting turned off in 2017 - https://dlv.isc.org/ – Alnitak Jan 26 '16 at 15:16
6

AAAA records can be delivered by both IPv4 and IPv6 resolvers. You can add IPv6 addresses to your domain and they will be delivered. People with IPv6 only resolvers (which I believe would be relatively rare) won't be able to resolve your domain in any case.

The standard work-around for DNSSEC is to use DLV (DNSSEC Lookaside Validation). This has been used for a long time and has been the only way to validate a number of TLDs for a long time. As TLD providers add DNSSEC support the requirement DLV disappears for those TLDs.

Overall uptake on both IPv6 and DNSSEC has been very slow. Where I am, I still require an IPv4 tunnel to get IPv6 connectivity.

BillThor
  • 27,354
  • 3
  • 35
  • 69
  • How is `won't be able to resolve your domain in any case` supposed to be interpreted here? – kasperd Jan 27 '16 at 08:21
  • @kasperd People on IPv6 only stacks won't be able to reach IPv4 only resolvers. If the cc-TLD server only has IPv4 addresses, they won't be accessible to resolvers without IPv4 addresses. Devices with IPv4 only stacks have the same issue reaching hosts which only have IPv6 addresses. In some cases proxies may be available to resolve the connectivity issues. – BillThor Jan 27 '16 at 23:21
6

If the TLD doesn't support AAAA records for the nameserver addresses that doesn't mean you can't have AAAA records for your underlying services, it just means that people won't be able to use IPv6 for the DNS protocol itself to lookup your service addresses.

It's a perfectly normal configuration (see BCP 91 aka RFC 3901) to only have IPv4-only nameservers listed with the domain registry, with those nameservers publishing AAAA records for entries within your domain. At this point that won't break anything - an IPv6-only connection (without NAT64) is pretty much unusable.

For DNSSEC, most ccTLDs already support it, and of those that don't many have plans to do so or are already in mid-implementation, albeit with Africa being the main area of concern. The latest ISOC map from a couple of days ago shows this:

enter image description here

Community
  • 1
Alnitak
  • 20,901
  • 3
  • 48
  • 81
  • 3
    Alnitak is a Smart DNS Person™ who is published (unlike me), so please leave a comment if you're going to downvote this. [BCP91](https://tools.ietf.org/html/rfc3901) recommends against IPv6-only nameservers and the "it's a perfectly normal configuration" statement is 100% accurate. – Andrew B Jan 26 '16 at 16:56
  • @AndrewB ah, yes, thanks for the reminder of BCP 91. – Alnitak Jan 26 '16 at 17:29
  • 1
    Very common configuration for networks transitioning from IPv4 only to dual-stack throughout. I can't come up with any reason this possibly could have deserved a downvote. – Brian Knoblauch Jan 26 '16 at 21:03
4

A Modestly Pragmatic (but admittedly less precise or permanent) Guide:

If you find yourself in the above pickle and for whatever reason HAVE to proceed with the TLDs in question...

(A) No IPv6 support for TLD

As of this post (Jan/2016), IPv4 is far from deprecated, so any practical impact to general discoverability should be minimal. But because of the imprecision of this assumption, and there may still be times where using a specific TLD is unavoidable for whatever branding or bulk TLD acquisition/transfer reasons, etc.,...

  1. Visit the IANA (an ICANN department) Root Zone Database at http://www.iana.org/domains/root/db and find official technical and administrative contact details for the TLD's corresponding sponsoring organization and contact them to find if/when IPv6 will be supported.

(B) No DNSSEC support for TLD

Since DNSSEC-aware resolvers check digital signatures before a request can be served in an additional effort (not unlike SSL) intended to prevent MITM attacks, overlooking it is not wise. If your TLD does not currently support it...

  1. A temporary workaround is a DNSSEC Lookaside Validation (DLV) implementation, which would in this case have to reside on a resolver or caching server, not an authoritative nameserver. But if you are simply hosting a site or an application, you are likely not going to be the one to do this on the resolving nameserver in question to begin with, and as @Calle-Dybedahl suggests, this option is coming to a close in ~2017. (See official sunsetting plan here: https://singapore52.icann.org/en/schedule/mon-tech/presentation-dlv-decommissioning-09feb15-en.pdf)

So, similar to (A) above...

  1. Visit the IANA (an ICANN department) Root Zone Database at http://www.iana.org/domains/root/db and find official technical and administrative contact details for the TLD's corresponding sponsoring organization and contact them to find if/when DNSSEC will be supported.
Old McStopher
  • 209
  • 1
  • 8
2

I know this means that I won't be able to add an AAAA record to the domain,

This is wrong. The incompetance of the domain registry has no bearing on the record types you can use (unless they force you to use their servers as the authoritative namesevers in which case I would suggest running far away).

but what does this mean for reachability/compatibility/visibility from other IPv6-capable DNS servers?

If the zone for the tld isn't available over ipv6 then ipv6-only resolvers will not be able to resolve the domain.

If the zone for the tld is available over ipv6 but they won't let you provide IPv6 glue records then things get more complex. If your nameserver is under the domain in question then an IPv6 glue record is needed to support IPv6 only resolvers. If your nameserver is under another domain then glue records are not needed for your domain (though obviously they are needed for some domain).

Dual stack resolvers should be fine in any case. The chances are most DNS resolvers will be IPv4 capable (either dual stack or v4 only) for the forseeable future.

I understand that DNSSEC is somehow important for authenticating DNS resolving, but have no idea if/how its implementation (or lack thereof) affects me as an application developer when it comes to security.

Dnssec is supposed to provide a mechanism to verify that the records you receive are genunine. However

  1. The vast majority of systems don't enforce it at this time.
  2. verifying the records are legitimate isn't really much help for A and AAAA records. An attacker who can mess with DNS can also very likely mess with IP routing.

DNSSEC with DANE is a potential future replacement or supplement to the current CA system. The current CA system is highly flawed from a security perspective because it effectively leaves you only as secure as the worst CA.

You don't say what sort of applications you are developing. If it's client app that talk to a server you own then you should secure your connections using tls with a private CA.

For webapps the public CA system (crappy as it is) is really the only option. You might want to consider HKP which tries to reduce the risk from mis-issued certs. Having working DNSSEC/DANE would provide better security but only for the handful of clients that actually support it..

If you are designing your own protocol which allows use of arbitary servers you might want to consider including an equivilent to hkp.

Peter Green
  • 4,056
  • 10
  • 29