Month: October 2007

A client whose emails are being relayed through a server I maintain alerted me that he wasn’t getting any emails though. After confirming that the email server was running smoothly, I checked the name resolution for “sbcglobal.net” with nslookup. Nothing there! Several other major DNS providers with exception of OpenDNS weren’t resolving sbcglobal.net, either (perhaps OpenDNS holds the cache for longer?) Would the queries be blocked from some areas of the net (I can’t imagine why)? I tried from three major networks with the same results. Yet there’s no major outcry on the web that sbcglobal.net would not be working, and DNSStuff DNSresport doesn’t find anything majorly wrong with sbcglobal.net service (other than that there is no A record.. but my digging couldn’t find anything – not even an MX record!) Every other valid zone I try works normally at their corresponding name servers (as listed in the zone’s registrar records). Can anyone explain?

Here’s a transcript from one of the systems (others were like a mirror copy.. exactly the same results):

[Astronite:/] [14:41]# whois sbcglobal.net

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

   Domain Name: SBCGLOBAL.NET
   Registrar: NETWORK SOLUTIONS, LLC.
   Whois Server: whois.networksolutions.com
   Referral URL: http://www.networksolutions.com
   Name Server: NS1.PBI.NET
   Name Server: NS1.SWBELL.NET
   Name Server: NS2.SWBELL.NET
   Status: clientTransferProhibited
   Updated Date: 09-oct-2006
   Creation Date: 27-mar-2000
   Expiration Date: 27-mar-2015

>>> Last update of whois database: Sat, 27 Oct 2007 19:40:32 UTC < <<

[whois server legal yada-yada deleted]

Visit AboutUs.org for more information about SBCGLOBAL.NET
AboutUs: SBCGLOBAL.NET

Registrant:
SBC Internet Services, Inc.
   1701 Alma dr
   Plano, TX 75075
   US

   Domain Name: SBCGLOBAL.NET

   Administrative Contact, Technical Contact:
      Southwestern, Bell                DNSCONTACT@att.com
      Southwestern Bell Internet Services
      1701 Alma dr
      Plano, TX 75075
      US
      1-800-648-1626 fax: 214-473-2253

   Record expires on 27-Mar-2015.
   Record created on 27-Mar-2000.
   Database last updated on 27-Oct-2007 15:41:08 EDT.

   Domain servers in listed order:

   NS1.PBI.NET                  206.13.28.11
   NS1.SWBELL.NET               151.164.1.1
   NS2.SWBELL.NET               151.164.11.218

[Astronite:/] [14:41]# nslookup
> server ns1.pbi.net
Default server: ns1.pbi.net
Address: 206.13.28.11#53
> sbcglobal.net
Server:         ns1.pbi.net
Address:        206.13.28.11#53

*** Can't find sbcglobal.net: No answer
> server ns1.swbell.net
Default server: ns1.swbell.net
Address: 151.164.1.1#53
> sbcglobal.net
;; connection timed out; no servers could be reached
> server ns2.swbell.net
Default server: ns2.swbell.net
Address: 151.164.11.218#53
> sbcglobal.net
;; connection timed out; no servers could be reached
> exit

[Astronite:/] [14:42]# dig @ns1.pbi.net sbcglobal.net /all
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 2301
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;sbcglobal.net.                 IN      A

;; AUTHORITY SECTION:
sbcglobal.net.          7200    IN      SOA     ns1.swbell.net. postmaster.swbell.net. 2007102500 7200 900 604800 7200

;; Query time: 182 msec
;; SERVER: 206.13.28.11#53(206.13.28.11)
;; WHEN: Sat Oct 27 14:42:37 2007
;; MSG SIZE  rcvd: 89

; <<>> DiG 9.4.1-P1 < <>> @ns1.pbi.net sbcglobal.net /all
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 64773
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 13
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;/all.                          IN      A

