Miscellaneous
Reverse DNS Policy
Summary
In order to access many Sargasso services, including FTP and SSH, you will require correctly set up reverse DNS. Usually this is not within your realm of control. Instead you may choose to refer your ISP (dialup or broadband) to this page for further information.
Explanation and Rationale
Sargasso login servers (including FTP and SSH) are configured to perform reverse DNS lookups for each connection, and to refuse the connection if the forward and reverse DNS do not match. The rationale is simple: an imposter may easily configure his reverse DNS to be 'myhost.yahoo.com', but if he is not also in control of the forward DNS for 'yahoo.com', the inverse mapping will not match.
Therefore correctly matching forward and reverse DNS may allow a fair degree of confidence that the reverse DNS hostname is correct. Conversely, mismatching DNS is indicative of subterfuge, or a misconfigured DNS service.
Concept
If 1.2.3.4 maps to "www.myhost.com", then "www.myhost.com" must map to 1.2.3.4
In technical terms, the PTR record must map to a valid hostname that has an A record that maps back to the same address.
in zone 3.2.1.in-addr.arpa: 4 IN PTR www.myhost.com. in zone myhost.com: www IN A 1.2.3.4
Sidenote: It is sufficient for ONE of the A records to point to 1.2.3.4, if www.myhost.com has multiple addresses.
Exercise
The following exercise will demonstrate the logic behind our server's correct refusal of a connection from 80.0.93.30
- First we look up the hostname from the address (reverse DNS):
C:\>nslookup 80.0.93.30 Name: spc1-epso2-4-0-cust30.asfd.broadband.ntl.com Address: 80.0.93.30
So whoever is responsible for this address claims that its hostname is spc1-epso2-4-0-cust30.asfd.broadband.ntl.com. - Second, we look up the address for this hostname (forward DNS):
C:\>nslookup spc1-epso2-4-0-cust30.asfd.broadband.ntl.com *** cache1.ns.sargasso.net can't find spc1-epso2-4-0-cust30.asfd.broadband.ntl.com: Non-existent domain
The DNS servers for 'ntl.com' deny that this mapping is correct, or that that hostname even exists. This is why this user is blocked.
A similar situation would have resulted if step 2 had returned an address that was not the same as the original query (80.0.93.30).
Solution
Any competent ISP should have an engineering team capable of fixing misconfigured DNS servers. Typically the three problems we see most are:
- Missing reverse DNS: there simply is no PTR record for the IP address in question.
- Incorrect or placeholder DNS: the PTR record exists, but the A record it points to does not exist or is bogus (e.g. no-dns-yet.demon.net)
- A special case of 2.: Relative zone specified by accident: by missing off the period at the end of the PTR line above, 1.2.3.4 would incorrectly resolve to www.myhost.com.3.2.1.in-addr.arpa.