Edward Lewis schreef op 2025-01-22 18:11:
On Jan 22, 2025, at 10:35 AM, Ben van Hartingsveldt | Yocto
wrote:
1) User goes to DNS provider and creates zone.
I think there’s a problem with step 1. A user (which is
any-off-the-street-customer) is not the source of authority when it
comes to
Michele Neylon - Blacknight schreef op 2025-01-22 15:50:
So you want to create a level of complexity and extra work for
everyone?
As a registrar that’s my read on this.
If you want to avoid hijacking then “registry lock” in one of its
flavours gets you there. And DNS records existing where the
Sorry for my mail being sent twice. My mailserver did some strange
things.
Anyway, my response is below:
Dr Eberhard W Lisse schreef op 2025-01-22 16:38:
While fully agreeing with Michele, some remarks from a ccTLD Manager's
perspective:
On 2025/01/22 17:50, Michele Neylon - Blacknight wrote:
Shumon Huque schreef op 2025-01-21 04:55:
I've changed the subject line to "Domain Hijacking countermeasures"
since the topic is somewhat different from the problem this draft is
trying to solve.
The problem you cite is how a (typically shared) 'DNS provider'
verifies that someone legitimately h
Shumon Huque schreef op 2025-01-21 04:55:
I've changed the subject line to "Domain Hijacking countermeasures"
since the topic is somewhat different from the problem this draft is
trying to solve.
The problem you cite is how a (typically shared) 'DNS provider'
verifies that someone legitimately h
6. Estonian VAT №: EE102625532. Glauca
Digital and the Glauca logo are registered trademarks in the UK, under
№ UK3718474 and № UK3718468, respectively.
On Thu, 15 Aug 2024 at 18:04, Ben van Hartingsveldt
wrote:
Dear all,
Thanks for the responses I received. I got some useful feedback
uld I add, change or remove in order to
improve it? Because some interpreted my draft differently, are there
some texts I wasn't fully clear? Please let me know.
Thanks in advance
Ben
Ben van Hartingsveldt schreef op 2024-07-26 09:07:
Dear all,
Today, I released a new version of the d
ter Thomassen: Is it possible to make some list with all interop
problems for this draft? With such list, I can look for ways to address
them; or that I conclude to reframe the draft to be for confined systems
only.
Ben
Ben van Hartingsveldt schreef op 2024-07-23 08:56:
Dear all,
Today, I released
erefore is not really the DNS's problem;
your storage layer could use some other datastructure "around" the DNS
data to represent that information. -- I wouldn't mind a label type
assignment as described above, though.
On 7/21/24 11:50, Ben van Hartingsveldt wrote:
Dear a
Dear all,
Today, I released a new version of the draft:
https://datatracker.ietf.org/doc/html/draft-yocto-dns-relative-label-01.
I tried to clarify things a little bit more, added some examples and
fixed some references.
Ben
Ben van Hartingsveldt schreef op 2024-07-21 18:50:
Dear all,
In
Hi Alexander,
My response is also inline:
Alexander Robohm schreef op 2024-07-21 21:44:
Hi Ben,
- The DNS UPDATE RFC redefines the question section as the zone
section. This means that the DNS server already doesn't extract the
target zone from the record name, but from the zone section. A
g functionality in other ways.
You should also check your citations - [RFC2671] links to RFC 2119, and
RFC 2065 was obsoleted in 1999.
Alexander Robohm
Am 21.07.2024 um 20:50 schrieb Ben van Hartingsveldt:
Dear all,
In the recent years I started working on my own coded DNS server,
because I was do
rmat to mention something important.
That is why I want you to give your honest opinion on this topic. Do you
agree with the problem? Does DNS need such label? Did I make a typo?
Etc.
Please let me know.
Thanks in advance
Ben van Hartingsveldt
___
DNS
13 matches
Mail list logo
