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

[Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>]

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 35.32.223.128.asn.routeviews.org TXT
"3582" "128.223.0.0" "16"

The data shown for 128.223.32.35 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
available.

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      58.218.202.189
ns3.byiueahei.com        A      59.63.41.98
ns3.byiueahei.com        A      60.172.219.21
ns3.byiueahei.com        A      61.162.229.152
ns3.byiueahei.com        A      61.162.229.180
ns3.byiueahei.com        A      124.236.241.91
ns3.byiueahei.com        A      221.230.2.221
ns3.byiueahei.com        A      222.186.12.77

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?

Regards,

Joe

Disclaimer: all opinions strictly my own