Martin's questions

Let's say a website is load-balanced between several servers. I want to run a command to test whether it's working, such as curl DOMAIN.TLD. So, to isolate each IP address, I specify the IP manually. But many websites may be hosted on the server, so I still provide a host header, like this: curl IP_ADDRESS -H 'Host: DOMAIN.TLD'. In my understanding, these two commands create the exact same HTTP request. The only difference is that in the latter one I take out the DNS lookup part from cURL and do this manually (please correct me if I'm wrong).

All well so far. But now I want to do the same for an HTTPS url. Again, I could test it like this curl https://DOMAIN.TLD. But I want to specify the IP manually, so I run curl https://IP_ADDRESS -H 'Host: DOMAIN.TLD'. Now I get a cURL error:

curl: (51) SSL: certificate subject name 'DOMAIN.TLD' does not match target host name 'IP_ADDRESS'.

I can of course get around this by telling cURL not to care about the certificate (the "-k" option) but it's not ideal.

Is there a way to isolate the IP address being connected to from the host being certified by SSL?

I'm using a virtual Ubuntu Server (on Amazon EC2) and I want to connect to a PPTP VPN server to route outgoing traffic through this connection. To do this, I specify the following two options:

defaultroute
replacedefaultroute

This works - but the moment the tunnel to route the traffic is established, my SSH connection to the server is broken and I can't reconnect. This makes sense, but is nevertheless a real problem. Any ideas for a workaround? How can I route outgoing traffic through the VPN connection and still be able to SSH into the machine?

I can use either PPTP or L2TP. All the tutorials I find require a GUI to setup the connections. However, I want to connect from a virtual server to which I have only SSH access. Any hints?

I'm trying to understand why one given DNS server is not resolving our domain correctly.

When I look up www.foo.com from this name server, a CNAME foo.bar.cc is correctly returned but there's no attached A record and the response status is NXDOMAIN. I understand that this could happen if the DNS server can not resolve the alias foo.bar.cc. However, if I use the same DNS server and look up foo.bar.cc directly, I always get the correct A record.

When using any other DNS servers I've tested (different ISPs, Google DNS, Open DNS) our domain resolves correctly.

Given this situation, is there some possible problem in our DNS that could cause this? Or does it seem like this given DNS server is to blame? The DNS server in question is used by a lot of people and it seems more likely that the problem is caused by us, but I don't see how - any clues?

Let's say we have a subdomain called www.foo.com which has a CNAME record pointing at foo.bar.cc. Foo.bar.cc in turn has an A record pointing at the IP address 1.2.3.4.

Now, if I do a DNS lookup of www.foo.com I'll get an answer looking like this:

www.foo.com. IN CNAME foo.bar.cc.
foo.bar.cc. IN A 1.2.3.4

My question is, at what stage is foo.bar.cc resolved? Is it done by the recursive DNS server before the response is sent back to the client? Or does the client issue a second request to the DNS server, this time for foo.bar.cc? Or does it depend on whether the DNS server already has a cached entry for foo.bar.cc?

I'm asking because one particular recursive DNS server returns only the first line, ie it does not resolve the CNAME. However, after perhaps 20 seconds, subsequent requests for the same host will then include both lines.

I'm currently logging "The time taken to serve the request, in microseconds" using the %D directive (as specified on https://httpd.apache.org/docs/2.4/mod/mod_log_config.html). However, this seems to log only the time used by Apache to create the response. Is there some way I can log the total time that the client is connected to the server? For example, Apache may create the page in 200 ms, but the client takes 2 seconds to download the page, because of a slow network. I'm interested in the 2 seconds here, since I want to measure the clients performance relative to this specific server.

We have started to run our own DNS servers located in Asia since that's where our main audience is. However, it seems that some users in the US are having difficulties accessing our website sometimes. I've noticed myself that DNS lookups of our domain from the US are relatively slow (500 msec+). Maybe the problems some users are having are due to other DNS configuration errors, but in general, how much of an issue is the geographical location of DNS servers? Should we have an additional server in the US?

Let's say I have the domain example.com using the name servers dns1.example.co.uk and dns2.example.co.uk. If I've understood it correctly, this means additional lookups since the .com doesn't contain glue records for domains on other TLDs. In practice, is this a problem? Does it make lookups noticeably slower?

Web server: Nginx.

Checking our log files, there are many log entries of connections that:

• take 59-61 seconds
• send an empty request (or at least none is logged)
• result in a 408 response (request timed out)
• do not contain any http_user_agent
• originate from a limited number of IPs

We are monitoring average times to serve responses and this obviously inflates our statistics. Apart from that though, is this a problem? Any idea why it is occurring? Does it suggest that somebody is intentionally messing with us? What should we do?