It is often inconvenient for network administrators to deliver timely information about configuration changes for many sites, especially for open wifi networks and transient connections.
The MOTD protocol provides a very simple method of delivering local-network specific information to local users.
The MOTD protocol is also very simple. A robust implementation can be developed for a new platform in a matter of minutes; it has very few security implications (addressed later), and it can be deployed very easily.
Whenver the network connection changes, any interactive device should do a DNS lookup for _motd. There is no domain; no subdomain; just a simple DNS TXT request for this dotless domain name.
Clients should only do this to DNS servers received from a DHCP server. The client should not have to implement the MOTD protocol for static DNS servers in most cases, but there is no pressing reason not to.
If the user hasn't explicitly acknowledged the plain utf-8 encoded message, it should be displayed to the user.
Below is a sample implementation for Linux. It should be straightforward to adapt for other systems.
#!/bin/sh # Requires http://developer-next.gnome.org/libnotify/ txt="`host -t txt _motd.`" if echo "$txt" | grep ' descriptive text "' >/dev/null 2>&1; then notify-send -i stock_channel "`echo "$txt" | sed -e 's/"$//;s/.*"//'`" fi
This could be put in /etc/resolvconf/update.d/motd or in another location if more appropriate.
The DNS cache need only be modified to respond to the _motd. request.
This should be trivial for any network administrator.
Network administrators may intercept this request if appropriate. They shouldn't intercept other kinds of DNS requests. The dotless-nature of the domain makes it easy to match the packets in the firewall rules.
It is important that ad-hoc implementations be trivially implemented. An administrator may not have the priviledge of installing and configuring additional software.
Someone who can see DNS requests (but not DHCP requests) could detect machines joining the network. Using a DHCP option for the motd would eliminate this, but make implementation more complicated.
DNS responses may be easy to forge. A client should not (foolishly) display any MOTD response, but instead only when it specifically made the _motd request. It should use the regular DNS timeouts for when that time has passed.
The information might not be trustworthy; a client should avoid presenting this information in a fashion similar to other programs, or in a way that indicates it is trustworthy. The information should be treated with skepticism.
If you believe I have neglected something, send me an email and I will address it here.
All operating system vendors should implement the MOTD protocol.
Messages should be in the local language. Localization extensions would make implementation less straightforward.
Implementors should not extend it with a web-request, or a url. Web requests are slow and may have additional security implications that a simple DNS-based protocol might not.
Implementation should not treat the output as HTML.
Client should not implement MOTD over multicast DNS because of the potential for abuse at public hotspots.
If you can get an implementation onto your users desktop, please do so, and let me know and I'll link to you here.