$ Nobody else outside your uni can resolve www.kymhorsell.com as your DNS $ server holt.cs.latrobe.edu.au is uncontactable. Try querying a few looking $ glasses out there if you want confirmation. [Later goes on to find that some sites -- even in AUS -- can resolve the name; just marks them "irrelevant"]. -- Synic , Fri, 25 Apr 2003 =============================================================================== EXPERIMENTAL SUBJECT HAS REFUSED TO LOOK AT/CAN NOT OBTAIN EXHIBIT A: MXlookup from XXXXXXXXXXXXXXXXXXXXX for kymhorsell.com Server: localhost Address: 127.0.0.1 kymhorsell.com preference = 10, mail exchanger = mail.kymhorsell.com kymhorsell.com preference = 20, mail exchanger = mail2.kymhorsell.com kymhorsell.com nameserver = ns.kymhorsell.com kymhorsell.com nameserver = ns1.kymhorsell.com mail.kymhorsell.com internet address = 131.172.104.191 mail2.kymhorsell.com internet address = 131.172.104.101 ns.kymhorsell.com internet address = 131.172.104.101 ns1.kymhorsell.com internet address = 131.172.104.191 -- 27 Apr 2003 =============================================================================== $ (You do know that this thread could be aborted by your proving you've got $ control of the networking to your nameserver as you claim, right? Drop $ the network blocks you claim to have intentionally put in place (on DNS $ and HTTP at least) for 24 hours and email me. If www.kymhorsell.com [Apparently the goalposts are now "does Kym actually have control of a packet filter?" ;-)]. $ resolves correctly and the page loads during that time, I'll happily $ announce that the absurd policies you've claimed are intentional and the $ subject's dropped. Hell, I'll even throw in the occasional flaming of $ Mosley on the topic, free. Can't get any fairer than that.) -- Synic , 27 Apr 2003 $ $ If there's anything worse than an ignorant tech, it's one who blusters $ and lies to cover up their mistakes. $ -- Synic , Sun, 27 Apr 2003 =============================================================================== EXPERIMENTAL SUBJECT HAS REFUSED TO LOOK AT/CAN NOT OBTAIN EXHIBIT B: DNS Report for kymhorsell.com Generated by XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX on 30 Apr 2003. Category Status Test Name Information Parent PASS Missing Parent check OK. Your parent zone exists, which is good. Some domains (usually third or fourth level domains, such as example.co.us) do not have a parent zone ('co.us' in this example), which is legal but can cause confusion. INFO NS records at parent servers Your NS records at the parent servers are: holt.cs.latrobe.edu.au. [131.172.104.191 (NO GLUE)] [These were obtained from l.gtld-servers.net] PASS Parent nameservers have your nameservers listed OK. When someone uses DNS to look up your domain, the first step (if it doesn't already know about your domain) is to go to the parent servers. If you aren't listed there, you can't be found. But you are listed there, with 1 entries. WARN Glue at parent nameservers WARNING. The parent servers (L.GTLD-SERVERS.NET.) are not providing glue for all your nameservers. This means that they are supplying the NS records (host.example.com), but not supplying the A records (192.0.2.53), which can cause slightly slower connections, and may cause some incompatibilities with some programs (if the programs are not fully RFC-compliant). This behavior is allowed by the RFCs. This will usually occur if your DNS servers are not in the same TLD as your domain (for example, a DNS server of "ns1.example.co.uk" for the domain "example.com"). In this case, you can speed up the connections slightly by having NS records that are in the same TLD as your domain. NS INFO NS records at your nameservers Your NS records at your nameservers are: ns1.kymhorsell.com. [TTL=21600] PASS All nameservers report identical NS records OK. The NS records at all your nameservers are identical. PASS All nameservers respond OK. All of your nameservers listed at the parent nameservers responded. PASS Nameserver name validity OK. All of the NS records that your nameservers report seem valid (no IPs or partial domain names). FAIL Number of nameservers ERROR: You have less than two nameservers. You are required to have at least 2 nameservers (RFC2182 section 5 recommends at least 3 nameservers). PASS Lame nameservers OK. All the nameservers listed at the parent servers answer authoritatively for your domain. WARN Missing (stealth) nameservers WARNING: You have one or more missing (stealth) nameservers. The following nameserver(s) are listed (at your nameservers) as nameservers for your domain, but are not listed at the the parent nameservers (therefore, they may or may not get used, depending on whether your DNS servers return them in the authority section for other requests, per RFC2181 5.4.1). You need to make sure that these stealth nameservers are working; if they are not responding, you may have serious problems! The DNS Report will not query these servers, so you need to be very careful that they are working properly. ns1.kymhorsell.com. FAIL Missing nameservers 2 ERROR: One or more of the nameservers listed at the parent servers are not listed as NS records at your nameservers. The problem NS records are: holt.cs.latrobe.edu.au. PASS No CNAMEs for domain OK. There are no CNAMEs for kymhorsell.com. RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present. Note that I only checked kymhorsell.com, I did not check the NS records, which should not have CNAMEs either. PASS No NSs with CNAMEs OK. There are no CNAMEs for your NS records. RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present. WARN Nameservers on separate class C's WARNING: All of your nameservers (listed at the parent nameservers) are in the same Class C address space, which means that they are probably at the same physical location. Your nameservers should be at geographically dispersed locations. You should not have all of your nameservers at the same location. RFC2182 3.1 goes into more detail about secondary nameserver location. [If the parent servers have no glue for your domain, this could be a false positive.] INFO Nameservers versions [Nameserver version test temporarily disabled ] SOA INFO SOA record Your SOA record [TTL=21600] is: Primary nameserver: kymhorsell.com. Hostmaster E-mail address: hostmaster.kymhorsell.com. Serial #: 2002081501 Refresh: 3600 Retry: 900 Expire: 604800 Default TTL: 3600 PASS NS agreement on SOA serial # OK. All your nameservers agree that your SOA serial number is 2002081501. That means that all your nameservers are using the same data (unless you have different sets of data with the same serial number, which would be very bad)! Note that the DNS Report only checks the NS records listed at the parent servers (not any stealth servers). WARN SOA MNAME Check WARNING: Your SOA (Start of Authority) record states that your master (primary) name server is: kymhorsell.com.. However, that server is not listed at the parent servers as one of your NS records! This is probably legal, but you should be sure that you know what you are doing. PASS SOA RNAME Check OK. Your SOA (Start of Authority) record states that your DNS contact E-mail address is: hostmaster@kymhorsell.com. (techie note: we have changed the initial '.' to an '@' for display purposes). PASS SOA Serial Number OK. Your SOA serial number is: 2002081501. This appears to be in the recommended format of YYYYMMDDnn, where 'nn' is the revision. For example, if you are making the 3rd change on 02 May 2000, you would use 2000050203. This number must be incremented every time you make a DNS change. PASS SOA REFRESH value OK. Your SOA REFRESH interval is : 3600 seconds. This seems normal (about 3600-7200 seconds is good; RFC1912 2.2 recommends a value between 1200 to 43200 seconds (20 minutes to 12 hours). This value determines how often secondary/slave nameservers check with the master for updates. PASS SOA RETRY value OK. Your SOA RETRY interval is : 900 seconds. This seems normal (about 120-7200 seconds is good). The retry value is the amount of time your secondary/slave nameservers will wait to contact the master nameserver again if the last attempt failed. PASS SOA EXPIRE value OK. Your SOA EXPIRE time: 604800 seconds. This seems normal (about 1209600 to 2419200 seconds (2-4 weeks) is good). RFC1912 recommends 2-4 weeks. This is how long a secondary/slave nameserver will wait before considering its DNS data stale if it can't reach the primary nameserver. PASS SOA MINIMUM TTL value OK. Your SOA MINIMUM TTL is: 3600 seconds. This seems normal (about 60 to 86400 seconds or 1-24 hours is good). RFC1912 2.2 recommends 1-5 days (86400 to 432000) unless you are about to change DNS entries. This value used to determine the default (technically, minimum) TTL (time-to-live) for DNS entries, but now is used for negative caching. MX INFO MX Record Your 2 MX records are: 20 mail2.kymhorsell.com. [TTL=21600] IP=131.172.104.101 [TTL=21600] 10 mail.kymhorsell.com. [TTL=21600] IP=131.172.104.191 [TTL=21600] PASS MX records are not CNAMEs OK. Looking up your MX record did not just return a CNAME. If an MX record query returns a CNAME, extra processing is required, and some mail servers may not be able to handle it. PASS MX A lookups have no CNAMEs OK. There appear to be no CNAMEs returned for A records lookups from your MX records (CNAMEs are prohibited in MX records, according to RFC974, RFC1034 3.6.2, RFC1912 2.4, and RFC2181 10.3). PASS MX is host name, not IP OK. All of your MX records are host names (as opposed to IP addresses, which are not allowed in MX records). PASS Multiple MX records OK. You have multiple MX records. This means that if one is down or unreachable, the other(s) will be able to accept mail for you. PASS Reverse DNS entries for MX records OK. All of your mail server(s) have reverse DNS (PTR) entries. RFC1912 2.1 says you should have a reverse DNS for all your mail servers. It is strongly urged that you have them, as many mailservers will not accept mail from mailservers with no reverse DNS entry. The reverse DNS entries are: 101.104.172.131.in-addr.arpa swx1.cs.latrobe.EDU.AU. [TTL=86043] 191.104.172.131.in-addr.arpa holt.cs.latrobe.EDU.AU. [TTL=86043] Mail PASS Connect to mail servers OK: I was able to connect to all of your mailservers. WARN Mail server host name in greeting WARNING: One or more of your mailservers claims to be a host other than what it really is (the SMTP greeting should be a 3-digit code, followed by a space or a dash, then the host name). This probably won't cause any harm, but is a technical violation of RFC821 4.3. mail.kymhorsell.com claims to be host holt.cs.latrobe.edu.au. mail2.kymhorsell.com claims to be host holt.cs.latrobe.edu.au. PASS Acceptance of NULL <> sender OK: All of your mailservers accept mail from "<>". You are required (RFC1123 5.2.9) to receive this type of mail (which includes reject/bounce messages and return receipts). PASS Acceptance of postmaster address OK: All of your mailservers accept mail to postmaster@kymhorsell.com (as required by RFC822 6.3, RFC1123 5.2.7, and RFC2821 4.5.1). PASS Acceptance of abuse address OK: All of your mailservers accept mail to abuse@kymhorsell.com. PASS Acceptance of domain literals OK: All of your mailservers accept mail in the domain literal format (user@[131.172.104.101]). DATA Open relay test Open relay test: [Open relay temporarily disabled due to abuse potential] WWW INFO WWW Record Your www.kymhorsell.com A record is: www.kymhorsell.com. A 131.172.104.191 [TTL=21600] PASS CNAME Lookup OK. Some domains have a CNAME record for their WWW server that requires an extra DNS lookup, which slightly delays the initial access to the website and use extra bandwidth. Legend: Rows with a FAIL indicate a problem that really should be fixed. Rows with a WARN indicate a possible minor problem, which often is not worth pursuing. -- 30 Apr 2003 (1 May AEST) =============================================================================== [Oblivious to the self-reference:] $ Mate, there's nothing sadder than someone becoming so haughty they $ throw away user feedback. -- Synic , Sat, 26 Apr 2003 $ Unlike yourself, Mosley and the rest of the nutter crew, I'm quite fine $ about being proven wrong when I'm wrong and moving on from it. -- Synic , Sun, 27 Apr 2003 ================================ E N D ========================================