ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [gnso-ff-pdp-may08] Information based solutions instead of policy based solutions

  • To: joe@xxxxxxxxxxxxxxxxxx
  • Subject: Re: [gnso-ff-pdp-may08] Information based solutions instead of policy based solutions
  • From: Marc Perkel <marc@xxxxxxxxxx>
  • Date: Sun, 13 Jul 2008 03:38:30 -0700

Joe - yes - you nailed it. That is exactly what I'm suggesting. I just don't know where all the information is so the details of how to actually implement it is better left to those who do. But - I'm glad you helped clarify it.

Joe St Sauver wrote:
Dave commented in response to Marc's suggestion...

#ICANN isn't the body that decides what the DNS protocol does and does #not do. ICANN does policy, not Internet architecture and protocol #definition. If I understand what Marc is asking for, what he wants would be a registrar policy thing (albeit a thing implemented via DNS) rather than something that would require a substantive IETF-ish protocol change.

I believe what Marc is suggesting is that currently:

-- a variety of information related to domains is public (as a matter
   of policy), BUT

-- that information is only exposed to public access *via whois* (or
   the limited zone file access programs) AND

-- whois does not support sustained programmatic query rates (most
   sites will ban or rate limit you if you hit their whois server
   at more than casual ad hoc query levels)

His point, as I understand it, is that we know of alternatives to
whois which CAN be used to scalably deliver access to useful already
nominally public information.

For instance, we can use DNS TXT resource records to return arbitrary information from specially constructed zones.

By way of example, even though this is not data which is itself
relevant to Marc's suggestion, the Oregon RouteViews project makes ASN data available for dotted quads via specially created TXT records
living in the asn.routeviews.org zone:

% dig +short TXT
"3582" "" "16"

The data shown for is the autonomous system number, and the encompassing prefix origin and length, for that IP address.

DNS doesn't "automatically know about" that data, but a zone can
(and has) been built that has what's needed, and no protocol
extension was needed to deliver the data -- good old DNS TXT records work fine.

I believe Marc's suggestion would be satisfied if "someone" -- ICANN,
Internic, registries, registrars, or even a private company -- were
to build similar special zones containing TXT records with information about the longevity and stability of some domain name characteristics.
True, Marc?

A more interesting question from my point of view is, "Does any
of this already exist, or if it doesn't exist, can it be created
without requiring the assistance or approval of ICANN or some
other entity?" In other words, is this a policy thing, or is it
just an operational execution thing?

For example, for at least modest numbers of ad hoc queries, I can
see when domains were created by checking Internic's domain
whois. To make this concrete, what if I check the domain byiueahei.com (as used by the name server ns3.byiueahei.com)?

>From whois, I can see that it was created on 25-jun-2008, so
now I know the longevity of that domain (albeit via a process that only scales to a small number of domains due to limitation
associated with whois process), and by extension, I also have an
upper bound on the age of the ns3.byiueahei.com name server.

If a list of name servers were to be extracted from zone files
each day, interested parties could use that data to maintain their own database reflecting the date they first saw any given name server appear across all domains.
Doing (or not doing) this would be a policy thing, not a protocol
thing. Because Internic knows about the name servers associated
with gTLD domains, it would not require any special registry
or registrar assistance or activity, just extraction and publication of a list of known nameservers from data that's already

But what of information about how often a name server has
*changed* its associated dotted quad? That's trickier, but not insoluble.

One could periodically test name servers of interest, obviously, or, if one had a data sharing arrangement with the operator of one or more
large recursive resolvers, passive DNS approaches could be used to
collect and synthesize the required data. For example, since 25-jun-2008, the RUS-CERT passive DNS server (see http://cert.uni-stuttgart.de/stats/dns-replication.php )
has seen ns3.byiueahei.com on eight different dotted quads:

ns3.byiueahei.com        A
ns3.byiueahei.com        A
ns3.byiueahei.com        A
ns3.byiueahei.com        A
ns3.byiueahei.com        A
ns3.byiueahei.com        A
ns3.byiueahei.com        A
ns3.byiueahei.com        A

One could imagine a synthesized DNS zone that might return "8" (the
number of dotted quads seen for that name server since it was created) in response to a suitable query for that name server's FQDN. Might their actually be other additional dotted quads that RUS-CERT doesn't
know about? Sure, but at least we'd have a good floor, and that
floor value might be high enough for folks to make the sort of
assessment that it sounded like Marc is urging be made.

Or if that's all too hard and folks just want something that's
already up and running, check out the Day Old Bread list, www.support-intelligence.com/dob/

DOB is a beta DNSRBL that contains domains registered within the last
five days. DOB is currently used as part of the SpamAssassin 3.2 tests (see DNS_FROM_DOB in http://spamassassin.apache.org/tests_3_2_x.html ).

Does any of that get at what you were thinking about, Marc?



Disclaimer: all opinions strictly my own

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy