smallseo.info

How the heck is http://to./ a valid domain name?

Apparently it's a URL shortener. It resolves just fine in Chrome and Firefox. How is this a valid top-level domain?

Update: for the people saying it's browser shenanigans, why is it that: http://com./ does not take me to: http://www.com/?

And, do browsers ever send you a response from some place other than what's actually up in the address bar? Aside from framesets and things like that, I thought browsers tried really hard to send you content only from the site in the address bar, to help guard against phishing.

Is a wildcard CNAME DNS record valid?

I know it's valid to have a DNS A record that's a wildcard (e.g. *.mysite.com). Is it possible/valid/advised to have a wildcard CNAME record?

What's the command-line utility in Windows to do a reverse DNS look-up?

Is there a built-in command line tool that will do reverse DNS look-ups in Windows? I.e., something like <toolname> w.x.y.z => mycomputername

I've tried:

• nslookup: seems to be forward look-up only.
• host: doesn't exist
• dig: also doesn't exist.

I found "What's the reverse DNS command line utility?" via a search, but this is specifically looking for a *nix utility, not a Windows one.

Linux command to inspect TXT records of a domain

Is there a linux shell command that I can use to inspect the TXT records of a domain?

Setting the hostname: FQDN or short name?

I've noticed that the "preferred" method of setting the system hostname is fundamentally different between Red Hat/CentOS and Debian/Ubuntu systems.

CentOS documentation and the RHEL deployment guide say the hostname should be the FQDN:

HOSTNAME=<value>, where <value> should be the Fully Qualified Domain Name (FQDN), such as hostname.example.com, but can be whatever hostname is necessary.

The RHEL install guide is slightly more ambiguous:

Setup prompts you to supply a host name for this computer, either as a fully-qualified domain name (FQDN) in the format hostname.domainname or as a short host name in the format hostname.

The Debian reference says the hostname should not use the FQDN:

3.5.5. The hostname

The kernel maintains the system hostname. The init script in runlevel S which is symlinked to "/etc/init.d/hostname.sh" sets the system hostname at boot time (using the hostname command) to the name stored in "/etc/hostname". This file should contain only the system hostname, not a fully qualified domain name.

I haven't seen any specific recommendations from IBM about which to use, but some software seems to have a preference.

My questions:

• In a heterogeneous environment, is it better to use the vendor recommendation, or choose one and be consistent across all hosts?
• What software have you encountered which is sensitive to whether the hostname is set to the FQDN or short name?

Top level domain/domain suffix for private network?

At our office, we have a local area network with a purely internal DNS setup, on which clients all named as whatever.lan. I also have a VMware environment, and on the virtual-machine-only network, I name the virtual machines whatever.vm.

Currently, this network for the virtual machines isn't reachable from our local area network, but we're setting up a production network to migrate these virtual machines to, which will be reachable from the LAN. As a result, we're trying to settle on a convention for the domain suffix/TLD we apply to the guests on this new network we're setting up, but we can't come up with a good one, given that .vm, .local and .lan all have existing connotations in our environment.

So, what's the best practice in this situation? Is there a list of TLDs or domain names somewhere that's safe to use for a purely internal network?

How to Configure Windows Machine to Allow File Sharing with DNS Alias

What process is necessary to configure a Windows environement to allow me to use DNS CNAME to reference servers?

I want to do this so that I can name my servers something like SRV001, but still have \\file point to that server, so when SRV002 replaces it I don't have to update any of the links people have, just update the DNS CNAME and everyone will get pointed to the new server.

Should we host our own nameservers?

This is a Canonical Question about whether to outsource DNS resolution for ones own domains

I currently have my ISP providing DNS for my domain, but they impose limitations on adding records. Therefore, I am thinking about running my own DNS.

Do you prefer to host your own DNS, or is it better to have your ISP do this?

Are there alternatives which I can look into?

How can I see Time-To-Live (TTL) for a DNS record?

I would like to see the Time-To-Live (TTL) value for a CNAME record.

I have access to dig (on Apple Mac OS X), which gives me an answer like this:

% dig host.example.gov
<*SNIP*>
;; ANSWER SECTION:
host.example.gov.       43200   IN  CNAME   host1.example.gov.
host1.example.gov.      43200   IN  A       192.168.16.10

Is the value '43200' the TTL for this DNS record?

Why can't MX records point to an IP address?

I understand you should not point a MX record at an IP address directly, but should instead point it to an A record, which, in turns, points to the IP address of your mail server.

But, in principle, why is this required?

Multiple data centers and HTTP traffic: DNS Round Robin is the ONLY way to assure instant fail-over?

Multiple A records pointing to the same domain seem to be used almost exclusively to implement DNS Round Robin as a cheap load balancing technique.

The usual warning against DNS RR is that it is not good for high availability. When 1 IP goes down clients will continue to use it for minutes.

A load balancer is often suggested as a better choice.

Both claims are not completely true:

1. When the traffic is HTTP then, most of the HTML browsers are able to automatically try the next A record if the previous is down, without a new DNS look-up. Read here chapter 3.1 and here.

2. When multiple data centers are involved then, DNS RR is the only option to distribute traffic across them.

So, is it true that, with multiple data centers and HTTP traffic, the use of DNS RR is the ONLY way to assure instant fail-over when one data center goes down?

Thanks,

Valentino

Edit:

