Re: [Declude.JunkMail] MX, DNS and other weird stuff
Update: NetworkMiner (http://sourceforge.net/apps/mediawiki/networkminer/index.php?title=NetworkMiner) uses the p0f OS fingerprint database and should work for you. -- 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.
Re: [Declude.JunkMail] MX, DNS and other weird stuff
> The link you provide is what I found before: it's a Windows port but it's > uncompiled. Lacking a compiler, I was looking for something precompiled. Ah, didn't notice that -- maybe search for a p0f 2.x binary because that's the last time I used it. I have a 2.04 binary that I'll send you off list. -- 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.
Re: [Declude.JunkMail] MX, DNS and other weird stuff
Hi Sandy, Thanks for the info on TTL. We don't change very often and we're pretty low volume, so 4 hours would be fine. The link you provide is what I found before: it's a Windows port but it's uncompiled. Lacking a compiler, I was looking for something precompiled. Thanks, Ben -Original Message- From: Sanford Whiteman Sent: Monday, November 26, 2012 7:20 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] MX, DNS and other weird stuff > So, two questions: first, is there a version of p0f that runs under > Windows? > I found the Unix version and I found a Windows-port version that is not > compiled (and I haven't used a real compiler in at least ten years). http://packetstormsecurity.org/files/download/109101/p0f-3.03b-win.zip > Second question: what's the popular recommendation for DNS TTL nowadays? I > think I reset mine many years ago after a discussion here among some other > people. "Universal" default TTL? You could say 4 hours. But it depends on the application, the stage you're at with setting up a new host (testing vs. long-term stable), the need for dynamic changes, all, of course, balanced against much load you want/need to shed. I test using 5m TTLs, but also keep 5- and 10-minute TTLs permanently where we have geographic clusters because that's the only way they work. In other cases, I try for one day. Rarely do I use more than a day even when a host has been stable for a long period, even if I could; with our traffic, I don't mind one DNS request per day for each session. For reference, you can look around at high-traffic sites like web analytics. My two analytics packages use 60s and 5m. I think the first one was at my behest because one of their servers kept going down and needing to be null-routed a couple of years ago! -- 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. --- 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.
Re: [Declude.JunkMail] MX, DNS and other weird stuff
> So, two questions: first, is there a version of p0f that runs under Windows? > I found the Unix version and I found a Windows-port version that is not > compiled (and I haven't used a real compiler in at least ten years). http://packetstormsecurity.org/files/download/109101/p0f-3.03b-win.zip > Second question: what's the popular recommendation for DNS TTL nowadays? I > think I reset mine many years ago after a discussion here among some other > people. "Universal" default TTL? You could say 4 hours. But it depends on the application, the stage you're at with setting up a new host (testing vs. long-term stable), the need for dynamic changes, all, of course, balanced against much load you want/need to shed. I test using 5m TTLs, but also keep 5- and 10-minute TTLs permanently where we have geographic clusters because that's the only way they work. In other cases, I try for one day. Rarely do I use more than a day even when a host has been stable for a long period, even if I could; with our traffic, I don't mind one DNS request per day for each session. For reference, you can look around at high-traffic sites like web analytics. My two analytics packages use 60s and 5m. I think the first one was at my behest because one of their servers kept going down and needing to be null-routed a couple of years ago! -- 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.
Re: [Declude.JunkMail] MX, DNS and other weird stuff
Hi Guys, So, two questions: first, is there a version of p0f that runs under Windows? I found the Unix version and I found a Windows-port version that is not compiled (and I haven't used a real compiler in at least ten years). Second question: what's the popular recommendation for DNS TTL nowadays? I think I reset mine many years ago after a discussion here among some other people. Thanks, Ben -Original Message- From: Sanford Whiteman Sent: Friday, November 23, 2012 6:01 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] MX, DNS and other weird stuff 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 rally 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. --- 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.
Re: [Declude.JunkMail] MX, DNS and other weird stuff
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 rally 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.
Re: [Declude.JunkMail] MX, DNS and other weird stuff
Hi, I just now did an nslookup mail.bcwebhost.net on each of our DNS servers, including the now no longer used ns1.xname.org. They all, even that last one, gave the correct IP address of .200. My observations about ns1.xname.org from last week was that sometimes it had the right serial number and sometimes not. I got the impression that someone was reloading it with old records, possibly due to hardware crashing. Anyway, we no longer use that server. So what is the extra complexity that you think we have in our DNS configuration? I wasn't intending to make anything complicated. I have the MX records pointing to A record mail, which points to the .200 IP address. I also have a second A I record mail1 pointing to the same IP. I don't see why any of this should be a problem? Also, did you understand the Comcast guy's reference to subdomain? I know an address such as mail.bcwebhost.net can be a host or a subdomain, but I didn't consider the two phrases to be synonymous. And we don't have any subdomains. Thanks, Ben -Original Message- From: SM Admin Sent: Thursday, November 22, 2012 12:22 PM To: Declude.JunkMail@declude.com Subject: Fw: [Declude.JunkMail] MX, DNS and other weird stuff -Original Message- From: Sanford Whiteman Sent: Thursday, November 22, 2012 11:55 AM To: imailad...@bcwebhost.net Subject: Re: [Declude.JunkMail] MX, DNS and other weird stuff [I'm not subscribed using this address, but it's the only one on my mobile. Pls feel free to forward to the list.] This guy's idea that IN MX is incorrect and "will cause issues" should really get him fired if he's the highest-level tech on this. When you want to set up a proper MX record to catch replies to postmas...@mysmtpserver.example.com, you of course do this by setting up such a record. Otherwise the implication would be that you can never receive mail at the same machine that originated it, but have to come up with some fake additional hostname? Ridiculous. Servers have been set up this way since the old days, when it was common to see addresses like u...@host.example.com (as opposed to just @example.com). Likewise, the idea that an intermediate host that is exempt from anti-spoofing measures can't reroute DNS requests is ridic. This is how our egress filters work: a machine listens using a network monitoring port and sends synthesized replies back if a website is in the block list. (The machine isn't a proxy, it's just listening to the switch's mirroring port in promiscuous mode). However, it is true that you have some complexity in your NSs that you need to work out. If you hadn't asked about interception it wouldn't have been my first guess. When you directly query each NS, what do you get? -- 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. --- 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.
Re: [Declude.JunkMail] MX, DNS and other weird stuff
Hi, First, I want to thank Shaun and Sandy for truly useful replies. Next, below is a response from someone at Comcast – presumably an engineer of some sort. I’m trying to fit together his comments (I find his tone pretty argumentative) with the points made here. For examples, Shaun seems to have shown that Comcast can intercept A-calls and I know that Comcast told me three years ago they intercept some calls, and yet here is this guy claiming it’s impossible. One thing Spencer has correct is a problem with ns1.xname.org. I have secondary DNS services set up with xname and twisted4life and I noticed last week that of the three xname servers (ns0, ns1, ns2), ns1 frequently had an old serial number. One day it would be 131 or something similar, which is about correct, and then the next day it would be 120, which is old. So last weekend I removed all references to ns1 (but kept ns0 and ns2 as secondaries) from our server and the registrar accounts. Really, by the time Spencer wrote to me yesterday afternoon, he shouldn’t have seen any references to ns1.xname.org. Any comments? Thanks, Ben From: Jones, Spencer Sent: Wednesday, November 21, 2012 2:39 PM To: b...@bcwebhost.net Cc: Self, Andrew Subject: FW: DNS zone files for BC Web LLC (Ben Bednarz) Sir, As to what you have below. Your MX record does point to a host name, but then that subdomain that does point to an A record and should ONLY point to an A record has an MX record of its own. This is NOT set up correctly, and WILL create issues. As far as our DNS servers intercepting DNS request traffic. That is not possible. If I make a DNS request it will go to 8.8.8.8, and if that server does not know the answer it goes to one of the 13 ROOT servers, then if the root server does not know the IP it goes to the TLD servers, they know the NS of the domain and go to that IP to get the answer if they do not know it. That is it, our servers can not and would have no way to know what traffic is going across the Comcast network, and then pull in packets that are DNS requests. Tens of thousands of people on Comcast’s network run DNS servers, including me and I do not have an issue. I bind to NASA’s ROOT server and everything pulls from there. I also host a Name Server on the network and never have I had a request answered by another NS. How do you suspect that our servers intercept traffic meant for your IP address, but only yours and only if it is a DNS request, and not any other traffic? Please show the 2 domain query’s below to your DNS expert and see if he feels that is correct that the subdomain points to itself. I am sorry you are having this issue but forward records of zone files we do not host CAN NOT be our issue, and in no way can ANY DNS server intercept a packet meant for another IP address. I see five name servers below for this domain and when I look up mail.bcwebhost.net on ns1.xname.org it gives me the answer of mail2.bcwebhost.net. So I found your issue and as I said it is NOT a Comcast one. Query: bcwebhost.net. Query type: Any record Recursive query: Yes Authoritative answer: Yes Query time: 188 ms. Server name: n/a Answer: bcwebhost.net. 43200 A 173.164.65.201 bcwebhost.net. 43200 NSbcw4.bcwebhost.net. bcwebhost.net. 43200 NSns0.xname.org. bcwebhost.net. 43200 NSns2.xname.org. bcwebhost.net. 43200 NSns1.twisted4life.com. bcwebhost.net. 43200 SOA bcw4.bcwebhost.net. administrator.bcwebhost.net. 133 ; serial 21600 ; refresh (6 hours) 3600 ; retry (1 hour) 2419200 ; expire (28 days) 43200 ; minimum (12 hours) bcwebhost.net. 43200 MX0 mail.bcwebhost.net. bcwebhost.net. 43200 TXT "v=spf1 a mx a:bcw5, a:bcw6, a:mail1 ip4:73.164.65.192/28 -all" Additional: bcw4.bcwebhost.net.43200 A 173.164.65.197 ns2.xname.org. 19A 88.191.64.64 ns1.tw
Re: [Declude.JunkMail] MX, DNS and other weird stuff
Hi Shaun, Thank you for a helpful response. I am CC'ing the list with this so I can get your response posted there. Thanks, Ben -Original Message- From: Shaun Sturby Sent: Wednesday, November 21, 2012 9:01 AM To: imailad...@bcwebhost.net Subject: RE: [Declude.JunkMail] MX, DNS and other weird stuff Hello Ben, (I get Declude mailing list messages but can't reply for some reason) I used the DNSStuff ISP Cached DNS records tester for mail.bcwebhost.net and all the records came back with the 173.164.65.200 IP EXCEPT for Comcast (NJ) which came back with "mail.bcwebhost.net. 0 IN A 68.87.92.78". Note that this is a very short TTL If you connect to that IP address you will see that the URL changes to 'http://selfinstall1.comcast.com/captiveportal/index.html'. Yet a DNS Cache Check using http://dns.comcast.net/ shows the correct .200 IP address. They did change DNS recently as this announcement shows. Comcast recursive resolver IPs (68.87.64.146, 68.87.64.150, and 68.87.64.196) will no longer be supported after October 12, 2012. If you manually configured any of these IPs on your device, please allow DHCP to update your DNS resolver IP addresses or update manually with 75.75.75.75 and 75.75.76.76. It looks like they intercept all A records to allow them to re-direct people to their management portal. I have seen this done before with ISP's like Telus when you need to register the MAC address of your router with your account but typically this uses a RFC 1918 private IP space and not live IP addresses. This is not the solution to your problem but is additional information to help you when you deal with ComCast. Shaun Sturby Technical Services Manager sh...@optrics.com Optrics Engineering | www.Optrics.com Canada: 6810 - 104 Street, Edmonton, AB, T6H 2L6 TF: 877-463-7638Fax: 780-432-5630 USA: 1740 S 300 West #10, Clearfield, UT, 84015 TF: 877-386-3763Fax: 801-705-3150 This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. From: Imail Admin [mailto:imailad...@bcwebhost.net] Sent: Tuesday, November 20, 2012 5:05 PM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] MX, DNS and other weird stuff Hi, This is a question about DNS records and MX records and how I'm getting some weird behavior. It's not strictly speaking Declude issue, but I have a lot of respect for the people that used to hang out here and I'm hoping there's someone around who can give me some insights. Original problem: We use Comcast for our upstream provider. A few years ago, when we switched to them from our telecom provider, they told us that their DNS servers would sometimes intercept DNS calls even though we have our own DNS server. This was supposedly because we only rent a small IP subnet from them. At the time, they had us send copies of our zone records to them so that their DNS servers would have the same information as our DNS server. This worked fine until this fall, when we installed a new mail server on a new IP address. Our DNS server, of course, was updated to reflect this change. However, mail sometimes shows up at the old mail server anyway, in a more or less random pattern. It apprears to me that most of the time when people send mail to us, their mail servers correctly getting the IP address resolved by our DNS server. However, about 25% of the time, it appears that the DNS request from those sending mail servers receives an outdated response from some unidentified Comcast DNS server, resulting in the wrong IP address and the mail ends up going to our old mail server. Suppose, for example, that you send a message to imailad...@bcwebhost.net (the address I'm using here, which is a misnomer since our new mail server is running SmarterMail). The MX records for bcwebhost.net points to mail.bcwebhost.net and the A record mail.bcwebhost.net points to our new server IP (ending in .200). So your email should arrive at our new mail server. However, sometimes it will arrive at the old mail server named mail2.bcwebhost.net (IP ending in .193). The old DNS records had the bcwebhost.net MX record pointing to mail2.bcwebhost.net, for which the A record pointed to .193 (the old server). I've been going in circles for about a month with Comcast on this and th
Re: [Declude.JunkMail] MX, DNS and other weird stuff
Thanks! -Original Message- From: Sanford Whiteman Sent: Tuesday, November 20, 2012 10:37 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] MX, DNS and other weird stuff > Thanks for the info. Is there any problem with using the same host name > for > both MX record and A record? None at all. It is arguably redundant, as the host name will be tried in the absence of an A record, but it is best to keep your zones self-explanatory and not rely on fallback mechanisms. IN MX is fine. -- 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. --- 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.
Re: [Declude.JunkMail] MX, DNS and other weird stuff
> Thanks for the info. Is there any problem with using the same host name for > both MX record and A record? None at all. It is arguably redundant, as the host name will be tried in the absence of an A record, but it is best to keep your zones self-explanatory and not rely on fallback mechanisms. IN MX is fine. -- 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.
Re: [Declude.JunkMail] MX, DNS and other weird stuff
Hi Sandy, Thanks for the info. Is there any problem with using the same host name for both MX record and A record? Although this wouldn't apply if you are writing to me at imailad...@bcwebhost.net because the MX record has no host name but it points to a real host name (mail.bcwebhost.net). However, would there be a problem writing to me at imailad...@mail.bcwebhost.net, since the MX record for mail.bcwebhost.net points to mail.bcwebhost.net, which is an A record? Thanks, Ben -Original Message- From: Sanford Whiteman Sent: Tuesday, November 20, 2012 5:32 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] MX, DNS and other weird stuff > Second problem: > In our new DNS records, I have it set up something like this: > two MX records: > bcwebhost.net MX mail.bcwebhost.net > mail.bcwebhost.net MX mail.bcwebhost.net > one A record: > mail.bcwebhost.net A (IP.200) > Is there any reason I can't have the same name for both an MX and > an A record (in this case, mail.bcwebhost.net)? > The Comcast people claimed this was wrong and that the MX record > should point to an IP address directly instead of a host name (which > I'm sure is wrong). Absolutely, without any doubt, they are wrong. MX RRs MUST point to A (hostname) records per RFC. Not to alias (CNAME) records (though this can function 95% of the time, it is an RFC violation). And *definitely* not to IPs. "This domain name must have as its value one or more address records. Currently those will be A records, however in the future other record types giving addressing information may be acceptable." "The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias." -- both RFC 2181 > They tried to claim that this is the cause of my original problem > but even if they're right about this, then it still doesn't explain the > original problem. I'll reflect on your first problem later. Do not worry at all that they are right here. -- Sandy --- 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. --- 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.
Re: [Declude.JunkMail] MX, DNS and other weird stuff
> Second problem: > In our new DNS records, I have it set up something like this: > two MX records: > bcwebhost.net MX mail.bcwebhost.net > mail.bcwebhost.net MX mail.bcwebhost.net > one A record: > mail.bcwebhost.net A (IP.200) > Is there any reason I can't have the same name for both an MX and > an A record (in this case, mail.bcwebhost.net)? > The Comcast people claimed this was wrong and that the MX record > should point to an IP address directly instead of a host name (which > I'm sure is wrong). Absolutely, without any doubt, they are wrong. MX RRs MUST point to A (hostname) records per RFC. Not to alias (CNAME) records (though this can function 95% of the time, it is an RFC violation). And *definitely* not to IPs. "This domain name must have as its value one or more address records. Currently those will be A records, however in the future other record types giving addressing information may be acceptable." "The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias." -- both RFC 2181 > They tried to claim that this is the cause of my original problem > but even if they're right about this, then it still doesn't explain the > original problem. I'll reflect on your first problem later. Do not worry at all that they are right here. -- Sandy --- 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.
