On Mon, 18 Aug 2003, at 10:17am, [EMAIL PROTECTED] wrote: > That behavior doesn't necessarily make sense in the grand scheme of how > DNS resolvers work though, does it? DNS resolvers (ie the DDNS client) > should only use the DNS server(s) to which they are configured.
Nope. The DNS resolver -- the "DNS client" -- and the "DDNS update mechanism" are really two separate components. I will call the "DNS resolver" the "DNS client" because that usage is less confusing. The "DNS client" is the component of your system responsible for finding answers to DNS queries. If your web browser wants to know what IP address to connect to for <www.microsoft.com>, it uses the DNS client library to find out. On most platforms, Windows included, each host is configured with one or more "DNS servers". The DNS client contacts those nameservers to get answers to queries asked of it. Those DNS servers are variously called "full service resolvers", "recursive DNS servers", "caching DNS servers", or some variation on that theme. They accept queries from DNS clients, and give answers back. They obtain those answers by either (1) performing an iterative query, or (2) forwarding the query to something which eventually does an iterative query. When DDNS needs to be updated, the DDNS update mechanism looks up the SOA and/or NS records for the domain it wants to update. It does this lookup by using the DNS client, just like any other program. Once it has the DNS records it needs, it contacts an authoritative nameserver for the domain in question, and submits the update. The "recursive DNS servers" configured for the DNS client have no necessary relationship with the DDNS update mechanism. This is easy to see why when you consider that *ANY* DNS domain name is a candidate for a DDNS update. The fact that Active Directory uses DDNS to update records for the domain the local computer is in is a degenerate case. The DDNS update mechanism could just as easily submit an update for the <yahoo.com> domain. The only requirement is that the "recursive DNS servers" must be able to find the right nameservers for the domain you want to update. If you are running a DNS zone which is *not* delegated from the Internet DNS root server, then your recursive DNS servers must also be authoritative for the domain you are trying to update. Otherwise, they will not find your nameservers. I think an example is needed. Suppose your Active Directory domain name is <mycorp.com>. You register <mycorp.com> with Network Solutions. You configure two DNS servers as authoritative for that domain, and you configure them to accept DDNS updates from anywhere. (This is a huge security exposure, but we'll ignore security for this example.) You list those two nameservers with NetSol as the delegated servers for <mycorp.com>. Now, on your AD client, you can configure your "DNS servers" to be any working nameservers. They could be your ISP servers, for example. When your AD client wants to submit a DDNS update for <myclient.mycorp.com>, it does a lookup for the authoritative servers for <myclient.mycorp.com>. The DNS client on the AD client contacts the ISP nameservers. The ISP nameservers do an iterative query and find the registered nameservers for <mycorp.com>. The DDNS update mechanism then contacts those nameservers and submits the update. Alternatively, suppose you did NOT register <mycorp.com> with NetSol or anybody else. You just configure a couple of nameservers as authoritative for <mycorp.com>. Those nameservers will be unknown to your ISP's nameservers. So, you *have* to use your nameservers as your "recursive DNS servers" as well, since no other nameservers know about them. Does that make sense? This topic really begs for diagrams, and I'm having trouble transcribing it into ASCII text. :-) -- Ben Scott <[EMAIL PROTECTED]> | The opinions expressed in this message are those of the author and do | | not represent the views or policy of any other person or organization. | | All information is provided without warranty of any kind. | ------ You are subscribed as [EMAIL PROTECTED] Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=nt2000&text_mode=&lang=english To unsubscribe send a blank email to [EMAIL PROTECTED]
