greg@duke.cs.unlv.edu (Greg Wohletz) (08/10/90)
in the routine res_search is the following line of code:
if ((n == 0 || *--cp != '.') && (_res.options & RES_DEFNAMES))
If you examine the routine you will notice that n > 0 if there were
any .'s in the name passed to res_search. I believe the intent was to
only append the local domain name in the case where there was no . in
the name passed to res_search, but instead the behavior is to append
the local domain name whenever the name does not end with a . Hence
when I type ``ping jimi.cs.unlv.edu'' it causes queries like
jimi.cs.unlv.edu.cs.unlv.edu to be generated. This is greatly
increasing the number of queries on my network. I believe the line
should read:
if ((n == 0) && (_res.options & RES_DEFNAMES))
What do you think?
--Gregoberman@rogue.llnl.gov (08/10/90)
In article <1891@jimi.cs.unlv.edu>, greg@duke.cs.unlv.edu (Greg Wohletz) writes: > in the routine res_search is the following line of code: > > > if ((n == 0 || *--cp != '.') && (_res.options & RES_DEFNAMES)) > > > If you examine the routine you will notice that n > 0 if there were > any .'s in the name passed to res_search. I believe the intent was to > only append the local domain name in the case where there was no . in > the name passed to res_search, but instead the behavior is to append > the local domain name whenever the name does not end with a . Hence > when I type ``ping jimi.cs.unlv.edu'' it causes queries like > jimi.cs.unlv.edu.cs.unlv.edu to be generated. This is greatly > increasing the number of queries on my network. I believe the line > should read: > > if ((n == 0) && (_res.options & RES_DEFNAMES)) This is "standard behaviour and is, to my understanding, correct. The normal operation is to add the default domain information if there is no trailing '.' and, if that fails, to try again without adding anything. This is important to cases where there are multiple levels of domain structure in an organization. I am icaen.llnl.gov. But we also have systems like abc.ocf.llnl.gov. Under the current mode the address abc.ocf is first tried as abc.ocf.llnl.gov. It does result in queries like abc.ocf.llnl.gov.llnl.gov, but these are resolved locally (within the authority of the local name servers), so are fairly cheap. If any '.' eliminated the use of the local domain, abc.ocf would simply fail. R. Kevin Oberman Lawrence Livermore National Laboratory Internet: oberman@icdc.llnl.gov (415) 422-6955 Disclaimer: Don't take this too seriously. I just like to improve my typing and probably don't really know anything useful about anything.
Craig_Everhart@TRANSARC.COM (08/10/90)
The code in question allows you to type ``foobar.ee'' from host ``jimi.cs.unlv.edu'' to contact ``foobar.ee.unlv.edu''. The extra queries (e.g.) (foobar.ee.cs.unlv.edu) are generally confined to the local network. I've taught myself to append a dot to fully-qualified domains in resolver-lookup contexts such as ping or telnet, but omit the trailing dot for mail addresses. The cost of the extra lookups seems small, given that they're local. Craig
kjd@MOLD.ZSO.DEC.COM (08/10/90)
>>in the routine res_search is the following line of code: >> >> >>if ((n == 0 || *--cp != '.') && (_res.options & RES_DEFNAMES)) >> >> >>If you examine the routine you will notice that n > 0 if there were >>any .'s in the name passed to res_search. I believe the intent was to >>only append the local domain name in the case where there was no . in I belive this is correct behavior. This is for the case where there are multiple sub-domains in the local domain. -Kevin Please note, BIND specific questions should be sent to bind@ucbarpa.Berkeley.EDU. not to namedroppers@nic.DDN.MIL. Send mail to bind-request@ucbarpa.berkeley.edu. to be added to the bind mailing list.
MAP@LCS.MIT.EDU (Michael A. Patton) (08/10/90)
Date: 10 Aug 90 05:28:52 GMT From: unsvax!jimi!duke.cs.unlv.edu!greg@uunet.uu.net (Greg Wohletz) ... the behavior is to append the local domain name whenever the name does not end with a . Hence when I type ``ping jimi.cs.unlv.edu'' it causes queries like jimi.cs.unlv.edu.cs.unlv.edu to be generated. This is the intended usage from the spec. Names that end in a dot are fully specified and not intended for local interpretation. Names without a dot at the end are potentially ambiguous. They are tried with the suffixes from the search list. Apparently your search list is ``cs.unlv.edu. .'' which is why it tries that long name first. The extra query should only happen once per resolver client. Once it caches that there is no listing under any ...edu.cs.unlv.edu then it won't ask about any other hosts that are local. You shouldn't be affected that much by these. If you want to avoid it completely, just specify the complete name (i.e. ``ping jimi.cs.unlv.edu.'') or configure your search list to include only ``.''. Your suggestion prevents a very useful ability to abbreviate names in adjacent domains.
greg@duke.cs.unlv.edu (Greg Wohletz) (08/14/90)
In article <1990Aug10.083545.1@rogue.llnl.gov>, oberman@rogue.llnl.gov writes: In article <1891@jimi.cs.unlv.edu>, greg@duke.cs.unlv.edu (Greg Wohletz) writes: |> > in the routine res_search is the following line of code: |> > |> > |> > if ((n == 0 || *--cp != '.') && (_res.options & RES_DEFNAMES)) |> > |> > |> > I believe the line should read: |> > |> > if ((n == 0) && (_res.options & RES_DEFNAMES)) |> |> This is "standard behaviour and is, to my understanding, correct. The normal |> operation is to add the default domain information if there is no trailing '.' |> and, if that fails, to try again without adding anything. This is important to |> cases where there are multiple levels of domain structure in an organization. |> Yes, I understand that having that behavior is usefull, but in that case should not the code read: in ((*--cp != '.') && (_res.options & RES_DEFNAMES)) The expresion: (n == 0) || (*--cp != '.') Doesn't seem to accomplish anything. --Greg