;; AUTHORITY SECTION:
.                       386954  IN      NS      B.ROOT-SERVERS.NET.
.                       386954  IN      NS      C.ROOT-SERVERS.NET.
.                       386954  IN      NS      D.ROOT-SERVERS.NET.
.                       386954  IN      NS      E.ROOT-SERVERS.NET.
.                       386954  IN      NS      F.ROOT-SERVERS.NET.
.                       386954  IN      NS      G.ROOT-SERVERS.NET.
.                       386954  IN      NS      H.ROOT-SERVERS.NET.
.                       386954  IN      NS      I.ROOT-SERVERS.NET.
.                       386954  IN      NS      J.ROOT-SERVERS.NET.
.                       386954  IN      NS      K.ROOT-SERVERS.NET.
.                       386954  IN      NS      L.ROOT-SERVERS.NET.
.                       386954  IN      NS      M.ROOT-SERVERS.NET.
.                       386954  IN      NS      A.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:
B.ROOT-SERVERS.NET.     473354  IN      A       192.228.79.201
C.ROOT-SERVERS.NET.     473354  IN      A       192.33.4.12
D.ROOT-SERVERS.NET.     473354  IN      A       128.8.10.90
E.ROOT-SERVERS.NET.     473354  IN      A       192.203.230.10
F.ROOT-SERVERS.NET.     473354  IN      A       192.5.5.241
G.ROOT-SERVERS.NET.     473354  IN      A       192.112.36.4
H.ROOT-SERVERS.NET.     473354  IN      A       128.63.2.53
I.ROOT-SERVERS.NET.     473354  IN      A       192.36.148.17
J.ROOT-SERVERS.NET.     473354  IN      A       192.58.128.30
K.ROOT-SERVERS.NET.     473354  IN      A       193.0.14.129
L.ROOT-SERVERS.NET.     473354  IN      A       198.32.64.12
M.ROOT-SERVERS.NET.     473354  IN      A       202.12.27.33
A.ROOT-SERVERS.NET.     473354  IN      A       198.41.0.4

;; Query time: 92 msec
;; SERVER: 206.13.28.11#53(206.13.28.11)
;; WHEN: Sat Oct 27 14:42:37 2007
;; MSG SIZE  rcvd: 441

[Astronite:/] [14:42]# dig @ns1.swbell.net sbcglobal.net /all
;; connection timed out; no servers could be reached

; <<>> DiG 9.4.1-P1 < <>> @ns1.swbell.net sbcglobal.net /all
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 2766
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 13
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;/all.                          IN      A

;; AUTHORITY SECTION:
.                       49366   IN      NS      a.root-servers.net.
.                       49366   IN      NS      b.root-servers.net.
.                       49366   IN      NS      c.root-servers.net.
.                       49366   IN      NS      d.root-servers.net.
.                       49366   IN      NS      e.root-servers.net.
.                       49366   IN      NS      f.root-servers.net.
.                       49366   IN      NS      g.root-servers.net.
.                       49366   IN      NS      h.root-servers.net.
.                       49366   IN      NS      i.root-servers.net.
.                       49366   IN      NS      j.root-servers.net.
.                       49366   IN      NS      k.root-servers.net.
.                       49366   IN      NS      l.root-servers.net.
.                       49366   IN      NS      m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.     49366   IN      A       198.41.0.4
b.root-servers.net.     49366   IN      A       192.228.79.201
c.root-servers.net.     49366   IN      A       192.33.4.12
d.root-servers.net.     49366   IN      A       128.8.10.90
e.root-servers.net.     49366   IN      A       192.203.230.10
f.root-servers.net.     49366   IN      A       192.5.5.241
g.root-servers.net.     49366   IN      A       192.112.36.4
h.root-servers.net.     49366   IN      A       128.63.2.53
i.root-servers.net.     49366   IN      A       192.36.148.17
j.root-servers.net.     49366   IN      A       192.58.128.30
k.root-servers.net.     49366   IN      A       193.0.14.129
l.root-servers.net.     49366   IN      A       198.32.64.12
m.root-servers.net.     49366   IN      A       202.12.27.33

