Comment 51 for bug 308181

Believe me, NAPTR and TXT record support are needed right now.

TXT record support is currently needed for frameworks like SPF and DomainKeys. They would also be useful for a number of more exotic services.

NAPTR records are needed right now if you're going to implement any servive that uses DDDS; for example ENUM services and SIP.

MX and PTR records would be useful, too: consider things like performing double-reverse-lookups.

If these two record types were also supported, say with resolveTXT, resolveNAPTR, resolveMX and resolvePTR methods, this would also close bug 356104 (at least for the time being).

However, what I was proposing was more generic. By implementing an interface like

nsIIDNService::resolveWithRecordType(name, record_type)

where "record_type" is a string in the obvious format, and returns an iterator in exactly the same way as the proposed resolveSRV method, this would remove the need for a method per record type, thus allowing extension of the repertoire of supported records in future without changing the interface.

(I'm not sure what the behaviour should be if a particular record type was not supported, though; presumably something should be chosen which maximizes the possibilities for forwards and backwards compatibility)

resolveSRV could then be implemented on top of this, without any loss of generality or efficiency.