
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">I’m not sure why the dot prod was not first set up to return NXDOMAIN, queries logged, and then source IP contacted to warn them of such upcoming change.<br><br>May be this is an insight now, may be this is something to do for ALL newly introduced TLDs, set up the resolution for a month with NXDOMAIN and then analyze the logs and see if it could be an issue.<br></div></blockquote></div><br><div><br></div><div>Such query logging could be seen as front-running, which is forbidden by ICANN contracts. An idea similar to what you mentioned has been floated in the new gTLD program, but has been withdrawn due to large criticism from the community, including RIRs. </div><div><br></div><div>What we tried was to contact the users that were likely to be more affected by collisions when the queried name allowed us to infer who would be affected, following information from this report:</div><div><a href="https://www.jasadvisors.com/namespace-expansion-i.pdf">https://www.jasadvisors.com/namespace-expansion-i.pdf</a></div><div><br></div><div>We had 0% of responses of such contacts, indicating that was likely that a massive mailing of IP space contacts wouldn't have much of a effect anyways. </div><div><br></div><div><br></div><div>Rubens</div><div><br></div><div><br></div></body></html>