[DNSOP] Re: Request Feedback: draft-sheth-dns-integration

[kowalik]

Hi Swapneel,

This is a valuable work. Some remarks below:

4.1.  Domain Name Lifecycle / 4.5.  Identifier Attribution

I would add any other changes to the technical configuration which might 
affect the integration (such as change of delegation).


Also an aspect of an owner of a domain name being blocked from usage of 
the name at an integration should be mentioned in both cases if the 
ownership would change but also if the integration would not verify at 
all and allow blocking names as a result.


One additional observation that might be mentioned is that DNS and 
domain registration ecosystem is currently lacking an effective 
mechanism of assuring this recommendation other than polling over 
existing protocols (WHOIS/RDAP/DNS) to figure out any change that might 
have happened. Even this would be limited only to visible changes and 
not all changes if some data would be redacted.


4.2.  Domain Control Validation

The draft mentions "storing evidence directly on a server referenced by 
a DNS domain name". Later it indicates the intention to verify that the 
current registrant is performing the integration. I think at least some 
text should be added about the level of indirection that domain control 
validation should accept as well as the goal of the validation. Even 
with the usage of DNS there is the TLD registry which actually deals 
with the "current registrant" and the Nameserver handling the zone which 
may be already controlled by other party who would be able to 
successfully complete the validation. Next level of indirection to a 
(web) server would be one additional step away from the registrant. Some 
integrations would just have a goal to assure technical control over the 
name in DNS or webserver, others would really seek to have a 
confirmation from the registrant, so maybe the text should account for that.


The scope of the validation, which is very broadly described in 
ietf-dnsop-domain-verification-techniques shall also here be taken into 
consideration.


4.3.  Completeness

This part could also express a stronger wish to support all names 
allowed in DNS to avoid confusion and negative domain owner experience. 
Otherwise an integration might decide "out of technical reasons" to only 
support ascii domains, which won't be in line with universal acceptance 
efforts.


4.5.  Identifier Attribution

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

Domain Connect draft-kowalik-regext-domainconnect may be mentioned as 
one of the methods of dealing with this particular issue.


Kind Regards,

Pawel

On 05.08.24 18:04, Sheth, Swapneel wrote:
>
> DNSOP,
>
> Just before IETF 120 we published a draft "Integration of DNS Domain 
Names into Application Environments: Motivations and Considerations" 
along with co-authors from Bluesky and Ethereum Name Service.  You may 
have seen us socializing it at the hackathon and HotRFC or heard the 
request for feedback during Thursday's DNSOP session when the chairs 
mentioned it during the "Drafts of Note" of section.

>
> During IETF 120 we received a lot of good feedback around this draft 
and would like further feedback!  Since the initial 00 version, we have 
changed the draft to informational and are in the process of evaluating 
how best to incorporate the other feedback we received.

>
> The goal of this draft is to provide informational guidance to 
communities who are trying to incorporate DNS domain names into their 
applications.  The draft currently provides motivations for why 
applications opt to utilize domain names and qualities that applications 
should consider as they build and maintain their integrations, e.g., 
having processes in place to account for domain name lifecycle events or 
DNS protocol evolution.  We would appreciate feedback on the current 
draft and other motivations/qualities we should consider including that 
would make this draft as useful as possible to these communities.

>
> We would be happy to take feedback here on the mailing list.
>
> Thanks,
> Swapneel Sheth


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: [dconn] Re: Re: "DNS Update with JSON", this time with simpler syntax and optional Base64

[kowalik]

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 
authorization when the records are set, like Domain Connect does.


Kind Regards,

Pawel

On 20.03.25 19:53, Petr Špaček wrote:

On 3/7/25 19:02, Phillip Hallam-Baker wrote:
On Thu, Mar 6, 2025 at 6:16 PM Ted Lemon > wrote:


    __
    I did a proof of concept at a hackathon about four years ago, but
    getting stuff like this into actual routers is hard. We are working
    on it in CSA/Matter, but I don’t see that happening this year.

I believe that the core problem is usability. If we can convince 
router providers that we have solved the usability issues, we are 
much more likely to expect stuff we produce to be used and that is 
going to make it much easier to get them to implement.


Every step we ask of consumers reduces the number of likely users by 
at least 50% and some say 90%.



Turning configurations into QR codes might seem trivial and 
unnecessary to DNSOPS folk but it is really important when it comes 
to making things 'just work'.


One option we might look at is companies like Ubiquiti which have 
been producing gear that rise above the 1990s tech most in that 
market seem to consider acceptable. But that is not my immediate 
concern. Let's start off with the problem of how to get a public DNS 
provider onboard.



What if there was a way that Alice could package up an Ed25519 or 
Ed448 key into a URI and that was the only thing she needed to pass 
to her DNS authoritative server for them to set up the zone so her 
applications can push the updates out to it?


Shipping a key is not a _technical_ problem. E.g. you can wrap a 
public key into KEY RR represented as DUJ. That KEY RR is then used to 
authenticate SIG(0) UPDATEs. KEY RR + SIG(0) works for many years now.


Much harder problem is how to attach authorization data to a given 
key. To what zone does the key apply? To what RR types? Does the 
server care if RRs were added by someone else/Is there a concept of 
'ownership' of a RR? Or all users/keys equal? etc. etc.


Authentication can be solved with some technical effort. For 
authorization, I'm not so sure because requirements differ wildly 
depending on use-case.




smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Domain Connect update

[Pawel Kowalik]

Hi,


After the presentation by regext this week it turned out that this work 
can be also of interest of dnsop WG.


Few slides from regext show especially the current implementation status 
and adoption


https://datatracker.ietf.org/meeting/120/materials/slides-120-regext-sessa-domain-connect-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 few people already about applicability of Domain 
Connect for other use cases, like provisioning parent-side RRs through 
registrar channel (DNSSEC bootstrapping, change of delegation etc.). 
This is not yet covered but an interesting future work IMHO.



Kind regards,

Pawel



OpenPGP_0xABB62115F7BCDB04.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: [Ext] For consideration by DNSOP: "DNS Update with JSON"

[Pawel Kowalik]

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 potentially low 
barrier entry.

Thanks! (For those in DNSOP who don't know, Pawel is a co-author on the 
DomainConnect draft.)


I think few properties of this solution would be worth being clarified in the 
draft.

1) Is there an intention that DUJ string could be freely or is welcoming to be 
modified by the user? Base64 of DUJ would also do the job the same way, likely 
would be less error prone when copy paste and not necessarily welcome fiddling 
with the content.

There is no such intention. I'll add that to the draft.

[PK] Thanks.



2) Why TTL is not covered? This is common that the service would also suggest 
an appropriate TTL for their RRs

The TTLs in a zone are usually controlled by the zone operator. I can imange a 
zone owner saying at a particular record should only be in a zone for so long, 
but not the TTL. The TTL is an operational part that should be controlled bu 
the zone operator.


[PK] Typically DNS operator user interface allows for setting of TTL, so 
it is in fact controlled by the user.


Also most the services typically specify TTL value they would like to 
see for their records. Likely not always out of good reasons but this is 
a fact to consider.


For the completeness of DUJ I would advocate to include TTL, even if 
handling would mean that it might be overwritten/normalised by the DNS 
operator.



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 DUJ 
would also include relative records, not only FQDN.

A rabbit hole at the bottom of a slippery slope. I think that's best handled by 
the proposals for automated updates.


Thinking about potential applicability of DUJ, I would say that a 
possibility to have a static DUJ that can be applied to foo.com and 
bar.com same way is an interesting feature (actually going even further 
away from automation), rather than requirement to generate new DUJ for 
each zone.



4) Also the assumption seems to be, that the service would upfront check the 
content of the zone and generate DUJ accordingly. For example a service might 
want to add DMARC record only if there isn't one in the zone alteady. If this 
assumption is true a valid consideration might be to see how the user might be 
informed if the zone content changed in the mean time before DUJ generation and 
DUJ application.

Ooooh, good point. Will add.


5) Is DUJ application all-or-nothing?

Yes.


Section 4 tells "does so only after verifying all the contents of the DUJ 
string.". Does it mean DNS operator needs to ensure that all the operations can be 
actually applied and reject whole DUJ if not?

Yes.


What is the expectation if out of whatever reason DUJ would fail in the middle? 
Is it supposed to be transactional (ergo rollback) or just applied to the first 
error?

Rollback. If there is a way to say that better in the document than the quoted 
sentence, I'll certainly add it.


[PK] "verifying all the contents of the DUJ string" is then too vague, 
or if it refers to section 3.1 not sufficient.


I would rather suggest "...after verifying that the entire DUJ string 
can be atomically applied to the target zone. The DNS operator MUST NOT 
process any action within the DUJ if any action would prevent the atomic 
application of the entire DUJ."



6) The Action Processing section 4.2. seems to assume DOJ application is not 
idempotent. This is an interesting property, as in fact the service issuing DOJ 
is rather interested in the final state of the zone, meaning not that a record 
is added or deleted, but rather existence or not existence of a desired RR. So 
a deletion of an non-existing record would be OK, because this is what the 
service wanted. Also adding a record with exactly the same content as an 
existing record shall also not be an issue, because in the end this is what the 
service was expecting as result of the action.

