[dns-operations] Why would an MTA issue an ANY query instead of an MX query?
Carlos M. Martinez
carlosm3011 at gmail.com
Tue Jun 12 15:14:33 UTC 2012
I don't really think that is the ISPs business to 'correct' 'unwise'
behaviour on the part of equipment. The devil is in the details. What
does an ISP mean by 'correct' or what is 'unwise' ?
Whatever filtering you can currently seem a 'good idea' quickly becomes
abused, misunderstood and applied like a wrecking ball all over the
place. For a taste of this one only needs to look at what ISPs and
network operators do nowadays regarding ICMP filtering.
It's a very slippery slope, one I wouldn't like the industry to take.
On 6/12/12 11:46 AM, Vernon Schryver wrote:
>> From: Nicholas Suan <nsuan at nonexiste.net>
>> However since 53/udp is stateless, and 25/tcp is not, you cast a much
>> wider net blocking port 53 inbound than you do with port 25. At least with
>> port 25 you can look at the tcp flags and recognize this is a new connection
>> without keeping connection state.
> Either I don't understand or that's a restatement of the claim that
> DNS clients commonly send from port 53. As far 25/TCP blocking is
> concerned in this context, the TCP flags only let you figure out whether
> a TCP segment is to or from a server, exactly as port 53 vs. not-53 often
> does for DNS/UDP.
> People have been repeating the "DNS clients send from port 53" claim
> for almost as long as others talking about blocking port 25. Is
> it valid for consumer ISP customers? I bet not, but I don't know.
> ] From: Peter Koch <pk at DENIC.DE>
> ] > Joe and Joan should be using their ISP's validating, load balancing,
> ] > well (or at least somewhat) maintained DNS servers, just as they should
> ] > be using their ISP's SMTP systems.
> ]I'm sure my government loves you already. Why not cripple the Internet further
> ] since what else do Joe and Joan need but TCP port 80, where the rest
> ] (or even anything at all) can go through the ISP's web proxy?
> Haven't you heard?--Everything is moving to The Cloud.
> Are you claiming that Joe and Joan Sixpack would ever knowingly run
> their own DNS servers? In the real world, Joan and Joe Sixpack have
> no real control over the software on their computers. They don't even
> want it or they'd not tolerate the new silent updates from ISPs, Apple,
> Microsoft, Google, Adobe, Mozilla, etc.
> Besides, local DNSSEC validating, regardless of ISP port 53 blocks,
> is the fix for those concerns. Please think how easy it is for anyone
> in the path of your port 53 packets to run a covert proxy. Do you
> doubt that there are many illicit translucent DNS proxies? What is a
> DNS resolver besides a licit, somewhat transparent proxy?
> Consider how easy it is for an ISP to adjust its routers to redirect
> user port 53 packets to a resolver with an RPZ zone.
> Recall DNSChanger and the soon to end DNSChanger remediation effort.
> } From: "Dobbins, Roland" <rdobbins at arbor.net>
> } The *real* problem is, to beat the dead horse yet again, lack of
> } anti-spoofing deployment at the access edge. The rest of this discussion
> } is tactical.
> Yes, how is BCP 38 deployment going? That's not rhetorical. Somewhere
> recently I saw that question yet again but no real answers.
> Are consumer ISPs finally deploying BCP 38 and/or blocking port 25?
> (other than by out-sourcing the port 25 blocking by expecting spam
> targets to use Spamhaus' PBL)
>> From: Stephane Bortzmeyer <bortzmeyer at nic.fr>
>> Also, many ISP have lying resolvers and customers
>> should NOT use them. From a security perspective, it would be
>> catastrophic since the last mile is not secured, so the only safe way
>> to run DNSSEC is to validate locally (which requires access to port 53
>> if the ISP resolver is lying).
> Either that is wrong or DNSSEC is useless, because sending to a packet
> toward a distant DNS servers does imply that it will answer. Instead
> I think local DNS validation consists of requesting signature and key
> RRs and checking the chain of public key signatures starting from the
> root key that you somehow previously got out of band.
> Do hotels capture and 'improve' your DNS requests to distant servers
> like HTTP? If you care, hotels you use manual IP addresses, laptop
> DNSSEC valdation, HTTPS, ssh (perhaps over port 443), and/or VPNs.
> Vernon Schryver vjs at rhyolite.com
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> dns-jobs mailing list
More information about the dns-operations