Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!soleil!mlb.semi.harris.com!thrush.mlb.semi.harris.com!del
From: del@thrush.mlb.semi.harris.com (Don Lewis)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: A plea for care when faking top-level domains
Message-ID: <1990Jul31.004542.3940@mlb.semi.harris.com>
Date: 31 Jul 90 00:45:42 GMT
References: <1990Jul25.054936.25540@mel.dit.csiro.au> <1990Jul25.223636.22744@mlb.semi.harris.com> <7672@gollum.twg.com>
Sender: news@mlb.semi.harris.com
Distribution: inet
Organization: Harris Semiconductor, Melbourne FL
Lines: 56

In article <7672@gollum.twg.com> david@twg.com (David S. Herron) writes:
>So it's fair to summarize that BIND has a problem in that it
>returns the same answer to any questioner regardless of where
>that questioner is.
>
>There are many reasons why a site would like to return different
>answers depending on where the questioner is.  For instance:
>
>-- Giving out different lists of MX records for hosts on the LAN
>   than is given to hosts outside.  Normally MX records are orderd
>   as so:
>		IN MX 0 mail-box-host.dom.ain
>		IN MX 10 near-by-gate.dom.ain
>		IN MX 100 other-gate.dom.ain
>   And this happens to work.  But anybody sending mail to the interior
>   domain names will pass through at least one timeout, assuming they
>   aren't allowed to SMTP directly to mail-box-host.dom.ain.  This slows
>   down the world needlessly ...
>
>-- A different ordering of A records for multi homed hosts depending
>   on where the questioner is.

Actually, there are implementations of the resolver or the local
name server that do this already.

>
>-- Different ordering, or lists of, NS records.
>
>etc

Good summary, BTW.

Since name servers pass this information among themselves and some
name servers are configured to forward all requests through other
name servers, this tends to defeat any schemes that return different
information to different clients.  The ideal solution would be to
supply the client with sufficient information to make the proper
decision.  Something like a method of determining the "cost" to
communicate with the different IP addresses (cheap, expensive,
unreachable) would be about right, but it could be very nasty
to implement due to the presence of subnets and packet filtering
routers.

>
>As I recall there's a mandated syntax/grammar for nameserver information
>which doesn't allow this stuff to be described.  And that BIND is
>required to follow that grammar.
>
>Oh well..
>

Well, that's what standards buy you 8-(.
--
Don "Truck" Lewis                      Harris Semiconductor
Internet:  del@mlb.semi.harris.com     PO Box 883   MS 62A-028
Phone:     (407) 729-5205              Melbourne, FL  32901