It's not really a complex setup unless you have (or had) a secondary that is capable of reloading with bad records. It shouldn't be possible to have a proper secondary that does this, as it should use either standard *XFR methods or some proprietary sync mechanism at startup to get the right records (incl serial #) from its primary.
Since your tests show all of your possible NSs giving the right results when q'd directly (although you can't be sure it's 100% of the time if the secondaries are outside your control) the "good" news is now you are justified in using p0f to try to see if something is sitting in-between your Comcast boxes and the outside world. You could set up a box the just sends a barrage of queries to the Comcast NSs and pipes the p0f results to a file, then scan it after a day and see if anything looks amiss. Re: subdomain v. hostname, as mail.bcwebhost.net has an IP address assigned to it, it should be considered a hostname. If the label had only NSs,, it would be considered a subdomain that could have child hostnames. I have no idea what the Comcast dude is saying about "subdomain that has an MX." If it were a delegated subdomain, that might be notable, but it's not. One other thing: is it possible that you have a reeeeally long TTL that you set at some point that might still send people to the bad/strange server? You could have mistyped and have 30 days to wait it out.... -- S. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to imail...@declude.com, and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
