DNS Update Proxy

I recently published a new internet-draft: DNS Update Proxy for mDNS that describes a way to do campus wide service discovery as an alternative to the Discovery Proxy and mDNS Discovery Relay.

The main difference is that instead of delegating subdomains for each IP subnet and translating unicast queries into multicast queries, it pre-populates the unicast authoritative DNS server with all the services it can discover using DNS Update from a proxy listening to multicast DNS.

This allows faster responses and support for DNSSEC with full NSEC next record semantics.

I'm looking for feedback and will also be working on code at the Hackathon @ IETF104 in Prague. Send me a note if you want to work on this MIT licensed code. No Rust knowledge necessary.

Here's a link to the code https://github.com/pusateri/rupdateproxy

DNS Authoritative server lease lifetimes

Tim Wattenberg and I recently published a new internet-draft: DNS TIMEOUT Resource Record that provides a mechanism for authoritative DNS servers to save a lifetime for other resource records in the same zone.

Lifetimes are sometimes associated with records based on the source of the record. DHCP based address assignments have a lease lifetime as well as DHCPv6 prefix delegation. Service Discovery DNS UPDATE registrations use an EDNS(0) Lease Lifetime Option to attach a lifetime to the services being registered.

If you have other uses for TIMEOUT resource records, let me know!

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.

The IETFers app has just been updated (v2.5) to include support for the new iPhone X and iOS 11! Send feedback inside the app in Settings.

Also includes Calendar bug fixes.

The IETFers iPhone/iPad app I wrote and maintain for the worldwide Internet Engineering Task Force (IETF) meetings is available for download in the Apple App Store.

If you have bug reports or feature requests, use the Settings panel and send me your wishes!

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: