All
Thanks for a productive IETF meeting. The draft minutes have been uploaded
(Thanks Paul H!) in the usual locations
https://datatracker.ietf.org/doc/minutes-118-dnsop/
https://github.com/ietf-wg-dnsop/wg-materials/blob/main/dnsop-ietf118/dnsop-ietf118-minutes.txt
Please take a minute to review to make sure if you are quoted that you are
quoted correctly, etc.
The chairs are working up a list of actions to take from the meeting that
we'll send out this week.
Tim
along with Benno and Suzanne
DNSOP WG
IETF 118, Prague
Chairs: Benno Overeinder, Suzanne Woolf, Tim Wicinski
Minutes taken by Paul Hoffman
Only stuff said that happened at the mic is reported here
Tuesday 2023-11-07 afternoon
Administrivia and updates of old work
https://datatracker.ietf.org/meeting/118/session/dnsop/
Lots of stuff on the chair slides
Hackathon Updates, Petr Špaček
See slides; there's lots there
Discussion of new DELEG RRtype
Also being discussed on DNS-OARC Mattermost server
Current Working Group Business
draft-ietf-dnsop-domain-verification-techniques, Shumon Huque
https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/
Daniel Kahn Gillmor: Glad that it is being coordinated with ACME
May be an attack where someone is giving you parts to splice
together
All need to be spliced as prefix, or suffix, not both
John Levine: Looks better since last time
We have a registry to use underscore tags
Thinks the PSL won't add flags or tags
The PSL is just a heuristic
Erik Nygren: Not needing anything new from the PSL
draft-ietf-dnsop-generalized-notify, Johan Stenstam
https://datatracker.ietf.org/doc/draft-ietf-dnsop-generalized-notify/
Erik: If you want it at the zone apex, don't use SVCB unless it uses an
underscore name
Petr: Might need extra parameters
Such as "talk to me over TLS"
JohnL: Needs a new RRtype to reduce the security issues instead of SVCB
Johan: This is for SIG(0), not shared secret
Jim Reid: Now at the implementation details
How will the client find out who the parent is?
Johan: There are algorithms for that
Already dealing with the problem in other contexts
Ben Schwartz: Doesn't think this draft needs to talk about transport
How does this deal with dynamic DNS
Johan: Wait for Friday
Peter Thomassen: Can determine in two queries if this is signed
Could parents use this to publish new records under the same
label
Ray Bellis: Go for a new RRtype
Maybe stick with SVCB format
For Consideration
draft-many-dnsop-dns-isolated-networks, Marc Blanchet
https://datatracker.ietf.org/doc/draft-many-dnsop-dns-isolated-networks/
BenS: Is someone doing that today?
Marc: Will be happening on the moon, no DNS
This has additional use cases
BenS: Wants real operational experience
Suggests that you don't do DNS in space
Ralf Weber: Where are the connections terminated?
Marc: Mostly local
Ralf: Cries for local infrastructure
Wes Hardaker: LocalRoot Project already does this type of stuff
Has done research with this
Will add link on the LocalRoot site
Friday 2023-11-10 morning
AD report on a document that got dropped from the WG
draft-ietf-dnsop-rfc5933-bis
Went to the ISE
Is that OK?
(No objection in the room)
For Consideration
draft-johani-dnsop-delegation-mgmt-via-ddns, Johan Stenstam
https://datatracker.ietf.org/doc/draft-johani-dnsop-delegation-mgmt-via-ddns/
Wes: Likes this
Key distribution, authorization, authentication are still a
problem
Johan: "smaller parents" already have a communication mechanism
Can just do it once with this key
Ed Lewis: REGEXT has the same example with EPP
Operators don't want dynamic update exposed to the public
Suzanne: Maybe have an interim
Current Working Group Business
draft-ietf-dnsop-rfc8109bis, Paul Hoffman
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/
draft-ietf-dnsop-rfc7958bis, Paul Hoffman
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7958bis/
Warren: Can we add another format for the XML file
Paul: That's up to the WG, IANA will respond
PeterT: Please be sure the hash is kept in the trust anchor file
Paul: It is still mandatory
draft-ietf-dnsop-compact-denial-of-existence, Shumon Huque
https://datatracker.ietf.org/doc/draft-ietf-dnsop-compact-denial-of-existence/
Ed: Explicitly not allowed to query for NSEC3, can do this here
This is complex to describe
Needs an applicability statement saying you don't need to do
this
Christian Elmerot: Cloudflare has made changes in deployment pipeline
Shumon: Do you treat metatypes special?
Christian: Yes
BenS: Doesn't understand the motivation
Any reasonable implementation would have a cache
This draft does not save any CPU time
Is it really worth it for response size?
Clarify the text
Christian: This does save CPU time at Cloudflare
Shumon: Also the packet size
Shane: We synthesize on the fly
draft-ietf-dnsop-svcb-dane, Ben Schwartz
https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-dane/
This is related to the new DELEG discussion
Benno: Almost ready for WG Last Call
For Consideration
draft-homburg-dnsop-igadp, Philip Homburg
https://datatracker.ietf.org/doc/draft-homburg-dnsop-igadp/
Ed: This sounds like lazy evaluation of zone transfer
How do you predict which parts to update?
Philip: Don't do anything special
Stefan Ubbink: Likes this idea, willing to help
PeterT: Sounds like a resolver with restricted capability
Philip: Using that word will be confusing, but is mostly
forwarding
Johan: Likes this
For large zones, will never use most parts of the zone
So, not IXFR, but instead for limited use
Petr: This is done in BIND for weird reasons today
Peter Koch: Like an authoritative with a long line to the database
Why document this protocol?
Maybe just document the operational aspect
draft-peltan-edns-presentation-format, Libor Peltan
https://datatracker.ietf.org/doc/draft-peltan-edns-presentation-format/
Paul: Explained why this was an individual document
Petr: Original purpose was to help interoperabilty testing
Good luck
Jim Reid: If you just want review, send to DNS Directorate
AD sponsored is a good path forward
Greg Choules: If there was a much better way to show this, it would
help folks understand DNS
draft-momoka-dnsop-3901bis, Momoka Yamamoto
https://datatracker.ietf.org/doc/draft-momoka-dnsop-3901bis/
Geoff Huston: Is a heretic in the church of IPv6
All about fragmentation
In IPv6, the likelihood of fragments getting lost is very high
The failure rate for large packets on IPv6 rockets
Timers in DNS software are longer than TCP timeouts
This says "I hate users"
This is irresponsible because we have measured that it will
hurt users
Strikes him as crazy
Erik Nygren: Thank you for doing this
Long overdue
Wes: Strong support for this
Geoff's concerns are valid but limited
Ralf: Supports
Did research about what parts of the DNS is not v6-ready
New networks are often faster for v6
Tobias Fiebig: Hears the arguments about MTU
Problem across all protocol families
Andrew Fregly: Has been looking at post-quantum signature sizes
Research should drive the development
Liaison with other WGs
draft-hollenbeck-regext-epp-delete-bcp, Scott Hollenbeck
https://datatracker.ietf.org/doc/draft-hollenbeck-regext-epp-delete-bcp/
Paul: New mailing list
We don't deal with dead things well
Ed: DNS does not recognize operator
Is not a protocol issue
PeterT: Get as close as possible to something that is consistent
Delete things that are dead
Warren: Doesn't know where it should live
Maybe another mailing list
This is an ongoing problem with lots of research
Work on this quickly
Scott: Active SSAC work on this
draft-ietf-core-dns-over-coap and draft-lenders-dns-cbor, Martine Lenders
https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/
https://datatracker.ietf.org/doc/draft-lenders-dns-cbor/
Ed: Is these devices doing their own DNS resolution or use a resolver
Uses a DoC server
That server can confirm the source
A DELEG record can help get from this DNS to that DNS, but will
be huge
BenS: Good to get a review here
A lot like defining a JSON representation for DNS
An interesting challenge
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
