BIND9.2.0a2 Source Code

Kevin Darcy kcd at daimlerchrysler.com
Thu Jul 26 21:56:59 UTC 2001


If you had a modified client talking to a modified server, then of course you could do
anything you wanted. But it wouldn't be interoperable with anything else in the DNS world
because the DNS standards don't support sending arbitrary data along with Resource Records.
You'd piss off a lot of people if the modified software were ever to accidentally try to
talk to unmodified DNS software on the Internet. You'd probably be better off using a
different protocol on a different port number -- call it "enhanced DNS" or "DNS plus",
which wouldn't have any potential to interfere with regular DNS.

A kludgey solution would be to make up an EDNS0 OPTION (see RFC 2671) and use that to
transport the metric information. But even that has interoperability problems -- AFAIK only
BIND 9 recognizes EDNS0. Also, there's no stock way within the standard resolver API to
retrieve EDNS0 information. If you decided to go this route, you should probably get an
official OPTION-number assignment from IANA so as not to conflict with any
"real" OPTIONs that may be implemented in the future. They may require that you write up an
Internet Draft specifying the format of the OPTION and how it is used, etc.

And don't forget the caching issues I mentioned earlier, i.e. if you piggyback this metric
information on regular DNS RR's, then you have to contend with the fact that regular
DNS RR's are usually cached for a while, which means the metric data might not be as
dynamic as you would wish. Perhaps this is an additional reason to develop a new protocol
instead, i.e. one that does not cache.


- Kevin

Vaishali Paithankar wrote:

