[TriLUG] OT: Router then Firewall

[Rick DeNatale]

On 5/22/06, Tanner Lovelace <clubjuggler at gmail.com> wrote:
> On 5/20/06, Aaron S. Joyner <aaron at joyner.ws> wrote:

> > 1) whois is not used by DNS in any manner, what so ever.  It's used by
> > humans, as a database maintained by the registrars, of contact
> > information for a given domain. ...
> You are correct, mostly, except that I think you give too little import
> to your second point -- "as a database maintained by the registrars".
> To illustrate my point, I'd like to highlight just how DNS works.
...
> 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.

Are you sure that they get this from whois? References?  I'd expect
that this would be done via nameserver-nameserver protocols.

Also, Verisign does not run the root nameservers, they run some of
them (the A, and J root servers). The A server is at Dulles, VA. The J
server is distributed over 17 sites world-wide, four of which are at
Dulles.

The other root servers are run by ISI (B), Cogent Communications(C, at
4 sites), University of Md (D), NASA Ames (E), ISC (F, 37 sites), the
U.S. DOD (G), the US Army Research lab (H), Autonomica/NORDU net (I,
29 sites), Reseaux IP Europeens (K, 17 sites), ICANN (L), and the WIDE
project (M)

http://www.root-servers.org/

The root nameservers actually contain VERY little information, they
are used to find the top level domain servers for say com, net, edu,
us, ca, to etc.  Some of these are run by Verisign but by no means
all.  The root nameserver database is also VERY stable, it typically
sees a change rate of 10-100 changes PER YEAR. The Internet Assigned
Numbers Authority (IANA) is responsible for overseeing the root name
servers. ICANN sets the policies and manages IANA. Updating the root
nameserver database is done by a (deliberately) onerous process
involving e-mail and manual verification.
http://www.iana.org/root-management.htm

Your caching nameserver probably goes to a root nameserver VERY
infrequently, only when it doesn't have a valid cached entry for  a
top level domain like com, edu, or cz.  The TLD entries tend to have
quite long TTLs, so it's likely you won't hit a root server much
except for the rare country code tld.

Registrars for certain tlds (.aero, .biz, .com, .coop, .info, .museum,
.name, .net, .org, and .pro  called gTLDs or generic TLDs) are
accredited by ICANN which afaik, is the overall authority for these
top level domains.

The Registrar is the entity which domain name owners interface to,
there are many of these, godaddy, network solutions ...

ICANN delegates the operation of some of these TLD name servers. to
Verisign.  Verisign seems to run the tlds for com, and net, based on
the results of dig aero, dig biz, dig com, etc.

This begs the question of just how all various accredited registrars
pass the information needed to keep the top level domain servers up to
date.  A generic term for the interface seems to be a "registry
registrar interface".   The contracts between the tld name server
(registry) operator and a registrar spell out this interface.  For
example the contract between Verisign and a registrar for .com domains
is available for perusal at:
http://www.icann.org/tlds/agreements/verisign/registry-agmt-appf-com-16apr01.htm

It spells out that communication between the registrar and the
registry (Verisign) will be by RRP over a two-way ssl connection.  It
also licenses the RRP API and software to the registrar over the
course of the license.  It also prohibits the registrar from
sublicensing; publishing; decompiling, reverse-engineering; copying or
reengineering the RRP software or APIs. No open source here folks!

Other registries might and probably do use other protocols and
software. For example the .info registry promoted the extensible
provisioning protocol which it uses to talk to registrars.
http://www.afilias.info/faqs/for_registrars/protocol

> Now, after being told where to go by the root nameserver and

Again, it wouldn't be a root nameserver but the TLD nameserver for the org TLD.

> querying a trilug.org nameserver, in addition to returning
> a CNAME record (Canonical Name, or in other words, a nickname
> or alias) and an A record (Address record) for talon.trilug.org
> (where the www.trilug.org nickname points) in the "Answer section",
> it also returns an "Authority section".  In the authority section,
> it gives it's list of nameservers.

And it's the authority section in the answer to a dig query which is,
I beleive the real answer to Aarons quiz question about where to go to
find out what the internet at large thinks are the domain server(s)
for your domain.

By the way there is also a +nssearch option to dig which will show the
SOA record for each of the name servers in the authority section in
the answer to a query.

> Note that these nameservers
> do not, in fact, have anything to do with those from the whois
> information that the root nameservers use.

As I said, the root nameservers don't use whois information, and I
don't think the registry operators do either.

> These, however,
> take precedence over any earlier answers.