;; Query time: 486 msec
;; SERVER: 151.164.1.1#53(151.164.1.1)
;; WHEN: Sat Oct 27 14:43:16 2007
;; MSG SIZE  rcvd: 441

[Astronite:/] [14:43]# dig @ns2.swbell.net sbcglobal.net /all
;; connection timed out; no servers could be reached

; <<>> DiG 9.4.1-P1 < <>> @ns2.swbell.net sbcglobal.net /all
; (1 server found)
;; global options:  printcmd
;; connection timed out; no servers could be reached
[Astronite:/] [14:44]#

I was looking for a fairly basic validation routine to weed out intentional garbage from a form email field. All I came across were either too restrictive or didn’t check what could be checked, so I wrote my own (inspired by various scripts on the web).

// pattern to match email addresses loosely
regex1 = /^[^sn@]*[^sn.@]@[^sn.@][^sn@]*(?=.[^s.n @]+$).[^s.n @]+$/;

// pattern to check for double-dots
regex2 = /(?:..)/;

// get the form value and trim whitespace using jQuery
email_address = jQuery.trim($j("#bus_email").val());

if (!email_address.match(regex1) || email_address.match(regex2))
alert("Please check the email address for accuracy!");

The above regex pattern will look for the following points in an email address:

• Only one @-sign.
• No spaces in the string.
• No newlines/linefeeds in the string.
• One or more characters before the @-sign. The character immediately before @ may not be a period.
• The character immediately after @ may not be a period.
• One or more characters after the @-sign, followed by at least one period followed by one or more characters at the end of the string (for the TLD).
• No two adjacent dots.

The RFC 2822 that defines the email address format is pretty complex, and new TLDs are added from time to time. This script helps to catch typos and randomly entered garbage, but of course has no way to prevent users from entering correctly formed but invalid addresses.

I’m using two separate regular expressions as there doesn’t seem to be a way to negate a string (i.e. two consecutive dots) but only single characters. If someone reading this happens to know how to combine the two regular expressions into one, please let me know!

I’m working on a subscription page which needs to identify the type of the entered credit card number, and display a logo accordingly. I came up with the following script to ID the card:

// get entered cc_number using jQuery
cc_number = $("#cc_number").val();

// remove spaces and hyphens
cc_number = cc_number.replace(/[ -]/g,"");

// initially the card type is unknown
cardtype = '';
$j("#cc_type").val("");

// define card names and their matching patterns
ccArray = {"visa"  : "^4[0-9]{12}(?:[0-9]{3})?$",
      "mastercard" : "^5[1-5][0-9]{14}$",
      "discover"   : "^6011[0-9]{12}$",
      "amex"       : "^3[47][0-9]{13}$"};

// identify the card type
for (key in ccArray) {
	regex = new RegExp(ccArray[key]);
	if (regex.test(cc_number)) {
		cardtype = key;
		break;
	}
}

I validate the card number next (JS routine available elsewhere on the web), and if that’s ok, display the logo using the card type.

Last evening I meant do do some routine updates on some Unix (FreeBSD) servers I maintain.  A new version of libpng had been released so I installed it. Then I recompiled PHP with some parameter changes. Suddenly apache web server on one of the systems started putting out just heaps of text. On closer inspection it turned out to be content of the mime ‘magic’ file that is found in the apache configuration directory. WHAT was going ON?! There were also garbled characters in the end of the "Server Version" line of httpdinfo, around where OpenSSL version info would usually be displayed.

Few web searches later I came across a bug report which shed light on what was happening.  I had upgraded the server to apache httpd 2.2.6 some time ago, but since the garbled characters are probably created from other information that is dependant on the server configuration, the bug "activated" when I changed the configuration slightly. My guess is that as the result of the configuration change the server header on the affected server came to include a line feed or some other disruptive control character that mauled the response header when a client was requesting content.

I resolved the problem by reverting to the previous released version. It’s odd that while the bug report (which can also be found elsewhere on the web) considers this a critical bug the released version remains the same even though this has been fixed in the SVN.  So if you download 2.2.6 and install it using mod_ssl statically, you may run into trouble brought on by this bug.