Mailing List Archive

Nevermind, the domain didn't expire (my confusion). However, I am having
problems reaching the site to download the script. Has anyone else
noticed this or is this a local issue?

Nathan

Thus spake Nathan Johanson (nathan@tcpnetworks.net) [05/02/04 17:29]:
> Nevermind, the domain didn't expire (my confusion). However, I am having
> problems reaching the site to download the script. Has anyone else
> noticed this or is this a local issue?

No, I'm having troubles as well. It looks like the primary and secondary
nameservers aren't responding authoritatively (when they respond):

[damian]@[pegmatite]:[~]% dig @NS1.GRANITECANYON.COM sandgnat.com soa
+noaddit

; <<>> DiG 8.3 <<>> @NS1.GRANITECANYON.COM sandgnat.com soa +noaddit
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11813
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 13
;; QUERY SECTION:
;; sandgnat.com, type = SOA, class = IN

;; AUTHORITY SECTION:
com. 7h45m57s IN NS A.GTLD-SERVERS.NET.
com. 7h45m57s IN NS G.GTLD-SERVERS.NET.
com. 7h45m57s IN NS H.GTLD-SERVERS.NET.
com. 7h45m57s IN NS C.GTLD-SERVERS.NET.
com. 7h45m57s IN NS I.GTLD-SERVERS.NET.
com. 7h45m57s IN NS B.GTLD-SERVERS.NET.
com. 7h45m57s IN NS D.GTLD-SERVERS.NET.
com. 7h45m57s IN NS L.GTLD-SERVERS.NET.
com. 7h45m57s IN NS F.GTLD-SERVERS.NET.
com. 7h45m57s IN NS J.GTLD-SERVERS.NET.
com. 7h45m57s IN NS K.GTLD-SERVERS.NET.
com. 7h45m57s IN NS E.GTLD-SERVERS.NET.
com. 7h45m57s IN NS M.GTLD-SERVERS.NET.

;; Total query time: 159 msec
;; FROM: pegmatite.sentex.ca to SERVER: 205.166.226.38
;; WHEN: Thu Feb 5 17:39:13 2004
;; MSG SIZE sent: 30 rcvd: 462

[damian]@[pegmatite]:[~]% dig @NS2.GRANITECANYON.COM sandgnat.com soa
+noaddit

; <<>> DiG 8.3 <<>> @NS2.GRANITECANYON.COM sandgnat.com soa +noaddit
; (1 server found)
;; res options: init recurs defnam dnsrch
;; res_nsend: Operation timed out
[damian]@[pegmatite]:[~]%

And the tertiary -- ns1.sandgnat.com -- isn't responding:

[damian]@[pegmatite]:[~]% dig @NS1.SANDGNAT.COM sandgnat.com soa +noaddit

; <<>> DiG 8.3 <<>> @NS1.SANDGNAT.COM sandgnat.com soa +noaddit
; (1 server found)
;; res options: init recurs defnam dnsrch
;; res_nsend: Operation timed out
[damian]@[pegmatite]:[~]%

A traceroute for me dies at 65.126.82.34, after traversing Qwest.

Yep, that's what I'm seeing.

I'd run a trace but I can't even resolve the domain at this point. The
"my_rules_du_jour_" script is hanging up while running wget to download
an updated script.

-----Original Message-----
From: Damian Gerow [mailto:freebsd@coal.sentex.ca]
Sent: Thursday, February 05, 2004 2:40 PM
To: Nathan Johanson
Cc: spamassassin-users@incubator.apache.org
Subject: Re: Sandgnat.com Down - RulesDuJour Affected

Thus spake Nathan Johanson (nathan@tcpnetworks.net) [05/02/04 17:29]:
> Nevermind, the domain didn't expire (my confusion). However, I am
having
> problems reaching the site to download the script. Has anyone else
> noticed this or is this a local issue?

No, I'm having troubles as well. It looks like the primary and
secondary
nameservers aren't responding authoritatively (when they respond):

[damian]@[pegmatite]:[~]% dig @NS1.GRANITECANYON.COM sandgnat.com
soa
+noaddit

