DnsProposal

Overview

As SeattleWireless grows we should decide on a standard DNS structure for our network infrastructure. SeattleWireless's segmentation from the global Internet allows us to choose our own TLD (Top Level Domain) independent of ICANN's and and others's offerings. Additionally we should fully exploit the use of DNS to provide ancillary host and network data. Specificaly, LOC, TXT, and HINFO and possibly WKS fields. LOC fields should be used to record the geographic information per node, and possibly per client. Required TXT fields should be maintined for NodeAdmin contact information such as name, email. Node hardware details can be stored in HINFO (Host INFOrmation), WKS (Well Known Services) could be used to list any unique services offered such as an Internet gateway.

An agreed naming standard does not prevent the creation of vanity domains. The naming standard should only be enforced for network infrastructure to assist in network troubleshooting (such as the reverse DNS provided by a traceroute) and to identify what node or neighborhood you, or someone connecting to you, is coming from.

Technical implementation of our DNS structure will be as simple as pointing to an already established client DNS server or secondarying the TLD zone from an established root servers. Its likely that many of the DNS servers will provide both root zone hosting and client serving.

Restrictions

We should ensure that our decisions don't interfere with the rest of the Internet in anyway. Also, some DNS servers like certain naming structures better than others; we should shoot for some level of reasonable interoperability. Given that our TLD should not be in ICANN and preferably AlterNIC's current list. We also might want to restrict at least the TLD and possibly even all subdomains to more than two letters so as not to interfere with a country code. The subdomain restriction is only an issue if people want to use a DNS search path and type in client-id.node-id.cx assuming it will resolve to a cx subdomain within our DNS structure rather than Christmas Island's TLD. All text in the a DNS name should be restricted to the following characters, [A-z,0-9,'-'], with the restriction that the first character must be in the set [A-z] (as in not a number or -). Contrary to some DNS records an underscore, '_', is not valid in some DNS servers.

Proposals

DNS name structure is potentially a very political issue. Proposals should be placed below with a signature so we know who's arguing for what. Also, make use of the comment area for suggestions or problems you see with a particular proposal, I'd suggest signing your comments too.

Proposal One

Abstract

Based on intial messages to the DEV list I've come up with the following example. This should provide a model similar to how we actually think about our network. The use of a TLD, Country Code and State/Province abreviation would allow for the eventual meshing of other comunity wireless projects. I've chosen cwn as the TLD to represent community wireless network. I've stayed away from free in an attempt to indicate the real purpose of the networks as an experiment in comunity building, not simply a free access medium. This proposal also makes the assumption of some type of unique node name, this could be either by name or number. The FQDN (fully qualified domain name) ends up being a little long but by using the full names for neighborhoods and city prevents the need to create meaningful and understandable abbreviations. But again, since this is only a needed for infrastructure the length should really be any issue.

If you would like to play with my proposal check out the Setup section of this proposal.

-RichardLotz

Examples

In the above cases wc indicates a "wireless client" while the n111 indicates node number 111 from our seattle wireless node map. Neighborhood could either be the official neighborhood or a community agreed one.

Setup

See the DnsClientSetup and DnsServerSetup pages.

Comments

I'm concerned about privacy -- can the wireless device user disable the automatic LOC record updates? There is also a comment (lower down) regarding the creation of other top-levels aside from "cwn" (such as "swn") which I don't agree with because it detracts from the elegance which undoubtedly inspired the original design of the DNS protocol.

I would also be willing to entertain the possibility of managing the DNS if Richard isn't interested.

-Randolf Richardson (rr@8x.ca), Vancouver, B.C., Canada

---

I can imagine dropping the country code or even shortening the city to a three letter airport code but this might exclude smaller networks based in rural towns. The neighborhood field might also cause a problem when scaling down to small cities that might not have a notion of neighborhoods. In that case the city could simply be repeated to indicate that it encompases the entire region.

The total FQDN could also be shortened for forward records by a proper DNS setup by allowing another TLD of swn to represent the seattle.wa.us.cwn in the above example. -RichardLotz

Some ideas:

• Use AirPortCodes for geographical relativity and radio information (ie: YVR24, YVR54 for "Vancouver, BC Area" on 2.4GHz and 5.4GHz respectively.

• NodeID and Neighboorhood could be summed into "IndependentNetworkName", ie: "bby-madison" meaning the Burnaby/Madison community network

• We'll need glue for other name spaces such as "nitrous.bby-madison.bcwireless.net"
• I'm more than willing to host several "root servers" (Internet and Wireless, although Wireless is a wee-bit in the future) for $cwn

- MatthewAsham

Regarding AirPortCodes These codes are actually a subset of Location Identifiers (also called City Codes in the airline world) There are also PseudoCityCodes which sometimes denote a particular building. An example is RKL, which once denoted the PanAm Rockleigh, NJ datacenter. The purpose of this code space is to help baggage routing as well as operations of airlines. I *think* some other transportation systems (busses maybe ?) might use it also. The official guide is at: http://www1.iata.org/codes/index.htm#

Unfortunately, the codes sometimes change. For example, Santorini Island, Greece (also known as Thira) once had the code SAN. But, there was baggage confusion with San Diego. So, Santorini's citycode was changed to JTR.

So, if we need identifiers that are guaranteed not to change, this isn't a good code to use.

The most stable identifier I can imagine is lat/long. But, that's pretty useless to normal people.

Question: What happens to the proposed DNS scheme if a ( location identifier / city name ) changes ?

- BobMeizlik

• Perhaps we could make nicknames for neighborhoods, i.e.: node111.udist.swn? And, since node numbers are unique within SWN, we could have node111.swn. Seems like people would appreciate having as short of names as possible.
• Could there be a master dns server for each neighborhood, served out of a node in that neighborhood? Would this be helpful?

- PeterAbrahamsen

• Nick names are very easy, I've already setup a node111.swn that is queriable from ns1.cat5fetish.net.
• Neighborhood DNS servers would be great but not necessary so long as the client system can communicate with a larger DNS server (this becomes and issue of network density or Internet access). Also, for a DNS server in a neighborhood or node they would not need to fully setup their system to secondary all the root domains, instead the server could simply forward all requests to one of the larger servers.
• I'll work on some BIND boot strap files for people that would like to set their systems up to secondary the zones from me.

-RichardLotz

As of 3/19/02, all of the dns servers seem to be up, but none of them resolve the example dns names. Furthermore, all of the zone files for the 'server setup' (zones), are 404, and have been this way for more than 6 months.

While I like this proposal, I think we need to do the following:

1. Information on how to add your node to the dns servers
2. Find someone who wants to be an active dns admin; Richard, do you have the time?

Thanks -EricJohanson

• I do once SpringBreak shows up (starts 3/21/02), the example DNS are just that, examples. The node111 example used to work except I renumbered it to node110 after the NodeMap number change (I've fixed it in the above example). I haven't heard from anyone regarding adding zones to the SeattleWireless namespace other than TomMarshall. His DNS is sitting on a 10/8 address and no one from the Ballard links have gotten back to me about setting up a tunnel that I can link my node (and hence DNS) into. If anyone is running some DNS server other than Bind4 let me know if you would like to do some work for me with converting my include and zone files from their current Bind4 version. -RichardLotz

  I have an idea: What about setting up webmin on the dns server; you could create webmin account for each node admin, so they can update the dns themselves. It would require some level of trust, as I don't know how secure webmin really is, but it sure would make it easy. One other idea would be to delegate sub zones out to other dns servers; but this requires each node to run a dns server... yuck... I would be happy to convert bind4 files into bind9. I had to do this once for around 30 domains; it's not a problem. If you send me the files, I'll update them. -EricJohanson

Another small idea that should be considered is community client registration. For instance, it would be nice to register my laptop to be evanslaptop.swn and have that resolve correctly no matter what node I was connected to at that time. Sure it's easy to do, but it should be considered as far as part of the proposal, and not something tacked on. Plus, this establishes the community feeling about the network. "Hey Bill, can you ssh to my machine and copy your mp3s off? Sure Eric! <Bill connects to ericslaptop.swn>" There is the whole thing about people wanting certain names, but with DNS we are all used to that. The level the clients would be registered would still need to be decided, but at community level seems most logical, ie. client.swn. Also, since we are treating the .swn and such and alias to namespaces within .cwn, evanslaptop.swn would also be evanslaptop.seattle.ca.us.cwn, so if we started to get into community bridging, it would also work. Another aspect is how address are handed out. Even without my client registration idea, the way DHCP servers serve IPs seems to be overlooked as far as the DNS. While I know that IP ranges are given to Node admins, some may not use it and just use the public unused mask. Plus, are the client ips within the current setup hardwired? ie, does wc23.n111.university-district.seattle.wa.us.cwn always point to the same IP? If not, how are the DHCP servers reporting the address changes to DNS? Plus, it could be seen as a feature to allow flexible hostnames and ip ranges, since it reduces the administrative time. This problem could be solved on the client side, but that seems to violate the idea of the DNS always working correctly. We may want to look into a simple DNS reporting system that the address serving nodes would run to fix this last leg. - EvanWebb

CategoryProposal