Hi, In the context of the recent .mobi whois takeover vulnerability, I had, as already mentioned in another thread, checked all the whois servers listed in IANAs data, and found a substantial number not answering. (Those were for the TLDs cf ci dz ec gn gp hm iq ml na sb tk to uy xn--lgbbat1ad8j xn--mgbtx2b xn--ygbi2ammx)
I reported this to IANA, and also asked them about the reliability of the whois server data provided by them, as I believe this is very relevant for the security of whois as a domain validatin mechanism. Kim Davies from IANA shared this with me, and allowed me to share it publicly with this group: > You'll note that the TLDs you gave identified with inoperative WHOIS > servers are country-code top-level domains (ccTLDs). For ccTLDs, > there is no global policy requirement for ccTLD managers to operate a > WHOIS server, and if they do, what kind of information is provided. > ccTLDs are expected to be operated under local oversight (i.e. within > their respective country) and accountability for how WHOIS servers > are operated is performed locally, not under ICANN policies. This is > in contrast to generic top-level domains (gTLDs) where ICANN policies > establish specific requirements and obligations, which are maintained > through contracts. ICANN operates a contractual compliance function > to address when these obligations are not met. > > More generally, TLD managers are obligated to keep their records > up-to-date with IANA. but again in the case of country-code top-level > domains IANA does not have an enforcement mechanism to ensure the > ccTLD manager maintains accuracy of their records. We do verify the > data is correct at the time we are assessing a change request from > the TLD manager, but we cannot ensure it is consistently maintained > without the ccTLD manager voluntarily participating. This is an issue > that has been raised with the policy setting body for ccTLDs, the > Country Code Name Supporting Organization (ccNSO), and they have > recently established a working group called the Policy Gaps Analysis > Working Group that is expected to study the issue in the near future. > > To your question as to whether IANA can guarantee control of the > servers that TLD operators use to operate their TLDs. We believe we > have sufficient safeguards in our processes that when we receive > change requests from TLD operators, we validate they are authentic > and appropriately authorized, and we confirm at that time the servers > are those duly designated by them. However we are only responsible > for their entries in the root zone and the associated meta-data > concerning who the recognized operator of the domain is. We have no > policy basis to investigate the internal workings of a TLD manager > and perform assessments on whether they have full control over the > components that comprise their registry operations. And in a further mail: > Briefly reading that thread, on an informal basis we have reached out > to whois client vendors when we notice poor implementations. The IANA > WHOIS server (whois.iana.org) actually has a "refer:" field that, > when queried for a FQDN that is more specific than the data we hold, > provides referrals to second-level WHOIS servers programmatically so > that there is no need to hard-code TLD WHOIS server locations. With > that said, WHOIS itself as a protocol is being superseded by RDAP > which has a more robust discovery/referral approach and would be the > preferred mechanism moving forward. I take away two things from this: * Hardcoding whois servers, like what appears to be the standard of many whois tools, is generally not a good idea. If one uses whois at all, one should query the iana whois server, and use the "refer:" field to get to the actual whois server responsible. * Particularly whois data for ccTLDs has limited reliability, and we have no guarantee that TLD operators keep this information updated and accurate. In my opinion, the latter is even more reason to consider deprecating whois as a domain validation mechanism. I have not looked into RDAP, and do not know about its security properties and whether this is used by CAs as an alternative to whois. -- Hanno Böck - Independent security researcher https://itsec.hboeck.de/ https://badkeys.info/ -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20240913151529.2289f19d%40computer.
