[TriLUG] OT: Router then Firewall

Aaron S. Joyner aaron at joyner.ws
Fri May 26 03:13:34 EDT 2006


Tanner Lovelace wrote:

> On 5/20/06, Aaron S. Joyner <aaron at joyner.ws> wrote:
>
>> I'm really surprised no one else has picked up this thread and run with
>> it.  :)  Both Jon and Tanner had good answers, so I'll send them both a
>> T-shirt (let me know your size and color preference, privately if you
>> prefer).  I'll point out some common misconceptions from their answers,
>> and pose some additional thinking points.  Jon and Tanner, give it a day
>> or so before you respond, if you'd like to.  :)  If things aren't
>> completely fleshed out by Monday evening, I'll try to remember to hit
>> this thread again and tidy up the loose ends.
>
>
> Ok, so it's been 47 hours now, so I'll go ahead and respond. :-)
>
>> 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.  If I want to look up the name servers
>> for a domain, I should use host or dig (no, you really shouldn't use
>> nslookup, but it would work :) ).  If I want to look up who to contact
>> about that domain, I should use whois.  Well, I'd probably trust the
>
>
> 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, what happens when you, say, tell your web browser to go to
> http://www.trilug.org/?  First off, your computer has no idea what
> www.trilug.org should be.  So, it goes and asks the nameserver
> that it is configured to use.  This, among other things, is generally
> a caching server, but let's assume for the moment that www.trilug.org
> is not in the cache.  All caching nameservers are configured with a
> list of root name servers.  If it doesn't have a hostname in its cache,
> it first picks one of the root name servers in its list and asks them.
> Now, ideally, a root nameserver, or alternatively a name server that
> responds authoritatively for "." would look at the last part of the 
> hostname
> and say, "I don't know, but go ask the ORG nameserver at this IP
> address".  What generally happens in practice, though, is that most
> root nameservers are also nameserver for .com, .org, and .net too,
> so it will skip over the .org part and see trilug.org.  From here it 
> says,
> "I don't know, but go ask the TRILUG.ORG nameserver at these
> IP addresses."
>
> 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.
>
> Now, after being told where to go by the root nameserver and
> 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.  Note that these nameservers
> do not, in fact, have anything to do with those from the whois
> information that the root nameservers use.  These, however,
> take precedence over any earlier answers.  So, if you wanted
> to, you could turn the trilug.org nameserver provided by the root
> nameserver into a "delegating nameserver" just like the root
> nameservers,  That is, instead of providing an authoritative answer
> to query, it instead says, "I don't know, but go ask this nameserver
> over here" just as the previous nameservers did.
>
> Finally, since name server TTL (time to live) values should be
> at least, if not more, time than cname or A records TTLs, if a
> record times out, the caching nameserver should still have
> the nameserver record in its cache and can just go ask it
> directly without going through the root server again.
>
> So, this is why I mentioned the whois information in my previous answer.
>
>> email contact listed in the SOA more, but if I needed more traditional
>> contact methods, ala name, phone, address, whois provides that.  How
>> would I use host or dig to find out what the delegating entity believes
>> my name servers are, ie. instead of the whois command Jon suggested:
>> `whois trilug.org`?
>
>
> As I mentioned before, they are returned with any query in the
> "Authority Section" of the DNS response.  You could also query the
> NS values directly by doing "host -t ns trilug.org" or "dig ns 
> trilug.org".
>
>> 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.  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.  This is how, a couple of years ago, they started redirecting
> mistyped domain names that weren't registered to their own
> web page saying "buy this domain".  Instead of returning "unknown
> domain" to something like "unregistereddomainanme.com" they would
> return an A record for their web server.  This upset MANY people because
> it broke a LOT of assumptions, not the least of which was that an easy
> spam check is to see if the return address domain exists or not, and
> one of the main things to come out of that was an option in bind to
> delegate certain domains as "delegation only".  That is, bind, when
> it goes to a nameserver for a particular portion of a hostname, say "com"
> can be configured to only accept a delegation response (that is, a 
> response
> that's like the ones above, "I don't know but ask this nameserver over 
> there.").
>
>> 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.
>
>> 4) Neither of them mentioned if any updates would be required to
>> secondary servers?
>
>
> 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 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.
>
>> 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?
>> What do slaves use to determine who to pull the zone from?  How do they
>> decide to get a new copy of the zone?  What roles does the SOA play to
>> persons other than the secondary?
>
>
> Ok, so is it obvious that I'm answering each section sequentially,
> since I just answered that question. :-)
>
>> If a good answer comes along to all of these, I might feel compelled to
>> toss out another T-shirt.  If not, I'll be sure to eventually answer all
>> my own questions for the curious minded folks.  :)
>
>
> This has been an excellent series of questions.  I may have to
> come up with a few of my own on a different subject and see if
> we can get a few more people to answer. :-)  (Hint to people:
> if you're wrong, that's ok, the purpose is to get discussion going,
> not whether you're right or not.  If you don't know, just remember,
> even easy things have to be learned.)

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, the wonderful thing about mailing lists, and the 
Internet in general, is that the quickest way to get to the right 
answer, is for someone to post the wrong answer.  Generally there is a 
lot of latent knowledge on this mailing list, regardless of your topic 
there's someone here who knows it inside and out, or knows someone 
personally who does.  Posting a question is usually enough to get the 
right answer, but you can be sure if someone notices mis-information 
it's much more likely to get corrected.  :)  By all means, throw out 
your understanding of how something works, and at the least you'll be 
able to work through it and refine your understanding, and with in a few 
messages come up with roughly the right answer.  At the best, someone 
will simply provide a thorough and correct clarification, and you'll 
learn something along the way.  :)  Note: this is how I learned most of 
what I know, by reading and learning from mailing lists and reading RFCs 
to be able to answer other people's interesting problems.  The 
information is out there, and it doesn't just want to be free, it wants 
to be in your head.  :)

That's enough cliche's for one message,
Aaron S. Joyner



More information about the TriLUG mailing list