Thank you, Comcast.

Curtis Maurand cmaurand at
Fri Feb 26 16:04:49 UTC 2016

I run my own resolver from behind my firewall at my home.  I don't allow 
incoming port 53 traffic.  I realize there's not a lot of privacy on the 
net, but I don't like having my dns queries tracked in order to target 
advertising at me and for annoying failed queries to end up at some 
annoying search page.

On 2/26/2016 9:18 AM, Maxwell Cole wrote:
> I agree,
> At the very least things like SNMP/NTP should be blocked. I mean how many people actually run a legit NTP server out of their home? Dozens? And the people who run SNMP devices with the default/common communities aren’t the ones using it.
> If the argument is that you need a Business class account to run a mail server then I have no problem extending that to DNS servers also.
> Cheers,
> Max
>> On Feb 26, 2016, at 8:55 AM, Mikael Abrahamsson <swmike at> wrote:
>> On Fri, 26 Feb 2016, Nick Hilliard wrote:
>>> Traffic from dns-spoofing attacks generally has src port = 53 and dst port = random.  If you block packets with udp src port=53 towards customers, you will also block legitimate return traffic if the customers run their own DNS servers or use opendns / google dns / etc.
>> Sure, it's a very interesting discussion what ports should be blocked or not.
>> This mentions on page 3.1, TCP(UDP)/25,135,139 and 445. They've been blocked for a very long time to fix some issues, even though there is legitimate use for these ports.
>> So if you're blocking these ports, it seems like a small step to block UDP/TCP/53 towards customers as well. I can't come up with an argument that makes sense to block TCP/25 and then not block port UDP/TCP/53 as well. If you're protecting the Internet from your customers misconfiguraiton by blocking port 25 and the MS ports, why not 53 as well?
>> This is a slippery slope of course, and judgement calls are not easy to make.
>> -- 
>> Mikael Abrahamsson    email: swmike at

Best Regards
Curtis Maurand
Xyonet Web Hosting
mailto:cmaurand at

More information about the NANOG mailing list