• Off course each data center has a local Load Balancer with hot spare.
• It's OK to sacrifice session affinity for an instant fail-over.
• AFAIK the only way for a DNS to suggest a data center instead of another is to reply with just the IP (or IPs) associated to that data center. If the data center becomes unreachable then all those IP are also unreachables. This means that, even if smart HTML browsers are able to instantly try another A record , all the attempts will fail until the local cache entry expires and a new DNS lookup is done, fetching the new working IPs (I assume DNS automatically suggests to a new data center when one fail). So, "smart DNS" cannot assure instant fail-over.
• Conversely a DNS round-robin permits it. When one data center fail, the smart HTML browsers (most of them) instantly try the other cached A records jumping to another (working) data center. So, DNS round-robin doesn't assure session affinity or the lowest RTT but seems to be the only way to assure instant fail-over when the clients are "smart" HTML browsers.

Edit 2:

• Some people suggest TCP Anycast as a definitive solution. In this paper (chapter 6) is explained that Anycast fail-over is related to BGP convergence. For this reason Anycast can employ from 15 minutes to 20 seconds to complete. 20 seconds are possible on networks where the topology was optimized for this. Probably just CDN operators can grant such fast fail-overs.

Edit 3:*

• I did some DNS look-ups and traceroutes (maybe some expert can double check) and:
  • The only CDN using TCP Anycast seems to be CacheFly, other operators like CDN networks and BitGravity use CacheFly. Seems that their edges cannot be used as reverse proxies. Therefore, they cannot be used to grant instant failover.
  • Akamai and LimeLight seems to use geo-aware DNS. But! They return multiple A records. From traceroutes seems that the returned IPs are on the same data center. So, I'm puzzled on how they can offer a 100% SLA when one data center goes down.

DNS failing to propagate worldwide

I haven't changed anything related to the DNS entry for serverfault.com, but some users were reporting today that the serverfault.com DNS fails to resolve for them.

I ran a justping query and I can sort of confirm this -- serverfault.com dns appears to be failing to resolve in a handful of countries, for no particular reason that I can discern. (also confirmed via What's My DNS which does some worldwide pings in a similar fashion, so it's confirmed as an issue by two different sources.)

• Why would this be happening, if I haven't touched the DNS for serverfault.com ?

• our registrar is (gag) GoDaddy, and I use default DNS settings for the most part without incident. Am I doing something wrong? Have the gods of DNS forsaken me?

• is there anything I can do to fix this? Any way to goose the DNS along, or force the DNS to propagate correctly worldwide?

Update: as of Monday at 3:30 am PST, everything looks correct.. JustPing reports site is reachable from all locations. Thank you for the many very informative responses, I learned a lot and will refer to this Q the next time this happens..

Should CNAME Be Used For Subdomains?

I manage multiple websites that currently have the following DNS configuration:

example.com      - A Record - Production Server IP
test.example.com - A Record - Test Server IP
www.example.com  - CNAME    - example.com
beta.example.com - CNAME    - test.example.com
dev.example.com  - CNAME    - test.example.com

Is this an appropriate use of CNAME records? I've looked online and have not found a clear answer. Some people claim that CNAME records are bad (they are not, however, clear on why this is) and propose the following setup:

example.com      - A Record - Production Server IP
test.example.com - A Record - Test Server IP
www.example.com  - A Record - Production Server IP
beta.example.com - A Record - Test Server IP
dev.example.com  - A Record - Test Server IP

Which one of these is the better approach (and why)?

Note: The subdomains do not require their own MX records, so that is not an issue here.

Are IP addresses "trivial to forge"?

I was reading through some of the notes on Google's new public DNS service:

• Performance Benefits
• Security Benefits

I noticed under the security section this paragraph:

Until a standard system-wide solution to DNS vulnerabilities is universally implemented, such as the DNSSEC2 protocol, open DNS resolvers need to independently take some measures to mitigate against known threats. Many techniques have been proposed; see IETF RFC 4542: Measures for making DNS more resilient against forged answers for an overview of most of them. In Google Public DNS, we have implemented, and we recommend, the following approaches:

• Overprovisioning machine resources to protect against direct DoS attacks on the resolvers themselves. Since IP addresses are trivial for attackers to forge, it's impossible to block queries based on IP address or subnet; the only effective way to handle such attacks is to simply absorb the load.

That is a depressing realization; even on Stack Overflow / Server Fault / Super User, we frequently use IP addresses as the basis for bans and blocks of all kinds.

To think that a "talented" attacker could trivially use whatever IP address they want, and synthesize as many unique fake IP addresses as they want, is really scary!

So my question(s):

• Is it really that easy for an attacker to forge an IP address in the wild?
• If so, what mitigations are possible?

DNS - NSLOOKUP what is the meaning of the non-authoritative answer?

When I do a NS Lookup, for some domains I get the reply saying Non-authorative answer:. I want to know what it means?

Got answer:
    HEADER:
        opcode = QUERY, id = 3, rcode = NXDOMAIN
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional =

    QUESTIONS:
        www.ssss.com.SME, type = AAAA, class = IN
    AUTHORITY RECORDS:
    ->  (root)
        ttl = 1787 (29 mins 47 secs)
        primary name server = a.root-servers.net
        responsible mail addr = nstld.verisign-grs.com

------------
Non-authoritative answer:
------------

------------
Name:    xxx.com
Address:  199.1xx.xx.1xx
Aliases:  www.xxx.com