On Tuesday, November 23, 2004, 6:40:59 AM, Dallas Engelken wrote:
> Well, the platform is not really the issue here I don't believe... The
> surrounding platform is.  Their SA is running on redhat 7.3, perl 5.6.1.
> They have this Symantec Raptor software firewall running on an NT box,
> and for some reason, it doesn't resolve NS resource record queries.
> Been on the phone with them (symantec) about it, they say they have
> never supported it in the DNS proxy, but in their new version, support
> for it is experimental.  I was like WTF, its just like any other DNS
> lookup.

Oh Joy, a closed, broken resolver implementation....

> So anyways, if you run a  'host -tNS domain.com', you get no answers.
> Not even a NXDOMAIN.   This causes SA to think DNS is not available and
> not run any network tests unless you hard code it.   Even then SURBL
> does not work because it does a NS lookup before pulling the A records.
> Dunno why, that's why I'm asking for feedback here.

> I guess it is possible that even when NS records are properly working on
> a good setup, that NS's are still being pulled for the URI domains that
> are being compared against SURBL.  Whether this is creating false
> positives or not is another thing.  I'm still trying to figure out
> how/if the NS lookups are being used in SA as it pertains to SURBL.  I
> realize the NS's are resolved and compared against SBL, and maybe this
> is why NS's are pulled for all URIs, but its just a DNS lookup that is
> not needed IMHO... And with lots of URIs to lookup, this could cause it
> to take twice as long on the surbl lookups.

It's gotta be something leftover from uridnsbl, which does look
at NS records.  If there's an extra, unnecessary resolution in
there that we can get rid of, I agree it will increase performance!

Perhaps you could open a bugzilla...

Jeff C.

Reply via email to