Subject: Re: Finding server for Dynamic Update?

From: Ted Lemon <[email-masked]>
Date: Mon, 19 May 2003 20:50:19 -0500

What I did to solve this problem was to look up the SOA record.   Say 
you're trying to update gnorf.foo.example.com.   So you look for an SOA 
record on gnorf.foo.example.com., and if it's there, you send the 
update there.   If there's no SOA record there, you look for one on 
foo.example.com., and then example.com., and then com., and then '.'.   
(You can probably skip the last two...  :')

In any case, it's unlikely that a name server is going to accept an 
update without a signature, so you're going to have to put some 
configuration goo on the client anyway.   So why not include the IP 
address of the real primary for the zone?   Since the client is 
probably updating its home server wherever it is, this isn't a 
collection of data that's going to have to change with any frequency, 
so it's not as bad as requiring someone to, for example, type in the IP 
address of a DNS resolver.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: [email-masked]
Date: Tue, 20 May 2003 12:16:51 +1000

> Question:
> 
> To do a DNS Update, you need to know the DNS server to which the Update 
> packet should be sent.
> 
> My intended algorithm would simply be to find the parent zone name of the 
> name being updated (e.g. from the SOA record), and then look up the NS 
> records for that zone name, and then send the Update to one of those DNS 
> servers.

	That is how update is designed to work.  You send to the
	listed nameservers and it is their job to get it to the
	primary master.  The only optimisation the client is supposed
	to make is to use the SOA MNAME first if it is in the NS
	set.  This allows UPDATE to work through firewalls is a
	controlled manned.

	If a given server doesn't support UPDATE forwarding then
	NOTIMP should be returned (early named's got this wrong).

	We query for SOA and don't cache NXDOMAIN responses to SOA
	queries.  We also generate uncachable responses to SOA queries.
	This allows you to discover the zone without negative side effects. 

	Note with reverse lookups the client may want to re-write the
	ownername to deal with RFC 2317 style delegations.

> Unfortunately, some sites have Update enabled on only *one* server, and 
> that server is *not* listed in the NS records.

	This is a misconfiguration.
 
> One solution would be simply to make the end user manually configure the 
> name of the Update server, but I'd rather not put that additional 
> configuration burden on the end user.
> 
> The established DNS mechanism for locating an instance of some service
> is SRV records. Perhaps this offers a solution for discovering
> a domain's update servers? The problem here is that the SRV name 
> "_domain._udp.apple.com." doesn't make any distinction between the two
> different services "DNS Update" and "DNS Query". Both Update and Query
> use DNS protocol on port 53, but semantically they are quite different
> services.
> 
> The solution I have in mind is to use some other name, such as
> "_domainupdate._udp.apple.com." Even though the port number is usually
> still 53, this SRV record would denote a semantically different service.
> When a client looks up this SRV record, it is conveying that it is
> seeking the entity that handles DNS updates for that domain, not
> just any old DNS server that only handles queries.
> 
> An alternative naming, which reflects the status of "update" servers as
> a subset of all DNS servers, might be "_update._domain._udp.apple.com."
> This naming is logical, but it doesn't follow the strict
> "_application-protocol._transport-protocol." structure recommended in
> RFC 2782. Of course, the DNS server doesn't care whether the name
> follows the RFC 2782 convention -- the question is whether human
> operators think it is important.
> 
> It really doesn't matter what name we pick, as long as we can pick one 
> name and agree on it.
> 
> Comments?
> 
> Stuart Cheshire <[email-masked]>
>  * Wizard Without Portfolio, Apple Computer, Inc.
>  * www.stuartcheshire.org
> 
> 
> --
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]