; <<>> DiG 8.3 <<>> @NS1.GRANITECANYON.COM sandgnat.com soa +noaddit

; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11813
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 13
;; QUERY SECTION:
;; sandgnat.com, type = SOA, class = IN

;; AUTHORITY SECTION:
com. 7h45m57s IN NS A.GTLD-SERVERS.NET.
com. 7h45m57s IN NS G.GTLD-SERVERS.NET.
com. 7h45m57s IN NS H.GTLD-SERVERS.NET.
com. 7h45m57s IN NS C.GTLD-SERVERS.NET.
com. 7h45m57s IN NS I.GTLD-SERVERS.NET.
com. 7h45m57s IN NS B.GTLD-SERVERS.NET.
com. 7h45m57s IN NS D.GTLD-SERVERS.NET.
com. 7h45m57s IN NS L.GTLD-SERVERS.NET.
com. 7h45m57s IN NS F.GTLD-SERVERS.NET.
com. 7h45m57s IN NS J.GTLD-SERVERS.NET.
com. 7h45m57s IN NS K.GTLD-SERVERS.NET.
com. 7h45m57s IN NS E.GTLD-SERVERS.NET.
com. 7h45m57s IN NS M.GTLD-SERVERS.NET.

;; Total query time: 159 msec
;; FROM: pegmatite.sentex.ca to SERVER: 205.166.226.38
;; WHEN: Thu Feb 5 17:39:13 2004
;; MSG SIZE sent: 30 rcvd: 462

[damian]@[pegmatite]:[~]% dig @NS2.GRANITECANYON.COM sandgnat.com
soa
+noaddit

; <<>> DiG 8.3 <<>> @NS2.GRANITECANYON.COM sandgnat.com soa +noaddit

; (1 server found)
;; res options: init recurs defnam dnsrch
;; res_nsend: Operation timed out
[damian]@[pegmatite]:[~]%

And the tertiary -- ns1.sandgnat.com -- isn't responding:

[damian]@[pegmatite]:[~]% dig @NS1.SANDGNAT.COM sandgnat.com soa
+noaddit

; <<>> DiG 8.3 <<>> @NS1.SANDGNAT.COM sandgnat.com soa +noaddit
; (1 server found)
;; res options: init recurs defnam dnsrch
;; res_nsend: Operation timed out
[damian]@[pegmatite]:[~]%

A traceroute for me dies at 65.126.82.34, after traversing Qwest.

Thus spake Nathan Johanson (nathan@tcpnetworks.net) [05/02/04 17:47]:
> I'd run a trace but I can't even resolve the domain at this point. The
> "my_rules_du_jour_" script is hanging up while running wget to download
> an updated script.

Edit the script, and add this line right above the TMPDIR line:

DONT_CHECK_FOR_RDJ_UPDATES=1

