[dns-operations] Browser Public suffixes list
meir at isoc.org.il
Sat Aug 27 00:17:18 UTC 2022
You are right, I'll change the nsec3 iterations on xn--4dbrk0ce to 0, no
You also suggested to not opt-out?
What would be the reason for that?
Thank you for the clarification
On Fri, Aug 26, 2022, 22:31 Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 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:
> 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
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dns-operations