[dns-operations] Browser Public suffixes list

[Viktor Dukhovni]

On Fri, Aug 26, 2022 at 09:20:00PM +0300, Meir Kraushar wrote:

> Yes the problem is that browsers not aware of a TLD, in this case SAFARI
> unaware of xn--4dbrk0ce,  do not treat it as a domain.  It won't resolve
> the given name and go to the address. Instead, it will pass the value to
> the search engine. This is bad. Most certainly not the desired behavior
> when launching a new domain.

That's rather odd.  How old is the Safari release you're testing?  The
TLD is no longer "brand new": DNSSEC/DANE survey data for the TLD shows
a go-live date in Mar 2021, with DNSSEC signing in May of this year.

        qname     | dnssec |    date    
    --------------+--------+------------
     xn--4dbrk0ce | f      | 2021-03-18
     xn--4dbrk0ce | t      | 2022-05-13

If Safari has a built-in list of TLDs, it'd have to have been "baked in"
at least ~1.5 years ago.

Speaking of DNSSEC, I see you're using NSEC3 with opt-out and 5
iterations.  Please consider 0 iterations, *no* opt-out and possibly
empty salt.  See:

    https://www.rfc-editor.org/rfc/rfc9276.html

Indeed when trying: xn--5dbedt4e.xn--4dbrk0ce, also recent Firefox and
Chrome suggest a search rather than treating it (בדיקה.ישראל) as a
domain first.

It seems that PSL aside (cookie scope management), the browsers have
additional rules about which punycode strings they accept as domain
names.

-- 
    Viktor.