On 7 October 2020 from 15:00 to 16:30 (UTC+2), the DNS Working Group held a remote session via Zoom.
The first minutes of the session recording are missing due to a technical error.
1. Keeping up with the IETF DNSOP WG
Benno Overeinder
NLnet Labs
Shane Kerr asked Benno which parts of his current work at the IETF would affect the RIPE community the most.
Benno Overeinder answered that from a practical perspective it would be Qname Minimization, but mentioned that he didn’t believe that it will trigger a lot of operational issues.
He added that DPRIVE, ADD, DNS over TLS or DNS over HTTP will have implications for the RIPE community. Benno clarified that they are working on open source applications for DOT and DOH, so that there are enough options for operators when it’s time to deploy.
Shane asked when was the next IETF meeting due to take place.
Benno replied that the IETF meeting will take place in November 2020 but that the schedule is still unknown.
Peter Van Dijk mentioned that he submitted a requirement draft in DPRIVE that didn’t receive a lot of positive feedback. He suggested that there was more work needed on those drafts. He also mentioned that there was another draft submitted in DNSOP that was covering a lot of topics and stressed out that there were multiples overlaps between DPRIVE and DNSOP.
Benno thanked Peter for his comments and agreed that the IETF community had to look into this.
There were no further questions.
2. The SVCB and HTTPS RR
Ben Schwartz
Google
Daniel Stirnimann asked how long a client should wait to get a HTTPS response.
Ben Schwartz answered that all three requests will be done in parallel and that there should be no delay. However, he mentioned that if the client doesn’t do an Encrypted Client Hello, they will have to wait.
Shane asked if we could expect a rapid rollout.
Ben replied that this was possible, and they could get a lot of support (60-70%) for servers and browsers but that it will take longer to get beyond that.
Otto Moerbeek asked if it still made sense to send A and AAAA if HTTPS is required for Encrypted Client Hello.
Ben pointed out that the interesting problem here is that the client doesn’t know if the Encrypted Client Hello is deployed, therefore they will have to issue them both.
Allison Mankin asked if people have to keep running ANAME-like solutions for those clients that don’t have the new RR types available.
Ben mentioned that they were no clear answer at the moment. However, he added that supposing that 70% of clients are making these queries, the question for a CDN customer would be: do I need the ANAME type resolution for the remaining 30%? or can I solve it in another way (e.g. anycast)?
Job Snijders asked about the impact of this technology on Happy Eyeballs.
Ben clarified that Happy Eyeballs will continue to apply unmodified and that in this case you could start opening TCP sockets. He added that ideally the replies will arrive simultaneously but that this is an optimisation that allow you to cover this discrepancy.
There were no further questions.