Good morning, Montréal! Third day of #IETF102 https://www.ietf.org/how/meetings/102/

For me, today, #DNS. DNSOP working group (QNAME minimisation on the standard track and many other things), DPRIVE WG (DNS #privacy, successor of RFC 7626, operators best practices draft, etc.

IETF 102 Montreal

IETF 102 Montreal, 14-20 July 2018

Two drafts at the #IESG (refuse ANY requests) five have finished working group last call (including the new terminology draft, and the underscored names registry) , two in working group last call, and much more being discussed. DNSOP is busy. #DNS #IETF102
On the slides, all the items are merged on the first line of the slide. "These are HTTP/2 slides, everything is done in parallel." #PowerPoint #IETF102
On the table: #DNS cookies (RFC 7873). Send back cookies to be able to get large answers, and have RRL disabled. May not play well with anycast, unless all the nodes take extra precautions. #IETF102
Proposed solution for #DNS cookies: more chocolate. No, one mandatory algorithm https://en.wikipedia.org/wiki/SipHash (I didn't know #SipHash before) #IETF102
SipHash - Wikipedia

"We should look at cookies with the perspective of the camel." It is hard to follow DNSOP if you weren't at the previous #IETF meetings.

#IETF102

Instead of #DNS cookies, why not simply moving to TCP? Long discussion (people feel strongly about cookies). #UDP #IETF102
Now, another hot topic: someting at the apex (of a zone). CNAME, ANAME, BNAME, whatever. (See the discussion yesterday about SRV for HTTP.) The problem is that users want it. #IETF102
At the hackathon, there was a test to see what happens when you put CNAME and DNAME together at the apex (BIND auth. server).
What breaks depend a lot on wether there is QNAME minimisation or not. Most of the time, the CNAME used alone masks the apex. With CNAME+DNAME, almost everything works (except PowerDNS in some cases).
#DNS #IETF102
BULK #DNS resource record : automatic generation of virtual records (got a lot of pushback at previous #IETF meetings, because of the load for the server). #IETF102
So the current draft is more modest, with a simpler language, but still requires additional processing by all the authoritative name servers, primary and secondaries. #DNS #IETF102
"Children cannot force parents to behave." (discussion about #DNSSEC security model, and the risk of a rogue parent). #DNS #IETF102

Meeting of the DPRIVE (#DNS privacy working group at #IETF102 https://datatracker.ietf.org/meeting/102/materials/agenda-102-dprive-03

Among the subjects: update RFC 7626 (description of the problem).

DNS padding (TLS does not hide the length of the data) policy currently not yet approved, still details discussed at the #IESG. #IETF102
Measurements of DNS-over-TLS with RIPE Atlas probes (yes, they can). 1.67 % of the servers replied with DNS-over-TLS. Be careful: many probes still have old TLS client code. #IETF102
RFC 7626 was published in august 2015, to document #DNS #privacy issues. Time for an update (7626-bis): best practices for server operators, DNS-over-HTTPS, experience gathered, etc. #IETF102
@bortzmeyer Chidren, no. But what about Austin Powers ? :-)