Either would cause the DUJ string to be rejected in whole, so I'm not sure why 
an application service would suggest that.


[PK] ok, so generally it's in line with the point 3, that DUJ is always 
generated according to the state of the zone (or at least relevant part 
of the zone known to the service generating DUJ), so none of the actions 
would ever render error unless the zone changed in between. This kind of 
excludes any static DUJ, also because there is no wildcard matching - so 
it's impossible to say "remove all A RRs on this host".


A weak point of this approach, rather than a decl

[DNSOP] Re: [Ext] For consideration by DNSOP: "DNS Update with JSON"

[Pawel Kowalik]

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 DUJ 
would also include relative records, not only FQDN.


A rabbit hole at the bottom of a slippery slope. I think that's best handled by 
the proposals for automated updates.

Thinking about potential applicability of DUJ, I would say that a possibility 
to have a static DUJ that can be applied to foo.com and bar.com same way is an 
interesting feature (actually going even further away from automation), rather 
than requirement to generate new DUJ for each zone.

This shifts the burden of work from the application service to the DNS 
operator, while at the same time making the string more complicated. I don't 
see that as a net win for usability.


[PK] true that. A design and use-case decision obviously.

One additional aspect to consider when using FQDN is that it does not 
offer clarity which zone the DUJ needs to be applied to.


For existing zone it would be enough to say "apply the template to the 
most specific zone for given FQND, or all FQNDs in DUJ". An additional 
question comes to my mind here: should DUJ allow multi-zone changes or not?


2.2 states however that "the FQDN might be a zone that does not yet 
exist because it is being created by an "add" action.". In this sense it 
won't be deterministic to tell which zone to create. For FQDN 
"_443._tcp.foo.example.com" the zone might be foo.example.com or 
example.com.


[PK snip...]


A weak point of this approach, rather than a declarative "desired state" 
approach is that the service does not know how the zone looks like, only what responses 
the RRs deliver. So if a zone would have a wildcard TXT record on the APEX and no DMARC, 
a service might think to remove this TXT record on _dmarc host, even though its not a 
real record and any attempt to remove it would fail.

Good point. I don't know how we could deal with that short of making a mini 
programming language, and I think that would again hurt adoption.


[PK] A way to deal with it would be to tell that a "del" action won't 
fail if RR does not exist. Result is the same - the record does not 
exist. A warning might be appropriate. Actually the same situation is 
with "add" - if exactly the same RR already exists why would add need to 
fail? After adding it the records would have existed the same way.


Kind Regards,

Pawel




smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: [Ext] For consideration by DNSOP: "DNS Update with JSON"

[Pawel Kowalik]

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 a static setup, so a 
DUJ could be even offered as part of documentation. This would require that DUJ 
would also include relative records, not only FQDN.



A rabbit hole at the bottom of a slippery slope. I think that's best handled by 
the proposals for automated updates.


Thinking about potential applicability of DUJ, I would say that a possibility 
to have a static DUJ that can be applied to foo.com and bar.com same way is an 
interesting feature (actually going even further away from automation), rather 
than requirement to generate new DUJ for each zone.


This shifts the burden of work from the application service to the DNS 
operator, while at the same time making the string more complicated. I don't 
see that as a net win for usability.

[PK] true that. A design and use-case decision obviously.
One additional aspect to consider when using FQDN is that it does not offer 
clarity which zone the DUJ needs to be applied to.
For existing zone it would be enough to say "apply the template to the most specific 
zone for given FQND, or all FQNDs in DUJ". An additional question comes to my mind 
here: should DUJ allow multi-zone changes or not?
2.2 states however that "the FQDN might be a zone that does not yet exist because it is being created by 
an "add" action.". In this sense it won't be deterministic to tell which zone to create. For 
FQDN "_443._tcp.foo.example.com" the zone might be foo.example.com or example.com. [PK snip...]

Telling someone to create a zone with two levels below the current zone 
inherently creates the zone one level below. I can't see anyone thinking any 
different.


[PK] Having the example above, assuming the user does have example.com 
in their account one way of processing would be to just add the RR 
_443._tcp.foo to this zone. Other interpretation would be that 
foo.example.com needs to be created as a separate zone and _443._tcpRR 
created in this zone. Basically DUJ does not tell anything about zone 
cut and still asks to create a zone.


If example.com is not in the account then DNS operator can only "guess" 
which zone to create. example.com or foo.example.com or maybe something 
else?


