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

[Dave Piscitello <dave.piscitello@xxxxxxxxx>]

Sigh. At the risk of prolonging a discussion Mike seems to characterize as  
"here's a solution for an as yet undefined and unscoped problem"...

Again, I'm not opposed to what you want to do. And I absolutely don't want to 
live in a world where whois does this:-O

I do not understand why TXT records in the DNS protocol is the way to do it and 
no one has provided a compelling argument why the using the DNS protocol in a 
non-standard way is the preferred candidate. If the information is simply 
arbitrarily constructed ASCII, you could use other protocols. Maybe I'm too 
much of a protocol purist, but if I have a specific kind of resource I want to 
the DNS to return, then I think the correct way to design a protocol is to 
identify a new query and record type, not to say, "in this ICANN policy and 
context, we are using TXT records constructed in this fashion for this purpose".

Someone's got to write the DNS server code to populate TXT records in this 
specific way.
Is this all custom code? Do you want ISC, Nominum, NSD/Unbound, etc. to include 
this in libraries. Or is it your expectation that the DNS operators will custom 
code this because ICANN makes it a policy? Is any interoperability or 
compliance testing required of the DNS operator under an ICANN agreement?

I think Joe's question - does this information exist today and is there a way 
to deliver it?

I also have no real sense yet what "scale" you are talking about. The notion 
that every client PC is asking for TXT records from TLD name servers is, well, 
quite a large scale. If you are going to take this route for FF spam/email, 
what about the next thorny problem that exploits DNS? More TXT record requests 
from SIP Clients each to decide if the NAPTR records is suspicious?

I know, I know. I'm ranting a bit here.

But I agree with Mike that we ought to clearly describe the problem we are 
trying to solve.

On 7/12/08 8:19 PM, "Joe St Sauver" <joe@xxxxxxxxxxxxxxxxxx> 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 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