Agenda ADD@IETF123

Meeting Materials, Links
Materials, Charter, Documents
ADD WG General Info
ADD Chairs: David Lawrence, Glenn Deen
Area Director: Éric Vyncke

Administration [10 min]

• IETF NOTE WELL: Noted
• Scribe selection: Wes Hardaker
• Agenda bash: will talk about next steps for WG
• Welcome from chairs
• AD Comments

WG Doc - Handling Encrypted DNS Server Redirection 20m (Tommy Jensen)

• Encrypted DNS Server Redirection slides
• Since last time
  • implementation experience
  • self-redirection: suggestion to stop at where you reach the loop
    detected
  • any other thoughts on this or other issues?

Q&A

- Ben Schwartz: loops are a misconfiguration and we don't need to specify what to do.  A client shouldn't completely bail out and fail DNS queries, but the configuration is invalid.
    - Tommy: should we upgrade SHOULD NOT to MUST NOT for deploying loops?
    - Ben: I guess so
    - In the case of A -> B -> C -> B then the client should use one of A, B or C
    - loop detection should be by name instead of IP address
    - Tommy: but the draft currently does by address since names may resolve to different IPs under geolocation
- Jim Reed: I'm not sure it's a good idea to say let's not do loops.  People will do stupid things all the time anyway.  Clients need to take appropriate action.
    - Tommy: are you saying we should we shouldn't specify a number to detect?
    - Jim: we should simply say clients must detect loops without specifying further
- Florian Obser: Clients should be told not to do a lot of work
- Lars Eggert: I might abort this chain at any point because you made me wait too long.  If we stop at the loop detection, then everything would land on B which doesn't spread the load properly.  Agree with Ben that clients should pick A, B, or C
- Ben: self redirction is how we represent end-of-chain.  It just needs to be clear

AOB / Discussion (all)

Next steps for the working group - Eric (AD)

• Éric: We made a plan with the chairs that after the redirection
  draft

  • can we discover a ADD server from from DNSD or IPCP
  • so we should stay open for a year, as the draft is simple?
  • suggest the chairs contact the authors
  • and of course the WG will stay open until the current draft is
    published

• Glenn: separate work is being defined for how to do certificate
  provisioning for CPE devices

  • those drafts may become alive again

• Ben S: there has been a lot of discussion about rechartering DNSOP

  • there are some new drafts for proposal for DNSOP that will
    generate a lot of discussion
  • there is a fair chance that work may line up better with ADD
    than the DNSOP revised charter
  • ADD is center of expertise for stub to resolver communication

• Lars E: two new drafts are not urgent

  • CPE equestion may need a recharter discussion and it's not in
    scope currently
  • we can still close ADD and spin a new group instead
  • Glenn: note the drafts were already somewhat active in the group
    already
  • Eric: the new may be a new WG or BOF for the future for this

• Tommy J: the DNSSD draft and it creates a standard on text records
  with a registry, which looks like a duplication of 9461 so am not
  happy with the particular solution

  • the justification for a DNSSD is that options have limited space
    vs an arbitrary text record
  • note that options can be concatinated
  • Glenn: we probably should have this discussion on the list
    because the authors aren't here today

• Jim Reed: the new (not yet approved) DNSOP charter excludes DNSOP
  from doing work in related WGs

• Tommy Pauly: other mechanism for how to express encryption DNS
  configuration has happened in other places
  • other groups can still do this sort of thing
  • we should still work toward sunsetting here and let that other
    work happen elsewhere