On 5/22/06, Rick DeNatale <[EMAIL PROTECTED]> 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. -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