> But I would not be able to return the additional information (metrics) to
> the client ?
>
> On Wed, 25 Jul 2001, Kevin Darcy wrote:
>
> >
> > Have you looked at the sdb mechanism in BIND 9 that allows you to use alternative
> > backends for your DNS data? I imagine you could also use it to store other stuff
> > alongside the DNS data, like metrics.
> >
> >
> > - Kevin
> >
> > Vaishali Paithankar wrote:
> >
> > > In fact, I wanted to do load balancing of the servers which are
> > > geographically distributed. In this case we need to have metrics which
> > > take into consideration the geographically distributed nature of the
> > > servers.
> > >
> > > Since, the DN System already has a distributed structure, this property of
> > > DN System can be used to make decision to choose the server.
> > >
> > > The DN Server would do the metric collection of e.g. RTT. This
> > > DN Server is assumed to be the nearest to the client to which
> > > the client has sent the query for I.P. address of the web site. So now,
> > > the client gets a good idea of the performance of all the servers
> > > depending upon client's geographical location .
> > >
> > > Instead of making changes in the zone files (RRs), is it possible to
> > > add/update the metrics in the memory where the zones are loaded (this was
> > > the reason to make changes in the source code) so that it not necessary to
> > > load the zones as and when we want to update the metrics ?
> > >
> > > Kevin and Brad, Thanks a lot for your advice/suggestions and for getting
> > > involved in the discussion.
> > >
> > > Vaishali
> > >
> > > On Thu, 19 Jul 2001, Kevin Darcy wrote:
> > >
> > > >
> > > > Vaishali Paithankar wrote:
> > > >
> > > > > Firstly, I am sorry for the repetative mails sent by me. This happened
> > > > > because my earlier mail to the list was bounced back. And I was trying
> > > > > to send it again.
> > > > >
> > > > > On Wed, 18 Jul 2001, Kevin Darcy wrote:
> > > > >
> > > > > >
> > > > > > This isn't just a BIND source code issue. You'd have to extend the protocol
> > > > > > so that the server would send this additional information in a form that the
> > > > > > clients would understand. And then you'd have to convince all of the server
> > > > > > and client implementors to adopt the protocol extension.
> > > > > >
> > > > > > Overall, you might be better off using a totally different protocol instead
> > > > > > of piggybacking on DNS. A Server Performance Metric Protocol or something
> > > > > > like that...
> > > > > >
> > > > > > About the best you can do _without_ protocol changes is to convince client
> > > > > > implementors to use SRV records, which send "preference" and
> > > > > > "weight" information to the clients so that they can make more intelligent
> > > > > > decisions about what server to use, and how to do failover. But SRV isn't
> > > > > > truly dynamic.
> > > > >
> > > > > To make it dynamic...
> > > > >
> > > > > How often a DNS loads its zones ?
> > > > >
> > > > > i.e. if we updated our SRV records frequently, DNS will also have to load
> > > > > its zones with the same frequency ?
> > > > >
> > > > > Or can't we load only SRV records or the information that has changed
> > > > > e.g. only the metrics in the SRV record ?
> > > >
> > > > With Dynamic Update, these questions become basically meaningless. The master
> > > > server gets the changes immediately. Now, how quickly the changes get out to all
> > > > of the slaves and to all of the caching servers in the world, is another question.
> > > > Most DNS-based load-balancer solutions "solve" this problem by using very small
> > > > TTL (time-to-live) values on their records. But that's an awful approach. It
> > > > wastes tons of nameserver resources and causes lookup latency. As Brad pointed
> > > > out, L4 load-balancing is a more technologically elegant approach, because from
> > > > the DNS perspective, the data stays constant. This fits DNS'es caching model
> > > > better.
> > > >
> > > >
> > > > - Kevin
> > > >
> > > > > If you want something dynamic, then you have to go to some
> > > > > > sort of load-balancing solution. If you look in the archives of this list for
> > > > > > the last few days, you'll see that we've been arguing about whether these
> > > > > > load-balancing solutions violate the DNS protocol and/or whether they are a
> > > > > > good idea or not.
> > > > > >
> > > > > >
> > > > > > - Kevin
> > > > > >
> > > >
> > > >
> > > > At 4:24 PM +0530 7/19/01, Vaishali Paithankar wrote:
> > > >
> > > >   i.e. if we updated our SRV records frequently, DNS will also have to
> > > > load
> > > > >  its zones with the same frequency ?
> > > >
> > > >         Yup.
> > > >
> > > > >  Or can't we load only SRV records or the information that has changed
> > > >   e.g. only the metrics in the SRV record ?
> > > >
> > > >          Nope.
> > > >
> > > >
> > > > >         This kind of thing does not belong in the DNS.  If you want to
> > > > do
> > > > load balancing, you should do it with mechanisms that do not involve
> > > > the DNS.
> > > >
> > > >         At the first level, you can put a Layer Four (L4) load-balancing
> > > > switch in front of the servers to be balanced, and the switch will
> > > > use any of several different methods (none of which depend on the
> > > > DNS) to determine which server is the "least loaded" and therefore
> > > > should be the one to handle a particular incoming connection.
> > > >
> > > >         See the archives of the load-balancing mailing list at
> > > > <http://www.vegan.net/lb/> for more information.
> > > >
> > > >
> > > >
> > > > > > Vaishali Paithankar wrote:
> > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > I have read about the concepts of DNS but am a new BIND user and
> > > > > > > just installed BIND9.2.0a2 on one of my Red Hat Linux 7 machines.
> > > > > > >
> > > > > > > I wish to try to incorporate some changes in BIND so that it returns
> > > > > > > metrics of Server (metrics like Server Load, RTT) with the I.P. Address of
> > > > > > > the Server.
> > > > > > >
> > > > > > > This is for the purpose of selection of "best" server by the Client.
> > > > > > >
> > > > > > > Which source code files should I go through / change to implement this ?
> > > > > > >
> > > > > > > Where can I find some help, documentation of structure of the source
> > > > > > > code of BIND ?
> > > > > > >
> > > > > > > Vaishali
> > > > > > > --
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > >
> > > >
> > > >
> > > >
> > >
> > > --
> >
> >
> >
> >
>
> --





More information about the bind-users mailing list