I'm not sure how you mean this, I'm pretty sure that earlier answers
"take precedence" as long as they haven't expired.  If an unexpired
entry is in the cache, a caching nameserver won't ask upstream.

...

> > 2) Neither Tanner nor Jon touched on who you actually need to contact to
> > update the information in the "whois" record.  There's a good buzzword
> > name for that company or entity, which I'm sure they both know, but
> > neglected to mention directly.
>
> As Ian mentioned, that would be your registry.

NO, as per all the above, it would be your REGISTRAR, which would be
someone like godaddy, network solutions, Joe's Crabshack and Domain
Sales, etc.  They act as your agent in interacting with the TLD
registry, and they are the only ones authorized to cause the registry
to update the pointers to your nameservers (or anything else in the
TLD nameserver).

> That used to be only
> Network Solutions but when the system was opened up for more
> registries they distributed the whois information.  Verisign (who bought
> Network Solutions), however, maintained control over the main root
> nameserver.

See the above, Network Solutions was, and is a Registrar. The root
nameservers which are actually "owned" by "volunteer" entities
distributed over the world. Verisign controls certain TLD name servers
delegated to it by ICANN and perhaps other authorities for ccTLDs.

By the way, Network Solutions was spun off by Verisign as a privately
held company in 2003.  I believe that they have the second largest
marketshare after GoDaddy. (Joes Crabshack and Domain Sales does less
well, but beats both in the cracked crab, and crabcake market <G>).

>
> > 3) Nobody touched on this fun and interesting angle: Can you do it with
> > out talking to that entity, and what interesting things happen if you
> > try?  (hint: this more often happens by accident)
>
> Yes.  As I mentioned above, the list of name servers returned by
> a nameserver doesn't have to match those in the root nameserver's
> list at all.  The ones in the root nameserver's list, however, do have to
> be running a nameserver and know where to send you (i.e. at least
> one need to be able to send you to a nameserver other than the root
> nameservers) or else your hostname won't resolve at all.

I think the answer is actually no.  If you are changing the address of
a nameserver for your domain, the only way to make this visible to the
outside world is to have the TLD for your domain updated, and the only
way to do that is through your registrar who will then cause the
registry to be updated via whatever protocol is specified in the
registrars agreement with the registry operator.

> > 4) Neither of them mentioned if any updates would be required to
> > secondary servers?

Well, I don't think that the masters clause in the zone statement
allows anything but an ip address, if so then the secondary(slave)
server needs to be reconfigured to point to the new master.

> Yes, that's one of the functions of the SOA field.  When you change
> the serial number of the SOA serial number field (which generally
> follows the convention of a date: YYYYMMDDNN, where NN is an
> ascending tag for each change made that day, but nothing at all
> says it has to follow that convention; you could just as easily just
> increment the value each time you changed a domain's information),
> a secondary nameserver compares the SOA serial number field
> with the one it has and if the one on the primary is greater than the
> one it has, it updates.

The serial number is more than just a control over slave name servers,
it's basically supposed to act as a kind of a monotonically inreasing
"hash" over the contents of a zone file.  It's a hash in the sense
that bind uses it as a first test to see if the file has changed.  If
the serial number hasn't changed and the info is already loaded, it's
assumed not to have changed so no further processing is done.


> The primary can also send the secondary a
> signal asking it to do the comparison right now so that a secondary
> isn't out of date until the SOA TTL expires.

If I'm correct that the ip address of the master needs to be updated
in the slave, then I'm pretty sure that bind will reload from the
(new) master when the slave is restarted/reloaded.

> > 5) Much attention was given to the SOA, the authoritative name server
> > mentioned in it, and it's TTL.  What role do each of these parts play?

The SOA record provides global information for a zone, one allowed per
zone file.

The name server in the SOA record is the primary name server which
will respond authoritatively for the zone.

The TTL is the number of seconds which a record may be cached.

There are also three additional timing values which are used by slaves.

refresh is the time interval, in seconds, at which a slave polls it's
master(s) for updated information.

retry is the time interval, in seconds, between attempts to contact a
master after a failure.

expiry is the number of seconds after losing contact with the master.

> > What do slaves use to determine who to pull the zone from?

The masters statement in the zone clause for the slave.  I have to
admit I'm not entirely clear on the meaning of multiple masters, I
guess that the slave will be happy if it can talk to one, but I could
be wrong here.

>> How do they
> > decide to get a new copy of the zone?

They contact the master on a schedule set by the refresh count.

> > What roles does the SOA play to
> > persons other than the secondary?

It designates the primary authoritative name server for the zone.


Okay Aaron, how did I do?
-- 
Rick DeNatale

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

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