cc-TLDでIPv6とDNSSECをサポートしていませんか？ （実用的な意味）
国コードドメイン拡張子を持ついくつかのドメインを登録する必要がありますが、それらのTLDが（A）IPv6または（B）DNSSECを公式にサポートしていないことに気付きました...これにより、どのような制限または落とし穴に遭遇すると予想されますか？
（A）TLDのIPv6サポートなし
これは、AAAAレコードをドメインに追加できないことを意味しますが、他のIPv6対応DNSサーバーからの到達可能性/互換性/可視性にとってこれはどういう意味ですか？
（B）TLDに対するDNSSECサポートなし
DNSSECがDNS解決を認証するために何らかの形で重要であることは理解していますが、その実装（またはその欠如）がセキュリティに関してアプリケーション開発者としての私に影響を与えるかどうか/どのように影響するかはわかりません。
注：甘やかされて育ったランプ、平均、フロントからのこの潜在的に初歩的な質問を許してください-終わり、そして上記を中心にネットワークアーキテクチャの決定を行う必要がめったにないネイティブモバイル開発者。よろしくお願いします！
CcTLDにネームサーバーのIPv6アドレスがない場合、IPv6のみのユーザーは、たとえそのTLDでanyの名前を解決できない可能性があります。これらの名前はIPv6対応ゾーンにあります。解決はルートから下のチェーンをたどり、1つのリンクが機能しない場合、すべてが失敗します。
DNSSECは、DNSデータの暗号化認証を提供します。 DNSの他のすべてと同様に、ルートゾーンから始まる通常のツリーに従います。また、1つのリンクが機能しない場合、チェーン全体が失敗します。したがって、DNSSECを実行しないccTLDの下の名前は、なりすましに対して脆弱になります（注：isは、このチェーンを回避するための手法です。 DLVと呼ばれるケースですが、非推奨であり、ICANNによるサポートは2017年に終了します）。
より良いTLDの使用を検討します:-)
AAAAレコードは、IPv4リゾルバーとIPv6リゾルバーの両方で配信できます。ドメインにIPv6アドレスを追加すると、それらが配信されます。 IPv6のみのリゾルバー（比較的まれだと思います）を持っている人は、どのような場合でもドメインを解決できません。
DNSSECの標準的な回避策は、DLV（DNSSEC Lookaside Validation）を使用することです。これは長い間使用されており、長い間多くのTLDを検証する唯一の方法でした。 TLDプロバイダーがDNSSECサポートを追加すると、それらのTLDの要件DLVが消えます。
IPv6とDNSSECの両方での全体的な取り込みは非常に遅いです。私がいる場所では、IPv6接続を取得するためにIPv4トンネルが必要です。
TLDがネームサーバーアドレスのAAAAレコードをサポートしていない場合、それは、基盤となるサービスのAAAAレコードを保持できないことを意味するわけではなく、人々ができないことを意味します。 IPv6を使用するにはDNSプロトコル自体にサービスアドレスを検索します。
ドメインレジストリにIPv4のみのネームサーバーがリストされ、それらのネームサーバーがドメイン内のエントリのAAAAレコードを公開するのは、完全に正常な構成です（ BCP 91、別名RFC 3901 を参照）。この時点では何も壊れません-IPv6のみの接続（NAT64なし）はほとんど使用できません。
DNSSECの場合、ほとんどのccTLDはすでにサポートしており、アフリカが主な懸念事項であるにもかかわらず、サポートする予定がないか、すでに実装中です。数日前の最新の ISOCマップ はこれを示しています：
適度に実用的な（しかし、明らかに精度が低いか永続的ではない）ガイド：
上記のピクルスに陥った場合、何らかの理由で問題のTLDを続行する必要があります...
（A）TLDのIPv6サポートなし
この投稿（2016年1月）の時点で、IPv4は非推奨にはほど遠いため、一般的な発見可能性への実際的な影響は最小限に抑えられます。ただし、この仮定が不正確であるため、ブランディングやTLDの一括取得/転送の理由などにより、特定のTLDの使用が避けられない場合があります...
- IANA（ICANN部門）のルートゾーンデータベース（ http://www.iana.org/domains/root/db ）にアクセスし、TLDの対応するスポンサー組織の公式の技術的および管理上の連絡先の詳細を見つけて連絡してください。 IPv6がサポートされるかどうか/いつサポートされるかを確認します。
（B）TLDのDNSSECサポートなし
DNSSEC対応のリゾルバーは、MITM攻撃を防ぐことを目的とした追加の作業（SSLとは異なります）で要求を処理する前にデジタル署名をチェックするため、それを見落とすことは賢明ではありません。 TLDが現在サポートしていない場合...
- 一時的な回避策は、DNSSEC Lookaside Validation（DLV）の実装です。この場合、権限のあるネームサーバーではなく、リゾルバーまたはキャッシングサーバーに常駐する必要があります。しかし、単にサイトやアプリケーションをホストしているだけの場合は、最初に問題の解決ネームサーバーでこれを行うことはできないでしょう。@ Calle-Dybedahlが示唆しているように、このオプションは間もなく終了します。 〜2017。 （ここで公式の日没計画を参照してください： https://singapore52.icann.org/en/schedule/mon-tech/presentation-dlv-decommissioning-09feb15-en.pdf ）
したがって、上記の（A）と同様に...
- IANA（ICANN部門）ルートゾーンデータベース（ http://www.iana.org/domains/root/db ）にアクセスし、TLDの対応するスポンサー組織の公式の技術的および管理上の連絡先の詳細を見つけて連絡してください。 DNSSECがサポートされるかどうか/いつサポートされるかを確認します。
これは、AAAAレコードをドメインに追加できないことを意味します。
これは間違っています。ドメインレジストリの無能さは、使用できるレコードタイプとは関係ありません（サーバーを正式な名前として使用するように強制されない限り、その場合は遠くに実行することをお勧めします）。
しかし、これは他のIPv6対応DNSサーバーからの到達可能性/互換性/可視性にとって何を意味するのでしょうか？
Tldのゾーンがipv6で利用できない場合、ipv6のみのリゾルバーはドメインを解決できません。
Tldのゾーンがipv6で利用できるが、IPv6グルーレコードを提供できない場合は、事態はさらに複雑になります。ネームサーバーが問題のドメインの下にある場合、IPv6のみのリゾルバーをサポートするにはIPv6グルーレコードが必要です。ネームサーバーが別のドメインの下にある場合は、ドメインにグルーレコードは必要ありません（ただし、一部のドメインでは明らかに必要です）。
いずれの場合も、デュアルスタックリゾルバで問題ありません。近い将来、ほとんどのDNSリゾルバーがIPv4対応（デュアルスタックまたはv4のみ）になる可能性があります。
DNSSECがDNS解決を認証するために何らかの形で重要であることは理解していますが、その実装（またはその欠如）がセキュリティに関してアプリケーション開発者としての私に影響を与えるかどうか/どのように影響するかはわかりません。
Dnssecは、受信したレコードが本物であることを確認するメカニズムを提供することになっています。しかしながら
- 現時点では、大多数のシステムはそれを強制していません。
- レコードが正当であることを確認することは、AおよびAAAAレコードにとってあまり役に立ちません。 DNSを混乱させる可能性のある攻撃者は、IPルーティングを混乱させる可能性も非常に高くなります。
DANEを使用したDNSSECは、現在のCAシステムの将来の代替または補足となる可能性があります。現在のCAシステムは、最悪のCAと同じくらい安全であるため、セキュリティの観点から非常に欠陥があります。
開発しているアプリケーションの種類はわかりません。所有しているサーバーと通信するのがクライアントアプリの場合は、プライベートCAでtlsを使用して接続を保護する必要があります。
Webアプリの場合、パブリックCAシステム（そのままでは安っぽい）が実際には唯一のオプションです。誤って発行された証明書によるリスクを軽減しようとするHKPを検討することをお勧めします。 DNSSEC/DANEを機能させると、セキュリティが向上しますが、実際にそれをサポートしている少数のクライアントにのみ提供されます。
任意のサーバーの使用を許可する独自のプロトコルを設計している場合は、hkpと同等のものを含めることを検討することをお勧めします。