[dns-operations] Why would an MTA issue an ANY query instead of an MX query?

Vernon Schryver vjs at rhyolite.com
Tue Jun 12 14:46:12 UTC 2012

> 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

More information about the dns-operations mailing list