relationship between .dir_colors settings and XTerm*color# settings
 

I am currently running the xfce window manager on top of RHEL5. I alternate between using Konsole and xterm as my terminals.

I have set my ~/.dir_colors file to customize the display of files and folders when I use the ls command. I have specified that .log files should be displayed in a light gray color. Everything appears as expected when I run "ls" in a Konsole.

If I run "ls" in an xterm, which I have configured to use a black background, .log files are invisible because for some reason they are being displayed with a black foreground, which of course is not visible on top of a black background.

After some trial and error, I found that if I add the following line to my ~/.Xdefaults file:

XTerm*color0: #BEBEBE

.log files correctly display as light gray in xterm when using the ls command, consistent with the behavior of ls in Konsole.

What is the relationship between the color codes used in the .dir_colors file and the XTerm*color# variables used in the .Xdefaults file?

Dircolors manipulates the values in the the dircolors database:
Or, if referenced as a file, it sets the shell environmental variable $LS_COLORS

.Xdefaults is an X server resource,

That's not quite what I'm asking. In my .dir_colors file, I have specified that .log files should appear as light gray. When I run "ls" in an xterm, the .log files are actually displayed in black text, which is invisible on a black background. If I add the following line to my ~/.Xdefaults file:

XTerm*color0: #BEBEBE

.log files correctly display as light gray in xterm when using the ls command.

How am I supposed to know which XTerm*color# variables correspond to which colors specified in the .dir_colors file?

I understand K, but I think you're probably doing this the hard way. Additionally I have no idea how much green you need to add to the blue to make gray, I can't see it and in truth, I'm color blind, so I'm hardly the guy to ask about that.
Let me explain what I think is happening. $LS_COLOR (via the Dircolors db) has a color it's trying to paint default files. Since we've never made a "log" file a special file group, for $LS_COLOR it's just a default or normal file (therefor color). Don't assume "black" means a lack of color, it doesn't, $LS_COLOR picked "black" from a lot of different values.
xdefaults, which appears to be deprecated (check your distro) is trying to paint it another color. It would be easier to do this if they'd stop arguing, wouldn't it?
Now you can disable .xdefaults attempts to paint the terminal, just remove the appropriate lines in the ~/.xdefaults directory, but you're not going to be able to stop $LS_COLOR from doing it's job, even if you empty the values in the hash table, there's a default color stored in the system, it'll just go with what it knows.
If you look at info coreutils 'dircolor' it will tell you that the $LS_COLOR local hash table (your ~/.dircolors file) is only going to be read it you put a little script that evaluates it in your ~/.bashrc directory. So do that.
The next step is to disable .xdefaults attempts to re-write what $LS_COLOR has already written and you should have total, fine grain control over every file type that interests you via the $LS_COLOR variable at the database level which will give you a stable, fully functional fix as long as $LS_COLOR remains in your disto.

The script from info coreutils 'dircolors'

You can run that script manually as well to reload the dircolors db and repopulate the $LS_COLOR variable so when you make changes it's easy to test.