Minutes IETF104: dnsop
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
"New work day"
draft-moura-dnsop-authoritative-recommendations; Giovane Moura
George: R2: Disagrees that the study is representative because uses RIPE
Atlas Wes: Asks whether we should bring to the WG, or remove some
recommendations Lars-Johan Liman: What status do you want?
Giovane: Informational, not BCP
Liman: Suggestions or things to think about; not recommendations
Customers will insist that "we much have this" and lose diversity
Giovane: Reproducing the recommendations
Liman: Not buying into that; needs to be observations
Wes: Will think about it
Stéphane: Thought it was good research
Concern that this is only for big authoritative servers, not even
medium-sized zone Wants title changed to make the scope narrow Giovane:
Peter van Dijk: Question about R5
Joe: Has read four of these papers
Really about anycast, not about DNS
Quite nuanced and subtle observations that are in context, but this
document makes broad claims Don't think it is sensible to expand the
papers Would prefer that this was a "literature review" These are too
broad and across the board
Peter Koch: 15 years ago, Lixia had a draft on TTLs
WG could not agree on this
Drop R5 from the document
Open to making papers more accessible, but not to be recommendations or
observations Wants more diversity of papers
Benno: Wants more discussion on mailing list
Paul: Why SipHash?
Ondřej Surý: Already used everywhere even though new
Peter Lexis: License is public domain
Benno: Will send out call for adoption, feels positive vibes
Warren: Make sure security groups and CFRG know
draft-stw-6761ext; Suzanne Woolf
Warren: Would be nice if we could avoid the .onion discussion again
Wants to work on this so we only do it once
Jim: Good to not use DNSOP in the review, but needs a review process
Expert review panel?
Would be good to have some visibility
Need to think about liason with ICANN
Worried about double-dipping or gaming of ICANN process
Doesn't want people coming to IETF to circumvent ICANN process
Paul Wouters: Froze 6761 with selectively allowing others
If we do not update 6761, we must move it to historic
Suzanne: Want the process to not look arbitrary
Christian Grothoff: Has proposal to overwrite root zone
Has done usabilty studies to show that this works
Wes: How to have input from ICANN is important
Note to chairs: don't let this drop, critical to solve
PeterK: Missing a recommendation: makes the name special, doesn't allocate
If you have a name, you can make it special
Doubts that DNSOP is the right venue, but doesn't have a better one
IETF and ICANN have tried hard to coordinate
Example of corp/home/mail
Stéphane: Doesn't solve the real problem
When people from outside to reserve TLDs
We can talk to ICANN
Draft doesn't solve the problem: it gives advice to people who already
know about it
Suzanne: "single label names" or not
Are people asking for the name to be delegated in the DNS with specific
behavior, or that the name be instantiated Distinct cases Other
approaches are welcome Warren will decide how to move forward
Warren: Would the WG please consider working on it?
draft-brotman-rdbd; Stephen Farrell and Alex Brotman
Brian Dickinson: Explicit declaration of non-mapping vs. missing
declaration of mapping
Defensive records saying that there are no other zones
Alexander Mayrhofer: How can this work without semantics?
There are other mechanisms, such as meta-tags
Stephen: Trying to not do semantics
Alexander: Makes this useless
Jim: Not sure the DNS is the place for this kind of semantics
How is this different than DNAME?
Joe: Thinks the cesspool is fine
The current mechanisms are terrible and inaccurate
What incentive does the domain name holder to have to publish these?
Alex: When people want to look legitimate
Matt: Hard time seeing use cases
Boils down to interpretation by anti-abuse researchers
What will the absence of records mean? Could be messy
John Reed: Which direction should it be?
Lists can get real big real fast
How to make sure it's gone on both ends when the relationship ends
Murray Kucherawy: Need to address unidirectional cases may be attacks
First party sets proposals
Signing is crazy
Warren: Not sure if it should be in the DNS
Would like to disavow: more useful
Dan York: Thanks for bringing it here
Have you spoken other vendors who might implement this?
What prevents less ethical people from claiming
Murray: Has application in DBOUND
ANAME discussion; Matthijs Mekking
Wants discussion to be about current draft, or maybe a reduced scope
Willem: Likes current draft, wants to implement it
Brian: Issues that authoritatives must act in a way that resolvers used to
Won't scale, is an existential threat to authoritative servers
Interferes with geo-ip that they have implemented
Recursives scale by queries, authoritatives scale by zone
Changes business model in a bad way
Matthijs: New document would need to deal with authoritative aspects
Similar to DNSSEC for geoip
Shane Kerr: People have implemented things just like this, it scales
Matt: This sort of thing does work
Had to do ramp-up and back-off strategies
Did simulations up to 10m zones
Petr: Two documents: how to do zone transfer, rest
Allow people to use multiple providers
Olli Vannoja: Doesn't think it breaks DNSSEC
Brian: Being offered by vertical integration suppliers, not authoritatives
Benno: Easier for two documents, but wants to hear more on the list
Tim: Brian is incorrect
One document is OK
This scales, everybody does it
Tony Finch: Would like more comments on the list from people who are
already do this