about DNS mapping method

[Kevin Darcy]

cokenve wrote:

> Thor Kottelin wrote:
>
> > Bobo wrote:
> >
> > >  As known, DNS is also a database system.
> > >  Then if we think about DNS based on database
> > >  relation, don't you think PTR and A have the
> > >  same meaning? a relation on address-&-name.
> > >  (not address-to-name, or name-to-address). Is
> > >  there any reason or advantage that cause DNS
> > >  need the direction on its database relation?
> > >  If we can creat A and PTR record as the same
> > >  record. Then it is abviously that we can reduce
> > >  the size of DNS database.
> > >
> > >  Furthermore, in the DNS cache, you will find
> > >  that:
> > >  though the server has a PTR record in the cache,
> > >  such like
> > >  52.0.0.10.IN-ADDR.ARPA  IN  PTR   C.ISI.EDU
> > >  , when you query an A record for the domain name
> > >  C.ISI.EDU's, of course the server will have to
> > >  the nameserver who has the authority on the
> > >  domain "C.ISI.EDU". Why not using the PTR record
> > >  which already exists in the DNS cache?
> >
> > *One* reason is that whoever runs network 10 doesn't necessarily run th=
> e
> > ISI.EDU domain. Reverse lookups are often performed upon receiving a
> > client connection, but in order to provide any kind of security, a norm=
> al
> > "forward" query must also be done in order to make sure that the host n=
> ame
> > really points to the right IP address. Otherwise anyone could set up hi=
> s
> > reverse DNS to point to C.ISI.EDU, and then impersonate that host.
> >
> > Thor
> >
>
> I'm with Bobo in that DNS is not managed in same fashion as a distributed=
>  data
> base. Data base technology is robust, with many security enhancements, we=
> ll
> optimized for fast reply on queries.

DNS *is* a distributed database. Perhaps your definition of the term is
narrower than mine.

> My opinion is people that start to program DNS does not know data base
> technology and his methods.

That may be true, but so what? People who deal with DNS tend to be from a
networking and/or OS background, rather than a data processing background.
But this applies equally, I think, to those who *program* DNS, as to those
who *administer* DNS. So those who produce the software are on the same
wavelength as those who consume it. Is this a problem? I certainly doubt that
I'd want to use a DNS-substitute written by the DBAs or application
programmers in this place. It would probably have a bunch of arcane,
unnecessary data-integrity features, huge, convoluted schemas, cryptic config
files, and lousy performance, compared to the BIND to which I am accustomed.
Just give me something lean and mean, thanks; something for which I can
easily script tasks at an OS level.

> This explain the tremendous efforts to make a=
>  dns
> server run OK (several files to customize, etc).

With BIND it's, one config file and one file per zone. And I wouldn't call
adding/changing/deleting resource records "customization" -- that's just data
maintenance. So that leaves only one file to "customize"; named.conf.

> If we make a query for a name we obtain the IP address. This information =
> is
> cached in our name server so if we make a reverse query we must obtain th=
> e
> name cached in cache table.

What if a completely different organization controls the reverse name space,
and the reverse zone is served on a completely different set of servers?

What if you have a many-to-one name-to-address relationship, does it
automatically follow that the reverse record should have a one-to-many
relationship? Maybe that's desirable, maybe it isn't. DNS leaves that up to
the individual administrators to decide, instead of just lumping forward and
reverse mappings together. Options and alternatives are good, aren't they?

> This relation -name and addrees- is biyective=
>  and
> stable for at least at medium term.
> Thor says anyone can take our name and reply in the reverse query. Why?. =
> The
> firts fetching come from an authoritative name server. The reverse query =
> is
> replayed also from an authoritative name server and cached again.

See above. There might be different organizations handling forward versus
reverse. You won't necessarily be asking the same nameservers. The nameserver
you ask about the forward data might be completely ignorant of the reverse
data, or _vice_versa_.

> Both ca=
> che
> entries are the same, contain the same information and the same relation.=
>  Even
> more, NIC is the central authority for IP address.

Actually,  no. ICANN is technically the authority for all DNS, I guess, but
they have farmed out control of the *forward* namespaces to various
registrars, including Network Solutions, country-code registrars, etc.. The
*reverse* address space, however, falls under the jurisdiction of the various
RIRs (Regional Internet Registrars), like ARIN, RIPE, APNIC, etc., most of
which preceded ICANN. So the split between forward and reverse namespaces is
occurs at a very high administrative/political level.

> If someone want to mak=
> e
> abnormal things it will not be reachable from outside nor via address nor=
>  via
> name.
> I think Bobo suggestion does not let for  =BFnon consistences? in the dat=
> abase.
> The problem DNS manage is well managed by distribuited database in a bett=
> er
> fashion.
> There must be others reasons: the need for go into the mother of the worl=
> d
> requesting the same thing several times and producing unnecessary signali=
> ng
> traffic (as no user data but conversation of machines in a network).

I don't understand this last sentence. Do you think that every reverse query
needs to go to a central server or set of servers? Caching and referral apply
just as much to the reverse namespace as to the forward namespace. In fact,
that was one of the design goals of the in-addr.arpa structure; to allow the
same algorithms and implementations to map addresses to names as were already
in place to map names to addresses. I think it's actually worked out quite
well, although in hindsight it would have been nice if the designers had
figured out a way to delegate on non-octet boundaries, so that circumventions
like RFC 2317 wouldn't be necessary...


- Kevin