[TriLUG] OT: Router then Firewall

[Rick DeNatale]

On 5/26/06, Aaron S. Joyner <aaron at joyner.ws> wrote:
> Tanner Lovelace wrote:

> > Now, here is the question?  How does it know what IP addresses
> > to give for trilug.org.  If you know the address of a nameserver for
> > trilug.org you can query that to get it's list of nameservers, but
> > generally the root nameservers do *not* do that.  So, where do they
> > get the list of nameservers for any given domain?  The answer is
> > given by Aaron's mention above of "as a database maintained
> > by the registrars".  That's where the nameserver fields in whois
> > information goes.  If you change that information, Verisign, who
> > runs the root nameservers, updates the root nameservers with
> > that information from whois every 12 hours.

>
> Very spot on here.  While reading this message, my hair was standing on
> end a few times, in particular the assertion that verisign queries the
> whois databases to fill in the glue in the zone data was particularly
> alarming.  :)

But I still don't believe that that's what actually happens, or what
happens in general.  As I posted a few days ago, Verisign provides
registrars with a non-public API and code to implement it under a
contract, and under an non-disclosure clause.  The template for the
contract is available on the ICANN site.

Various registry operators have different interfaces to the registrars
authorized to register domains under their tld.  One of the ways this
probably varies is the whether or not, and how, the whois database is
used to maintain the dns registry.  Another variation is likely
whether the particular api is a push or a pull.

I haven't really dug into how whois servers work, but FWIWm the
wikipedia article on whois indicates that:

   1) They are logically associated with the top-level domain registry.
        So for .com Verisign actually maintains the whois database, but..

   2) There are two models of the whois server.  The thick model has the
        server storing all of the whois data directly. The thin model
has the server
        keeping track of which whois server has the real whois data for each
        second level domain, and forwarding whois requests to that server (which
        is probably run by a registrar).

Quoting from the wikipedia article on whois:

"Exact implementation of which records are stored varies between
domain name registries. Some top-level domains, including .com and
.net, operate a thin WHOIS, allowing the various domain registrars the
ability to maintain their own customers' data. Other registries,
including .org, operate a thick model."

Now, I suppose that, in effect, you could say that the overall job of
the API between the registry and the registrars is to keep both the
whois AND registry name server information in sync from the point of
view of clients, exactly how this is done is inside various black
boxes, using different implementations.

Since the whois protocol is so underspecified
http://www.rfc-editor.org/rfc/rfc3912.txt, I suspect that at least
some of those registry-registrar APIs are using a more structured
interface.

The current (RFC3912) whois protocol specification is basically this:
If you do whois johndoe.com, the whois client:

  1) Opens a tcp socket to a whois server
  2) Writes "johndoe.com" to the socket
  3) Reads the socket to get whatever the server knows about "johndoe.com"

There doesn't seem to be any RFC which specifies anything about what
data flows in step 3.

And by the way, according to Wikipedia at least, the "official" name
for domain names like trilug.org, or google.com, which are directly
below a top-level domain.  IS a "Second Level Domain", whereas a
domain any lower in the tree is a subdomain.

---

Rick DeNatale

IPMS/USA Region 12 Coordinator
http://ipmsr12.denhaven2.com/

Visit the Project Mercury Wiki Site
http://www.mercuryspacecraft.com/