2 ways out of this problem: define clearly the zone in DUJ or remove 
this part about creating zone that does not exist and being created by 
"add". I would rather opt for the latter as service provider may not 
exactly know the zone cuts when creating DUJ.



A weak point of this approach, rather than a declarative "desired state" 
approach is that the service does not know how the zone looks like, only what responses 
the RRs deliver. So if a zone would have a wildcard TXT record on the APEX and no DMARC, 
a service might think to remove this TXT record on _dmarc host, even though its not a 
real record and any attempt to remove it would fail.


Good point. I don't know how we could deal with that short of making a mini 
programming language, and I think that would again hurt adoption.


[PK] A way to deal with it would be to tell that a "del" action won't fail if RR does not 
exist. Result is the same - the record does not exist. A warning might be appropriate. Actually the 
same situation is with "add" - if exactly the same RR already exists why would add need 
to fail? After adding it the records would have existed the same way.

Why allow a service provider, who can do DNS lookups before creating a DUJ, to 
make sloppy errors? I don't see who this helps.


[PK] This is not about sloppy errors but about situation (quite common 
for TXT records btw) that a wildcard would make service provider think 
they would have to remove a record, which in fact does not exist.


Kind Regards,

Pawel



smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: For consideration by DNSOP: "DNS Update with JSON"

[Pawel Kowalik]

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 the discussions on list to date, I 
think we should adopt proposal by Robert Edmonds here:

https://mailarchive.ietf.org/arch/msg/dnsop/8mW0o9JOkAkjgZTSP3SqLiLO8QA
Namely the mandatory RFC3597 syntax.

Using RFC3597 for RDATA portion of the record-data (which would get 
Base64 encoded anyway) will avoid lots of trouble with encoding and 
decoding.


I don't think this is any good idea. Likely implementers of DUJ on the 
receiving side, at least for the copy-paste use case of unskilled users 
that Paul highlighted as main use case, will be front-end developers, 
not DNS experts. Making the format more complicated to decode and not 
understandable for them will just kill possible adoption of DUJ.


Kind Regards,

Pawel



smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Charter proposal for domain connect (dconn) working group

[Pawel Kowalik]

Hi,

After the AD decision not to proceed with the domain connect draft as 
AD-sponsored the preferred way forward seems to be forming a working 
group tasked with this work.


Orie asked me to propose a charter text and initiate the discussion here.

I kept the charter in a very narrow scope, so that this potentially new 
working group can finish the work in a foreseeable timeframe.



Please feel free to comment in the document directly or provide feedback 
over the mailing list.


https://docs.google.com/document/d/1fDVD4RoJ0vHJ5CsSlshZpzm5dfq145sb


There was a number of people, who expressed interest for this work and 
in the potential working group in the previous discussion.


A feedback or even +1 would be of a value. Thanks.


PS: cross-posting to all working groups with potential interest, but 
please just post (and subscribe) to dconn mailing list when responding.


Kind Regards,

Pawel



OpenPGP_0xABB62115F7BCDB04.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Domain Connect at DNSOP

[Pawel Kowalik]

Hi,

In the light of the recent discussion on new DNSOP charter [1] and WG's 
role on DNS related drafts or a dispatch function in this field I would 
like to ask for WG opinion on draft-kowalik-domainconnect.


I am looking for a guidance or opinions, if Domain Connect can or should 
be adopted by DNSOP, or whether the current route with forming new WG is 
still the correct one.


If someone is looking for general information, the recent presentation 
by ART AREA interim is a good source [2] [3].


As a reminder this draft already've taken the following route:

- presented in REGEXT by IETF 96 (2016)
- presented in REGEXT by IETF 120 (2024) -> not in charter
  - mentioned in DNSOP in IETF 120 followed by mailing list mention [4] 
-> no particular reaction from the WG
- ART AD sponsored and unsponsored in 2024/25 with creation of own 
mailing list dconn
- a charter proposal for a dedicated WG with a minimum scope now in 
evaluation [5]


[1] https://mailarchive.ietf.org/arch/msg/dnsop/AE7iAonwWA4Ha2M0bIZ6s1HZH6o/
[2] 
https://datatracker.ietf.org/meeting/interim-2025-artarea-01/materials/slides-interim-2025-artarea-01-sessa-interim-2025-artarea-01-domain-connect-00.pdf

[3] https://youtu.be/JmpvoCXkXt0?feature=shared&t=924
[4] https://mailarchive.ietf.org/arch/msg/dnsop/r9dV-riRwZfmYJpbbk-0FZugc1U/
[5] https://datatracker.ietf.org/doc/charter-ietf-dconn/

Kind Regards,

Pawel



OpenPGP_0xABB62115F7BCDB04.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org