That should stop it from trying to check for updates for itself (in theory,
I haven't tested it).

Thus spake Damian Gerow (freebsd@coal.sentex.ca) [05/02/04 17:50]:
> Edit the script, and add this line right above the TMPDIR line:
>
> DONT_CHECK_FOR_RDJ_UPDATES=1
>
> That should stop it from trying to check for updates for itself (in theory,
> I haven't tested it).

Gah, hit enter too soon.

Note that this is for rules_du_jour, /not/ my_rules_du_jour. I don't have
(and can't get, for obvious reasons) a copy of the latter.

Thanks for the tip. I noticed when moving to version 1.8 of the script
this afternon.

I figured I would give it until this evening before the next cronjob.
I'm sure others are bound to notice. It's probably not a "local" issue,
(as judging from your email address) you appear to be in Canada and I'm
in California. We'll see.

Nathan

-----Original Message-----
From: Damian Gerow [mailto:freebsd@coal.sentex.ca]
Sent: Thursday, February 05, 2004 2:50 PM
To: Nathan Johanson
Cc: spamassassin-users@incubator.apache.org
Subject: Re: Sandgnat.com Down - RulesDuJour Affected

Thus spake Nathan Johanson (nathan@tcpnetworks.net) [05/02/04 17:47]:
> I'd run a trace but I can't even resolve the domain at this point. The
> "my_rules_du_jour_" script is hanging up while running wget to
download
> an updated script.

Edit the script, and add this line right above the TMPDIR line:

DONT_CHECK_FOR_RDJ_UPDATES=1

That should stop it from trying to check for updates for itself (in
theory,
I haven't tested it).

Nathan Johanson said:
> I noticed this morning that the sandgnat.com domain has expired
> (apparently in December). This does seem to affect the ruledujour
> scripts, as it just sits there presumably timing out on this domain (as
> part of its self-update checks).
>
> I noticed this when I tried to download an updated version of the
> my_rules_du_jour script.
>
> I'm sure Chris is already aware of this, but thought I would bring it to
> the list's attention.
>
> Nathan

Sorry, all.

My mail and www servers (sandgnat.com) are running off my DSL line at
home. Somebody was digging in the area and my entire neighborhood lost
power and phone connectivity. Power was restored quickly and it looks
like phone was just restored.

I'm going to run some tests regarding RDJ not working properly if the
auto-update check fails and hopefully release a bugfix (probably early
next week). However, I can't think off the top of my head why RDJ might
not finish updating the rules files after timing out looking for
sandgnat.com (I don't have the script in front of me right now). If I
remember correctly, nothing should be output for the "RDJ auto update"
code on failure.

--
Chris Thielen

Easily generate SpamAssassin rules to catch obfuscated spam phrases
(0BFU$C/\TED SPA/\/\ P|-|RA$ES):
http://www.sandgnat.com/cmos/

On Thu, 2004-02-05 at 16:47, Nathan Johanson wrote:
> Yep, that's what I'm seeing.
>
> I'd run a trace but I can't even resolve the domain at this point. The
> "my_rules_du_jour_" script is hanging up while running wget to download
> an updated script.

Nathan/everyone:
I would love to make RDJ more robust. However, I can't get it to fail
or hang by pointing it to some bogus domain. Did anyone else experience
issues when sandgnat.com was offline? Any additional information that
could help me test? Version of wget perhaps?

Thanks.

--
Chris Thielen

Easily generate SpamAssassin rules to catch obfuscated spam phrases:
http://www.sandgnat.com/cmos/

----- Original Message -----
From: "Chris Thielen" <cmt-spamassassin@someone.dhs.org>

> On Thu, 2004-02-05 at 16:47, Nathan Johanson wrote:
> > Yep, that's what I'm seeing.
> >
> > I'd run a trace but I can't even resolve the domain at this point. The
> > "my_rules_du_jour_" script is hanging up while running wget to download
> > an updated script.
>
> Nathan/everyone:
> I would love to make RDJ more robust. However, I can't get it to fail
> or hang by pointing it to some bogus domain. Did anyone else experience
> issues when sandgnat.com was offline? Any additional information that
> could help me test? Version of wget perhaps?

Chris, when I attempt during the outage, the RDJ script hung for about 15
seconds right after executing, and then ran through the balance of the
script fine. I tested it about 3 time and each time it ran successfully
after the initial 15 second pause. I am running GNU Wget 1.8.2 on RH9.

Bill

>
> Nathan/everyone:
> I would love to make RDJ more robust. However, I can't get it to fail
> or hang by pointing it to some bogus domain. Did anyone else
> experience
> issues when sandgnat.com was offline? Any additional information that
> could help me test? Version of wget perhaps?
>
> Thanks.
>

I'm using wget-1.8.2-14.72 on RHEL 2.1.

Here are some notable circumstances...

* I could not resolve the sandgnat.com domain during the outage. DNS
couldn't even give me the IP address, presumably because your
authoritative name servers were also on the DSL line?
* I ran the my_rules_du_jour script (not the original rules_du_jour).
When I ran it manually, it would hang and a subsequent look at processes
showed the wget process active and attempting to connect to
sandgnat.com.
* Turning off the "DON'T_CHECK_FOR_RDJ_UPDATES" option fixed the problem
(as suggested by Damian Derow).

Of course, everything is working fine now.

Nathan