tion
DNS hijacking is specifically mentioned, however I think this can be
generalised accordingly to the control validation used. If https server
is used then new possibilities of change of control over an identifier
outside of DNS can be open.
4.6. Variety of DNS Management User Interfaces
For Authorization one needs to take user/zone owner in the loop. Either
by obtaining authorization upfront (like saying: by delegating to this
server it's also allowed for this server to do certain things related to
this delegation, like setting keys, a.k.a CDS/CDNSKEY) or getting the
authoriza
-update
There is a refreshed draft, not yet clear which WG would be appropriate
to proceed with this work however there was good feedback and support in
the regext session to solve this "issue"
https://datatracker.ietf.org/doc/draft-kowalik-regext-domainconnect/
I was also asked by
Hi Paul,
No idea how I skipped responding to the mailing list last time, so the
conversation went on a private track, but now fixing this.
On 03.02.25 22:12, Paul Hoffman wrote:
On Feb 3, 2025, at 05:33, Pawel Kowalik wrote:
This is an interesting approach to solve this problem with
Hi Paul,
On 04.02.25 20:32, Paul Hoffman wrote:
[PK snip...]
3) The assumption seems to be that DUJ is always generated dynamically for each
application. Some simple service scenarios only require a static setup, so a
DUJ could be even offered as part of documentation. This would require that
Hi Paul,
On 06.02.25 19:32, Paul Hoffman wrote:
On Feb 5, 2025, at 07:16, Pawel Kowalik wrote:
Hi Paul,
On 04.02.25 20:32, Paul Hoffman wrote: [PK snip...]
3) The assumption seems to be that DUJ is always generated dynamically for each
application. Some simple service scenarios only require
Hi,
On 20.03.25 20:28, Petr Špaček wrote:
On 1/30/25 20:40, Paul Hoffman wrote:
Title: DNS Update with JSON
Status: https://datatracker.ietf.org/doc/draft-hoffman-duj
Ad version: 03
After the discussion in dnsop session today about escaping and doing
DUJ64 only, and reading through all
