In July of 2018, I gave a talk about thoughts on the future work of the DNS-SD working group. You can watch the recording here starting at 02:13:25.

Here are the slides:

Well-known DNS Server Reputation Service

While preparing for a talk I gave at IETF 102 in Montréal, I had an idea about establishing a reputation service for sharing trust about well-known public DNS servers. Sort of a wisdom-of-the-crowds attempt for clients and operating systems to bootstrap trust when learning about new public DNS servers. Trust is local and trust doesn't scale as Leif Johansson and Lucy Lynch once told me. So this is an attempt at conveying trust or more likely conveying the lack of trust.

The talk related to DHCP, which wasn't well received, but it's not clear how well the reputation service part was received. HTTPS has a form of a reputation service for identifying compromised certificates called Online Certificate Status Protocol (OCSP).

While public DNS servers also have certificates that could benefit from OCSP, the DNS reputation service I was proposing was more about the anwers returned by the DNS resolvers. Ideally, DNSSEC would be more widespread and the answers returned by a resolver could all be validated by the client. But clients don't normally do DNSSEC validation. They trust the resolvers to do it for them when asked. So, are resolvers returning the correct results? We hope so but how do you catch them if they aren't.

Imagine if you attach to a network that is a bad actor. The network operator gives you DNS resolvers to use over DHCP but they intend to log your DNS traffic and sell access to it. The only ones who know about this are the buyer and the seller and neither have an interest in letting you know.

Now, what if they return invalid results? You are trusting your resolver to give you accurate results. The only way you can be sure though is to do DNSSEC validation at the client.

So imagine if there was a registry, say at dnsprivacy.org, where users could report a public DNS server. The service could list their security practices, audit logs, third-party verification, etc to allow users to decide which DNS servers they trust. If a bad actor is found to be abusing its resolver data, others would immediately know.

If this is something you would like to see happen, contact me!

Update

Marek Vavruša made a great point on the DNSOP mailing list here. The network operator should be involved in this reputation service by pushing the list of its servers that it considers trustworthy. Then the clients can evaluate these servers.

Configuring Private DNS via DHCP

At IETF 102 in Montréal, I presented some slides on DHCPv6 Private DNS Discovery at the DRIU BOF.

The talk was based on an Internet Draft that Willem Toorop and I worked on: DHCPv6 Options for private DNS Discovery. It provided a means to include an Authenticated Domain Name (ADN) for a nameserver to be used with DNS over TLS (DoT) or DNS over HTTPS (DoH).

To say that the talk was received poorly is an understatment...

Ted Lemon made a good argument that DHCP should only be used for boostrapping initial network parameters and not for full fledged configuration of all network parameters.

There was enough consensus that we feel that moving forward with this work would go against the wishes of the IETF community.

There still is a need for configuring the ADN in a trusted campus environment but a different proposal will need to be invented for this use case.

Overall, it was a good excercise and I hope that by documenting this here, it will discourage others from going down this path in the future.

Update

Ted Lemon's talk can be found here in the IETF Proceedings on YouTube at 33:18.

In July of 2016, I gave a talk to the IETF DNS-SD Working Group in Berlin with a status update of DNS Push Notifications.

Here are the slides:

In March of 2015, I gave a talk to the IETF DNS-SD Working Group in Dallas introducing DNS Push Notifications. This work was a joint effort between Stuart Cheshire and myself as a next generation follow on to LLQ.

Here are the slides:

In November of 2014, I gave a talk to the IETF DNS-SD Working Group in Honolulu explaining how Long Lived Queries (LLQ) work.

Here are the slides:

In June of 2014, I gave an invited talk to the Research & Education Track of NANOG 61 explaining what a Discovery Proxy was (Hybrid Proxy at the time) and how Long Lived Queries (LLQ) works. The link at the end of the slides http://hypd.info is no longer valid and should be changed to https://dnsdisco.com.

Here are the slides: