Skip to Content.
Sympa Menu

isn-discuss - Metadata DNS storage for Freenum/ISN

Subject: Discussion List for Freenum/ITAD Subscriber Number (ISN) Project

List archive

Metadata DNS storage for Freenum/ISN

Chronological Thread 
  • From: John Todd <>
  • To:
  • Subject: Metadata DNS storage for Freenum/ISN
  • Date: Mon, 8 Oct 2007 14:48:51 -0700

I have a question or two I'd like to pose to the list about storage of organization metadata in the DNS:

In creating the Freenum system, there is an underlying need to not only provide the linkage of users to NAPTR records, but (probably) also the ability for end-user stations or systems to understand non-pointer (non-NAPTR) information about the user and the organization (ITAD) to which the call is being placed or from which a call is received. There is also a need to search directory information for particular organization data, though searching is not ideal in the DNS-based method I describe below (though other methods (http, ldap?) are planned to be available, they are outside the scope of this discussion.)

In the existing zone, the test method in which metadata is stored for organizations is in a zone called "<itad>". These elements are mapped to X.400-like namespace turned into TXT records, like this:

; DNS Entry for ITAD 298 Bill Woodcock
; generated @ 2007-10-03T18:20:57.867979
$ORIGIN IN TXT "o=Packet Clearing House"
IN TXT "street=572 B Ruger Street, Box 29920"
IN TXT "street=The Presidio of San Francisco"
IN TXT "localityName=San Francisco"
IN TXT "stateOrProvince=CA"
IN TXT "postalCode=94129-0920"
IN TXT "friendlyCountryName=United States"

Currently, all of the metadata is returned in a single reply to a TXT query (i.e.: "dig TXT") This is a problem, since all that data has to fit into a single DNS UDP reply. This is very constraining, and quickly will run out of space as DNS replies can only typically be 1500 bytes long (and in some cases, replies over 512 bytes are rejected by some resolvers/firewalls.) As the size of the metadata list grows, it will soon be the case that it is impossible to fit all of the possibly useful identifiers into a single reply.

It would be a preference to keep this data centralized in the Freenum database instead of allowing it to be delegated to the end organizations. The reason for this is that it seems that the data here is fairly static, and is (mostly) also available via the IANA pages. To prevent inadvertent (or malicious) modification of data without an audit trail, it seems the best place to leave that data is with the "trusted" delegation authority. I'm interested in hearing any potential objections to this centralization for the "base" data (much like ARIN/RIPE/etc. already keep some core data about ASNs in a single repository.)

Here is my question:
Would it be more reasonable to create a slightly different layout for the metadata, such that it would appear like this in the zone:

; DNS Entry for ITAD 298 Bill Woodcock
; generated @ 2007-10-03T17:57:29.030819
o IN TXT "Packet Clearing House"
street IN TXT "572 B Ruger Street, Box 29920"
street IN TXT "The Presidio of San Francisco"
localityName IN TXT "San Francisco"
stateorprovince IN TXT "CA"
postalcode IN TXT "94129-0920"
friendlyCountryName IN TXT "United States"
email IN TXT

Is this a better method? In this manner, all that is necessary is to make a list of the X.400-style field names available on the site, and anyone who wished to write a parser for CDR data or screen-pop information could quickly do DNS lookups on this ITAD for the particular fieldtype of data they were collecting. This also reduces the maximum size of any one reply down to a single TXT record, which will reasonably fit into even a 512 byte reply for any forseeably embedded metadata.

Other question:

I've also been considering how this might apply to individual users, so that something like this might be suggested as a possible method for organizations to "publish" data about individual subscribers (note that this would be a suggestion for organizations who operate their own nameservers, and would not be published in the zone, nor would it be mandatory for any records):

; This zone file hypothetically lives on the DNS servers
; operated by the owner of ITAD 256. Note: SOA left off
; for brevity.
$ORIGIN NAPTR 100 10 "u" "E2U+sip" "!^\\+*([^\\*]*)!sip:\\!"
cn. IN TXT "John Todd"
title. IN TXT "Chief Bottle Washer"
tz. IN TXT "UTC-0800"

Would anyone find this useful if I wrote it up as a specification? What data would be useful in here? Would protocol specific data be interesting? (i.e.: IN TXT "Linksys SPA942")


Archive powered by MHonArc 2.6.16.

Top of Page