<div dir="auto">Indeed, TLD  xn--4dbrk0ce  was signed and published earlier this year. <div dir="auto">As the DNS guy I was sure this is it.<br><div dir="auto">Later on we discovered that browsers have their own lives. </div><div dir="auto">It appears as if firefox and chromium browsers determine if an entered value is a  domain name or a search value, based on a list called  "PSL", which is maintained by Mozilla volunteers: </div><div dir="auto"><a href="https://publicsuffix.org/">https://publicsuffix.org/</a></div><div dir="auto">Like I said, this was new to us and frankly very surprising. I think this xkcd </div><div dir="auto">describes this situation best: <a href="https://xkcd.com/2347">https://xkcd.com/2347</a></div><div dir="auto"><br></div><div dir="auto">So bottom line, browser behavior is not based on DNS resolving,  nor by any IANA list, but rather on the PSL.</div><div dir="auto">As I wrote earlier we have already merged the diff into the list. </div><div dir="auto">The next update of firefox and hopefully chromium based browsers (sept 26), should contain the updated list.</div><div dir="auto">The only browser we could not find any documentation on this matter is Apple's safari.</div><div dir="auto">p.s It has nothing to do with right to left scripts.</div><div dir="auto"><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 26, 2022, 22:31 Viktor Dukhovni <<a href="mailto:ietf-dane@dukhovni.org">ietf-dane@dukhovni.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Aug 26, 2022 at 09:20:00PM +0300, Meir Kraushar wrote:<br>
<br>
> Yes the problem is that browsers not aware of a TLD, in this case SAFARI<br>
> unaware of xn--4dbrk0ce,  do not treat it as a domain.  It won't resolve<br>
> the given name and go to the address. Instead, it will pass the value to<br>
> the search engine. This is bad. Most certainly not the desired behavior<br>
> when launching a new domain.<br>
<br>
That's rather odd.  How old is the Safari release you're testing?  The<br>
TLD is no longer "brand new": DNSSEC/DANE survey data for the TLD shows<br>
a go-live date in Mar 2021, with DNSSEC signing in May of this year.<br>
<br>
        qname     | dnssec |    date    <br>
    --------------+--------+------------<br>
     xn--4dbrk0ce | f      | 2021-03-18<br>
     xn--4dbrk0ce | t      | 2022-05-13<br>
<br>
If Safari has a built-in list of TLDs, it'd have to have been "baked in"<br>
at least ~1.5 years ago.<br>
<br>
Speaking of DNSSEC, I see you're using NSEC3 with opt-out and 5<br>
iterations.  Please consider 0 iterations, *no* opt-out and possibly<br>
empty salt.  See:<br>
<br>
    <a href="https://www.rfc-editor.org/rfc/rfc9276.html" rel="noreferrer noreferrer" target="_blank">https://www.rfc-editor.org/rfc/rfc9276.html</a><br>
<br>
Indeed when trying: xn--5dbedt4e.xn--4dbrk0ce, also recent Firefox and<br>
Chrome suggest a search rather than treating it (בדיקה.ישראל) as a<br>
domain first.<br>
<br>
It seems that PSL aside (cookie scope management), the browsers have<br>
additional rules about which punycode strings they accept as domain<br>
names.<br>
<br>
-- <br>
    Viktor.<br>
_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net" target="_blank" rel="noreferrer">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel="noreferrer noreferrer" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
</blockquote></div>