[TriLUG] OT: Router then Firewall
Tanner Lovelace
clubjuggler at gmail.com
Mon May 22 17:21:13 EDT 2006
On 5/22/06, Rick DeNatale <rick.denatale at gmail.com> wrote:
> Are you sure that they get this from whois? References? I'd expect
> that this would be done via nameserver-nameserver protocols.
Well, when I decide to change the information about my domain,
I go to my registrar (yes, I mistyped that), and change whois
information, which contains my name server information.
Now, whether the whois database is the source of the data
or whether or not there is a separate db which both whois
and the TLD nameservers get the data from is a separate
issue. I was under the impression that it came from whois
and that was the big deal when they went from a single
whois server (run by Network Solutions) to a distributed
database. In either case, the information ultimately comes
from the domain owner when they enter it into the whois
information through their registrar.
> 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.
I do know that, and had thought I had written that Versign runs the
main root name server but I see I did not. Apologies for being
unclear.
[...]
> 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.
As I said, the same server that answers for the root domain ALSO
answers for the major top level domains like .com, .org, and .net.
You completely glossed over that part of my explanation.
Yes, you are correct. There is no reason the ROOT nameserver
should change often. I completely agree. But, very often, for
.com, .org, and .net (and my example was TRILUG.ORG which
fits there), the root nameserver and the .org nameserver is the
same and would therefore come from the same server.
And yes, it does cache the TLD nameservers, but not when it
first comes up, which is what I was describing (I said "nothing
in the cache").
> 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
Ah, so apparently what has happened since the last time
I looked at this in detail is the data has been abstracted into
separate registries (ok, it's been a while) and both whois and
RRP (which stands for Registry-Registrar Protocol, btw, you don't
mention that) both provide views into the underlying databases.
So, I still maintain that I was correct in what I was trying to
describe, I just got the terminology wrong. (And, yet, I'll
still probably keep calling it the whois information, just because
that's what I'm used to calling it. :-P).
> Again, it wouldn't be a root nameserver but the TLD nameserver for the org TLD.
Again, reread my message where I said that for .com, .org, and .net
the nameserver is the same as the root nameserver.
> 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.
But, how does the "internet at large" get there? The .org nameserver
doesn't get it's information from your local nameserver. It gets it
from the registry information (what I was calling the whois information).
That's the first step. If it isn't setup correctly, you never get to an
authoritative nameserver. Only after you get to an authoritative nameserver
will this be valid.
> 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.
A more useful option in this discussion would be +trace, which will
show you the nameservers used at each stage in the process. For
instance
$ dig +trace www.trilug.org
; <<>> DiG 9.2.4 <<>> +trace www.trilug.org
;; global options: printcmd
. 63801 IN NS E.ROOT-SERVERS.NET.
. 63801 IN NS F.ROOT-SERVERS.NET.
. 63801 IN NS G.ROOT-SERVERS.NET.
. 63801 IN NS H.ROOT-SERVERS.NET.
. 63801 IN NS I.ROOT-SERVERS.NET.
. 63801 IN NS J.ROOT-SERVERS.NET.
. 63801 IN NS K.ROOT-SERVERS.NET.
. 63801 IN NS L.ROOT-SERVERS.NET.
. 63801 IN NS M.ROOT-SERVERS.NET.
. 63801 IN NS A.ROOT-SERVERS.NET.
. 63801 IN NS B.ROOT-SERVERS.NET.
. 63801 IN NS C.ROOT-SERVERS.NET.
. 63801 IN NS D.ROOT-SERVERS.NET.
;; Received 292 bytes from 127.0.0.1#53(127.0.0.1) in 2 ms
org. 172800 IN NS TLD5.ULTRADNS.INFO.
org. 172800 IN NS TLD6.ULTRADNS.CO.UK.
org. 172800 IN NS TLD1.ULTRADNS.NET.
org. 172800 IN NS TLD2.ULTRADNS.NET.
org. 172800 IN NS TLD3.ULTRADNS.org.
org. 172800 IN NS TLD4.ULTRADNS.org.
;; Received 290 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 50 ms
trilug.org. 86400 IN NS ns2.trilug.org.
trilug.org. 86400 IN NS ns.wayfarer.org.
;; Received 108 bytes from 192.100.59.11#53(TLD5.ULTRADNS.INFO) in 38 ms
www.trilug.org. 300 IN CNAME talon.trilug.org.
talon.trilug.org. 7200 IN A 64.244.27.142
trilug.org. 7200 IN NS ns2.trilug.org.
trilug.org. 7200 IN NS ns.wayfarer.org.
;; Received 128 bytes from 64.244.27.142#53(ns2.trilug.org) in 55 ms
This shows that I was wrong about the .org nameserver
being the same as the root nameserver. It also appears
that they have now been separated even for .com:
$ dig +trace www.linux.com
; <<>> DiG 9.2.4 <<>> +trace www.linux.com
;; global options: printcmd
. 63898 IN NS H.ROOT-SERVERS.NET.
. 63898 IN NS I.ROOT-SERVERS.NET.
. 63898 IN NS J.ROOT-SERVERS.NET.
. 63898 IN NS K.ROOT-SERVERS.NET.
. 63898 IN NS L.ROOT-SERVERS.NET.
. 63898 IN NS M.ROOT-SERVERS.NET.
. 63898 IN NS A.ROOT-SERVERS.NET.
. 63898 IN NS B.ROOT-SERVERS.NET.
. 63898 IN NS C.ROOT-SERVERS.NET.
. 63898 IN NS D.ROOT-SERVERS.NET.
. 63898 IN NS E.ROOT-SERVERS.NET.
. 63898 IN NS F.ROOT-SERVERS.NET.
. 63898 IN NS G.ROOT-SERVERS.NET.
;; Received 276 bytes from 127.0.0.1#53(127.0.0.1) in 2 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
;; Received 491 bytes from 128.63.2.53#53(H.ROOT-SERVERS.NET) in 57 ms
linux.com. 172800 IN NS ns1.ostg.com.
linux.com. 172800 IN NS ns1.vasoftware.com.
linux.com. 172800 IN NS ns2.ostg.com.
linux.com. 172800 IN NS ns2.vasoftware.com.
linux.com. 172800 IN NS ns3.vasoftware.com.
;; Received 217 bytes from 192.5.6.30#53(a.gtld-servers.net) in 58 ms
www.linux.com. 7200 IN A 66.35.250.177
linux.com. 7200 IN NS ns2.ostg.com.
linux.com. 7200 IN NS ns2.vasoftware.com.
linux.com. 7200 IN NS ns3.vasoftware.com.
linux.com. 7200 IN NS ns1.ostg.com.
linux.com. 7200 IN NS ns1.vasoftware.com.
;; Received 153 bytes from 66.35.250.10#53(ns1.ostg.com) in 78 ms
> As I said, the root nameservers don't use whois information, and I
> don't think the registry operators do either.
So, where do the registry operators get the data then?
You MUST enter nameservers into your domain information
so that HAS to be the original source for it. This is
the same information provided by whois.
> 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.
The nameserver will still cache the nameservers listed in the
authority section. Perhaps "take precedence" is too strong a
description. It will keep all the name servers in it's cache
until their TTL is expired no matter if it comes from the TLD
name server or the authority section.
> 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).
Yes, I mistyped registrar. A registrar, however, is just someone who
keeps your REGISTRY, so it's not that much of a stretch.
> 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>).
I hadn't realized they spun them off again. Sounds like "As the Registrars
Turn" if you ask me, though...
> 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.
Why would you think this? Answer this question then. What about
delegated subdomains? For instance, many university computer
science departments use cs.UNIVERSITY.EDU (i.e. cs.unc.edu)
and run their own nameservers. Based on your description above,
there would be absolutely no way for that to happen, because
subdomains are not in the TLD registries. But, because nameservers
naturally delegate it's simple for them to return a delegation to another
name server. In the same vein, the name server returned by the
TLD name server is also free to delegate to another nameserver.
That's how DNS works.
> 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, you are correct.
> 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.
Correct, but the same algorithm is used when slave servers
transfer from the master. If the SOA serial hasn't changed,
there's no reason to transfer the data over the network.
> 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.
Yes, but what if the slave isn't restarted/reloaded? The master
can signal the slave to reload immediately, using a Zone Change
Notification (also known as DNS NOTIFY). See RFC 1996 at
http://rfc1996.x42.com/.
> 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.
>From "DNS and Bind 4th ed" section 4.8.4
( http://www.unix.org.ua/orelly/networking_2ndEd/dns/ch04_08.htm )
----8<------snip-----8<-------
4.8.4. Multiple Master Servers
Are there other ways to make your slave name server's configuration
more robust? Yes -- you can specify up to 10 IP addresses of master
servers. In a BIND 4 configuration file, just add them after the first
IP address and before the backup filename. In a BIND 8 or 9
configuration file, add them after the first IP address and separate
them with semicolons:
masters { 192.249.249.3; 192.249.249.4; };
The slave will query the master server at each IP address in the order
listed until it gets a response. Through BIND 8.1.2, the slave would
always transfer the zone from the first master name server to respond
if that master had a higher serial number. The slave would try
successive master servers only if the previous master didn't respond.
>From BIND 8.2 on, however, the slave actually queries all of the
master name servers listed and transfers the zone from the one with
the highest serial number. If multiple master servers tie for the
highest serial number, the slave transfers the zone from the first of
those masters in the list.
The original intent of this feature was to allow you to list all the
IP addresses of the host running the primary master name server for
the zone if that host were multihomed. But since there is no check to
determine whether the contacted server is a primary master or a slave,
you can list the IP addresses of hosts running slave servers for the
zone if that makes sense for your setup. That way, if the first master
server is down or unreachable, your slave can transfer the zone from
another master name server.
-------8<------snip-----8<--------
>
> They contact the master on a schedule set by the refresh count.
Or when told to by a DNS NOTIFY message.
> > > What roles does the SOA play to
> > > persons other than the secondary?
>
> It designates the primary authoritative name server for the zone.
It also provides a contact for the domain (that's the part
after the nameserver where "@" is replaced by ".".
>
>
> Okay Aaron, how did I do?
I'll let Aaron answer that one. :-) But I'd say pretty good.
Cheers,
Tanner
--
Tanner Lovelace
clubjuggler at gmail dot com
http://wtl.wayfarer.org/
(fieldless) In fess two roundels in pale, a billet fesswise and an
increscent, all sable.
More information about the TriLUG
mailing list