On Fri, Aug 26, 2022 at 10:25:49PM +,
Paul Hoffman wrote
a message of 100 lines which said:
> There's also, you know, the DNS itself
Speaking of DNS, it is time to remind readers that there was a
project to express information such as "is it a public suffix?" in
the DNS and it
; interacted with.
>
> -Jothan
>
>
> On Sat, Aug 27, 2022 at 11:26 AM Paul Vixie via dns-operations
> mailto:dns-operati...@dns-oarc.net>> wrote:
>
>
>
> -- Forwarded message --
> From: Paul Vixie mailto:p...@redbarn.org>>
> To: DNS Operations List
> To: DNS Operations List
> Cc:
> Bcc:
> Date: Sat, 27 Aug 2022 11:20:53 -0700
> Subject: Re: [dns-operations] Browser Public suffixes list
>
>
> Viktor Dukhovni wrote on 2022-08-27 11:06:
> > On Sat, Aug 27, 2022 at 10:48:46AM -0700, Paul Vixie wrote:
>
--- Begin Message ---
Viktor Dukhovni wrote on 2022-08-27 11:06:
On Sat, Aug 27, 2022 at 10:48:46AM -0700, Paul Vixie wrote:
...
see: https://www.ietf.org/mailman/listinfo/dbound
Another aspect of the problem, is that the browsers unified the address
bar and the search bar in order to
On Sat, Aug 27, 2022 at 10:48:46AM -0700, Paul Vixie wrote:
> this...
>
> Meir Kraushar via dns-operations wrote on 2022-08-27 02:56:
> > 2) The need to maintain a list dedicated to browser issues is out of our
> > scope. I'm sure there are good reasons to have it, like you said, there
> > is
--- Begin Message ---
this...
Meir Kraushar via dns-operations wrote on 2022-08-27 02:56:
2) The need to maintain a list dedicated to browser issues is out of our
scope. I'm sure there are good reasons to have it, like you said, there
is gap between the worlds.
...is why the IETF DBOUND
--- Begin Message ---
Hi Jothan
Thank you for the detailed response.
1) After approval and implementation of delegation from the root , I did
not notice any information sent from IANA about PSL.
We were referred to it only much later.
2) The need to maintain a list dedicated to browser issues is
Hi Meir-
I have had some dialog with your CEO on this related to the introduction of
this TLD and its subdomains and the PSL PR expediting for
https://github.com/publicsuffix/list/pull/1595. I volunteer time to
maintain the PSL and I did bump the ישראל, אקדמיה.ישראל, ישוב.ישראל ,
צהל.ישראל ,
On Sat, Aug 27, 2022 at 03:17:18AM +0300, Meir Kraushar wrote:
> You also suggested to not opt-out? What would be the reason for that?
Attackers can no longer fabricate the existence or non-existence of
unsigned delegations whose hashes fall between those of the signed ones.
Of course all
Hi Meir. It might also be good to write to the uasg discussion list
(https://uasg.tech/). I don't know if they'll have contacts with apple, but
this topic fits right in with their "universal acceptance" goal. I remember a
similar case a few years ago, and I'm sure they'll be interested in
--- Begin Message ---
Hi Viktor
You are right, I'll change the nsec3 iterations on xn--4dbrk0ce to 0, no
salt.
You also suggested to not opt-out?
What would be the reason for that?
Thank you for the clarification
Meir
On Fri, Aug 26, 2022, 22:31 Viktor Dukhovni wrote:
> On Fri, Aug 26, 2022
ati...@dns-oarc.net
> Cc:
> Bcc:
> Date: Fri, 26 Aug 2022 19:57:57 -0300
> Subject: Re: [dns-operations] Browser Public suffixes list
> >
> > So bottom line, browser behavior is not based on DNS resolving, nor by
> any IANA list, but rather on the PSL.
> > As I wr
--- Begin Message ---
>
> So bottom line, browser behavior is not based on DNS resolving, nor by any
> IANA list, but rather on the PSL.
> As I wrote earlier we have already merged the diff into the list.
> The next update of firefox and hopefully chromium based browsers (sept 26),
> should
--- Begin Message ---
Indeed, TLD xn--4dbrk0ce was signed and published earlier this year.
As the DNS guy I was sure this is it.
Later on we discovered that browsers have their own lives.
It appears as if firefox and chromium browsers determine if an entered
value is a domain name or a search
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
--- Begin Message ---
Hi peter
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
Hi Meir,
On 8/26/22 06:38, Meir Kraushar via dns-operations wrote:
We are about to go public with a new IDN ccTLD in Hebrew, being xn--4dbrk0ce.
We have done the procedure of updating Mozilla PSL, also merged the list into
chromium. But as far as how Safari browser behaves, we are totally in
--- Begin Message ---
Hi
My name is Meir, from ISOC-IL, the .il registry.
We are about to go public with a new IDN ccTLD in Hebrew, being
xn--4dbrk0ce.
We have done the procedure of updating Mozilla PSL, also merged the list
into chromium. But as far as how Safari browser behaves, we are totally
18 matches
Mail list logo
