Minutes IETF104: dnsop
|The information below is for an old version of the document
Domain Name System Operations
||Minutes IETF104: dnsop
26 March 2019, 13:50-15:50 local time
Chairs: Tim Wicinski, Suzanne Woolf, Benno Overeinder
Minutes: Paul Hoffman
Text from slides not reproduced here
ANAME authors may be reducing scope of document
DNS-SD Document Updates; Stewart Chesire
Will take more things to the WG list, wants more review from DNSOP folks
IETF Hackathon: Everything DNS; Sara Dickinson
Paul: Encourages people to come because it helps you when you are doing code
Suzanne: Because the DNS lives in the real world, the hackathon is
draft-ietf-dnsop-multi-provider-dnssec; Pallavi Aras and Shumon Huque
Shumon: Not ready for WG last call because there is a bunch of pending
issues Jan Vcelak: Definitely looking for more input Shumon: Would like new
draft to be ready for next meeting Willem Toorop: What are the colors of
Blue is private key
John Reed: Is this intended for steady-state, or transitioning?
Shumon: Was for steady-state, but now moving to transitioning
John: Will this help get rid of 6761 and non-cooperating operators
Christian Grothoff: Have you thought about threshold signatures
Shumon: Will do
Tim: REGEXT is looking at registry handoff, also a side meeting on registry
lock Mike StJohns: What if different providers are signing different parts?
Shumon: Each provider is signing the whole zone
Pallavi: Each signer needs to do NSEC or NSEC3, but not different
Shumon: What about response size? Only changes DNSKEY records
Petr Špaček: Does this affect aggressive NSEC?
draft-ietf-dnsop-7706bis; Paul Hoffman
Wes Hardaker: Why is the root special?
Paul: Root is not special
Wes: Seems useful to do pre-caching for any zone.
Paul: Examples in Appendix showing how to do for other zones
Wes: Root Zone List not correct
Paul: Please send email
Andreas Schulze: Anyone can try and see if it works.
Paul: Should be for zone administrators who want this served this way.
Matt Pounsett: Listing non-ICANN or ICANN projects, side projects come and
go. Perhaps discuss these projects are ephemeral.
Paul: Off-boarding is really important for this.
Chairs: HyperLocal date?
Paul: I don't predict well
Paul: Knowing when a service stops working is really important
draft-ietf-dnsop-dns-tcp-requirements; Duane Wessels
Slides were originally for tcpm WG (TCP Maintenance)
Sara: There are also privacy concerns with TFO
Yes to promoting TLS
Do you want to talk about DSO? Will send text
Wes: 7706 code snippets
Petr: From flag day, operators said this was not Internet Standard
Suzanne: Chairs will follow up on that
Suzanne: Have people tested this?
Sara: DNS Privacy web site has some data on that for open source
draft-livingood-dnsop-dont-switch-resolvers; Jason Livingood
draft-livingood-dnsop-auth-dnssec-mistakes; Jason Livingood
George Michaelson: When the signalling mechanism is SERVFAIL, how do I know?
Have to have extended errors
Tim: Can they be combined into one?
Jim Reid: Supports
Validating resolvers that will soft-fail: needs wording
Matthijs Mekking: One document
Ralf Weber: Could be split into different sections
Warren Kumari: Who is the actual audience?
Jason: Lots of people outside the IETF read RFCs
Stéphane Bortzmeyer: Lots of people who talk to users read these documents
Tim: Audience is network operations people who aren't obsessed with DNS
like we are Matt Pounsett: Should work on it. Peter Koch: RFCs don't reach
the right audience
Paul: IETF Blog helps
Joe Abley: Old RFCs get use
Petr: Supports draft
Dan York: Likes these kind of drafts
We can point to RFCs
Tim: We can bring this to NANOG
Suz: Customer Support folks at operator shops care about these
Dan: You want a small number of best practices documents
Matthijs: Would prefer one document because they are intertwined
Benno: Go for one document, then call on mailing list
draft-lhotka-dnsop-iana-class-type-yang; Ladislav Lhotka and Petr Špaček
Andrew Sullivan: Has opinions on IANA registries
Do not get out of sync with IANA registry
You will run into things that are deprecated
Everything that is marked as "obsolete" is treated as "deprecated"
You don't have to care about these
Draft will be reviewed by YANG doctors
Wes: Did you consider RFC 6168?
Ladislav: This can be a difficult process
This is just types that can be used in other places
Wes: Think about TSIG keys