I think its safe to say I have a better than average understanding of DNS[1]
I don't necessarily agree with how the DDNS registration works, at least from my observations in the past. Unfortunately, I don't have a mechanism in which it is easily tested, so I'm not going to argue the point. As I mentioned, my experience has been that all dynamic updates seem to be processed through the resolving DNS server, rather than direct client to SOA. I do agree, however, that the DDNS update process is a different process than the DNS resolver process - in fact, and oddly at that, DDNS is handled by the DHCP Client Service under Win2k and later. We found that out the hard way, buy stopping that service on a number of statically IP'ed servers. Roger -------------------------------------------------------------- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. [1] My former boss referred to me as Iron Chef - DNS > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, August 18, 2003 5:34 PM > To: NT 2000 Discussions > Subject: RE: DNS Architecture Question > > > 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&tex t_mode=&lang=english To unsubscribe send a blank email to %%email.unsub%% ------ 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]
