From my research, ENS is designed to be extensible & flexible, it doesn’t currently support DNSSEC due to "the lack of support for cryptographic signatures in Ethereum smart contracts".

The ENS system is designed to be extensible, so that it can be used to resolve a wide variety of resources, including blockchain addresses, off-chain web resources & other purposes in the future…

But Resolving an ENS domain's node ID can vary depending on the specific domain & "methods"used by the resolver.

Some suggested methods for resolving an #ENSdomain's node ID include using ENS console or "service that maintains a database of node IDs" such as Infura's ENS resolver…

I don’t fall for ‘Handshake' or 'Unstoppable Domain'.. Moreover, at the prelude to ENS, I ventured into it & even mint an ‘emoji-domain’ to see if ENS was compatible with it or even with the ‘Puny Code’ but Domain names are meant to be human-readable, which means that they can only contain a limited set of characters.

Ensuring that everyone can use ENS remains to limit domain names to the subset of ASCII characters that can be encoded using 'Punycode'. This allows ENS to avoid depending on any particular blockchain's native encoding mechanisms because it’s compatible with the internationalization (i18n) standards..

In the end, ENS isn’t so effective & is full of some disadvantages for the use of deploying an IPFS..