Good morning, London! Second day of #IETF115, with a lot of #DNS today.

Otherwise, it rains.

First big issue : the .ALT TLD. A TLD for non-#DNS resolution systems. Quite politically loaded... (ICANN, alternative roots, etc)

Proposal to move it to Working Group Last Call.

There are also funny technical issues such as "how do we sign a TLD which will not exist in the root zone?"


#DNS error reporting was tested at the hackathon two days ago. "What we learned: the food was amazing."

This technique allows a DNS resolver to report to the operatior of a domain, not to the client (like RFC 8914 does).

Now, caching of #DNS resolution failures. The Facebook breakage on october 2021 showed that many resolvers keep trying and overload the parent name servers. The goal is to be more specific that resolvers MUST cache resolution failures.

Proposal of a new EDNS option for the application to tell the local resolver/proxy how you want #DNS resolution to be performed("I want everything sent over DoH to eight*four")


Some people suggest an API instead.
We are in 2022, guys, we no longer use only C, how to design and specify an API for N programming languages?

@bortzmeyer You’re thinking of things like jsonschema for instance? There are a few standardizations that exist and is widely supported in many programming languages

@immae I don't see the relationship between an API and a schema langage for a format (like JSON).


@bortzmeyer openapi then? I’m not sure I get what you’re trying to specify here (I thought you wanted to specify a content standard - independently of the transport -, hence the jsonschema)

@immae The idea was to replace a network protocol (DNS) by an API, since, in that use case, client and server are on the same machine.
So a network "API" would not help.

Sign in to participate in the conversation
Mastodon is one server in the network