Questions[resolution](server)

I just recently installed ESXI on a server for some basic tasks, but now I'm having a problem with my windows VM.

The thing is, the bottom and the right-hand side of the screen go beyond what the VSphere Client is showing me (This happens with an external console as well as the tabbed one)

Here is what I mean:

• "New Window" console:

  

• "Tabbed" console

  

I haven't been able to find ANYTHING pertaining to this on here or on google. What I tried so far, however:

• Restart the server VM
• Restart ESXI
• Restart my Computer
• Go to View -> fiddle with the auto-fit settings (no change at all)
• Change the VM's resolution (Migitated the problem somewhat, as I can see more window content, but there is still a lot missing at 1024x786, which is the smallest it willl go)
• Change my resolution
• Unplug my extra screens (I have 3 including my laptop)

The used ESXI Server is Version 6.0.0, I am on Windows 10.

Any ideas?

I'm having some DNS issues on a new box I'm installing with CentOS 6.2.

I am able to look up names using nslookup, dig, or host. I am able to ping machines by name or by IP address. However, when I try other tools, such as ssh, wget, or yum, they are unable to resolve names. For example:

# wget http://www.google.com
--2012-03-08 14:48:06--  http://www.google.com/
Resolving www.google.com... failed: Name or service not known.
wget: unable to resolve host address `www.google.com'
# ssh www.google.com
ssh: Could not resolve hostname www.google.com: Name or service not known
# ping -c 1 www.google.com
PING www.l.google.com (74.125.113.106) 56(84) bytes of data.
64 bytes from vw-in-f106.1e100.net (74.125.113.106): icmp_seq=1 ttl=46 time=43.6 ms

--- www.l.google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 59ms
rtt min/avg/max/mdev = 43.665/43.665/43.665/0.000 ms
# host www.google.com
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 74.125.113.99
www.l.google.com has address 74.125.113.103
www.l.google.com has address 74.125.113.104
www.l.google.com has address 74.125.113.105
www.l.google.com has address 74.125.113.106
www.l.google.com has address 74.125.113.147

My /etc/nsswitch.conf file is the default, including this (standard) line:

hosts:      files dns

/etc/resolv.conf is as set up by DHCP:

; generated by /sbin/dhclient-script
nameserver 192.168.1.254

192.168.1.254 is a working DNS server (my DSL modem, working for years with other machines)

Anyone know why ping would work, but ssh/wget would fail?

Per NcA's suggestion, I tried changing /etc/resolv.conf to point to 8.8.8.8. Oddly enough, this does make it work. Obviously, my DSL modem is responding to DNS requests in some way that some parts of Linux's resolution system don't like. Looking at the tcpdump, I am unable to see what the difference is. Certainly, both servers are sending the same addresses.

Here's the output from tcpdump -nn -X with the server set to the DNS server on the DSL modem. It's clearly replying with the correct addresses, but ssh/wget don't seem happy with it for some reason:

15:53:52.133580 IP 192.168.1.254.53 > 192.168.1.2.54836: 33157 7/0/0 CNAME www.l.google.com., A 74.125.115.105, A 74.125.115.106, A 74.125.115.147, A 74.125.115.99, A 74.125.115.103, A 74.125.115.104 (148)
        0x0000:  4500 00b0 e33a 0000 ff11 53b1 c0a8 01fe  E....:....S.....
        0x0010:  c0a8 0102 0035 d634 009c 7528 8185 8180  .....5.4..u(....
        0x0020:  0001 0007 0000 0000 0377 7777 0667 6f6f  .........www.goo
        0x0030:  676c 6503 636f 6d00 0001 0001 c00c 0005  gle.com.........
        0x0040:  0001 0007 acd0 0008 0377 7777 016c c010  .........www.l..
        0x0050:  c02c 0001 0001 0000 0001 0004 4a7d 7369  .,..........J}si
        0x0060:  c02c 0001 0001 0000 0001 0004 4a7d 736a  .,..........J}sj
        0x0070:  c02c 0001 0001 0000 0001 0004 4a7d 7393  .,..........J}s.
        0x0080:  c02c 0001 0001 0000 0001 0004 4a7d 7363  .,..........J}sc
        0x0090:  c02c 0001 0001 0000 0001 0004 4a7d 7367  .,..........J}sg
        0x00a0:  c02c 0001 0001 0000 0001 0004 4a7d 7368  .,..........J}sh
15:53:52.135669 IP 192.168.1.254.53 > 192.168.1.2.54836: 65062- 0/0/0 (32)
        0x0000:  4500 003c e33b 0000 ff11 5424 c0a8 01fe  E..<.;....T$....
        0x0010:  c0a8 0102 0035 d634 0028 98f9 fe26 8000  .....5.4.(...&..
        0x0020:  0001 0000 0000 0000 0377 7777 0667 6f6f  .........www.goo
        0x0030:  676c 6503 636f 6d00 001c 0001            gle.com.....

I'm not enough of an expert to know if this is malformed in some way, but ping seems to do the right thing with it.

For comparison, here's the same thing when querying 8.8.8.8:

15:57:27.990270 IP 8.8.8.8.53 > 192.168.1.2.49028: 59114 7/0/0 CNAME www.l.google.com., A 74.125.113.105, A 74.125.113.103, A 74.125.113.106, A 74.125.113.147, A 74.125.113.104, A 74.125.113.99 (148)
        0x0000:  4500 00b0 5530 0000 2f11 6453 0808 0808  E...U0../.dS....
        0x0010:  c0a8 0102 0035 bf84 009c 39f8 e6ea 8180  .....5....9.....
        0x0020:  0001 0007 0000 0000 0377 7777 0667 6f6f  .........www.goo
        0x0030:  676c 6503 636f 6d00 0001 0001 c00c 0005  gle.com.........
        0x0040:  0001 0001 516a 0008 0377 7777 016c c010  ....Qj...www.l..
        0x0050:  c02c 0001 0001 0000 0116 0004 4a7d 7169  .,..........J}qi
        0x0060:  c02c 0001 0001 0000 0116 0004 4a7d 7167  .,..........J}qg
        0x0070:  c02c 0001 0001 0000 0116 0004 4a7d 716a  .,..........J}qj
        0x0080:  c02c 0001 0001 0000 0116 0004 4a7d 7193  .,..........J}q.
        0x0090:  c02c 0001 0001 0000 0116 0004 4a7d 7168  .,..........J}qh
        0x00a0:  c02c 0001 0001 0000 0116 0004 4a7d 7163  .,..........J}qc
15:57:28.018909 IP 8.8.8.8.53 > 192.168.1.2.49028: 31984 1/1/0 CNAME www.l.google.com. (102)
        0x0000:  4500 0082 7b1b 0000 2f11 3e96 0808 0808  E...{.../.>.....
        0x0010:  c0a8 0102 0035 bf84 006e c67e 7cf0 8180  .....5...n.~|...
        0x0020:  0001 0001 0001 0000 0377 7777 0667 6f6f  .........www.goo
        0x0030:  676c 6503 636f 6d00 001c 0001 c00c 0005  gle.com.........
        0x0040:  0001 0001 517f 0008 0377 7777 016c c010  ....Q....www.l..
        0x0050:  c030 0006 0001 0000 0258 0026 036e 7334  .0.......X.&.ns4
        0x0060:  c010 0964 6e73 2d61 646d 696e c010 0016  ...dns-admin....
        0x0070:  91f3 0000 0384 0000 0384 0000 0708 0000  ................
        0x0080:  003c                                     .<

I still don't know why the server's reply is adequate for ping but not for ssh/wget.

If anyone has ideas, I'd be happy to hear them. For now, though, I can either refer to an outside DNS server or set up my own server on the new box. It's a workaround that seems like it should be unnecessary, but will allow me to proceed.

Is it possible on the client side to setup the client.conf file to resolve a particular host/domain to a given IP.

For instance, domain.tld resolve usually from the Internet NS to 1.2.3.4

host domain.tld => 1.2.3.4

I would like to force domain.tld to resolve to 10.11.12.13 when using openvpn client.conf

openvpn client.conf
host domain.tld => 10.11.12.13

Doing a lookup for my domain on http://www.intodns.com/ I noticed theese two messages:

In Parent section:

DNS Parent sent Glue The parent nameserver g.gtld-servers.net is not sending out GLUE for every nameservers listed, meaning he is sending out your nameservers host names without sending the A records of those nameservers. It's ok but you have to know that this will require an extra A lookup that can delay a little the connections to your site. This happens a lot if you have nameservers on different TLD (domain.com for example with nameserver ns.domain.org.)

and in NS section:

Glue for NS records INFO: GLUE was not sent when I asked your nameservers for your NS records.This is ok but you should know that in this case an extra A record lookup is required in order to get the IPs of your NS records. The nameservers without glue are: 109.230.225.96 84.201.40.52 You can fix this for example by adding A records to your nameservers for the zones listed above.

I do perfectly understand that the primary objective of glue records is to resolve circular dependencies.

The classic use case:

my domain is example.com and I want to have the nameserver ns1.example.com. This will never work because i cannot know the ip of ns1.example.com if I don't fetch example.com and in order to do that I need to fetch it from ns1.example.com. To resolve this deadlock I add a glue record to ns1.example.com containing the ip adress of the nameserver, so this can work out.

So this problem does not occour if the nameservers are in a different TLD than the domain i want to look up. But however to fetch the zone information from the nameservers I need to know their ip adress right? And in order to know that i need to fetch the zone the nameservers are in from their respective nameservers, right? (or rather my ISP needs to do that in the background) So an extra lookup that takes time?

If I now have glue records, I know the IP adress right away without the need to look it up - so this should speed up the resolution of my domain, shouldnt it?

However my DNS zone provider (tecserver.at) replied that

this would make no sense because "we are not running ns1.ourdomain.com an ns1.ourdomain.com as authorative NS for ourdomain.com.

This would be the only sense for glue records.

Tecserver has a glue record because the NS for tecserver.at are ns1.tecserver.at and ns2.tecserver.at. Therefore a glue record is needed for resolution.

Any automated syslog solution finding frameworks? I want my central syslog server to email a list of problems, their severity and suggested solutions.
There have been several questions about centralising system logs and alternative log analysis systems, but I don't get the impression that any of them help with issue resolution.

A little background:
At work I am now literally doing the work of two people, and both jobs have expanded beyond their initial frameworks. It is not so bad as I have helpers, but they are little more than smart monkeys. While one of my predecessors [I have two, that is how I know I have the jobs of two people] set-up logwatch to email its results out, my monkeys don't have the skills necessary to identify unimportant data. This has caused all of them, and myself sadly, to setup email filters and ignore the whole thing until something goes "bang".
It would be handy to have someone else tell them what is important, what is connected, and to suggest a few ways to resolve the issue (I could train then to research the solution first, ha!).
My reading of the Splunk and Octopussy sites indicates that I still need to bring my own highly trained monkey to the party. Which I am several years from having.