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

[Kyle Creyts]

bigger question: why allow the UDP 53 to CPE to be answered as if it
were from internal? the external connectivity to port 53 should be
able to be forwarded at the consumer's discretion, but should
certainly not be answered by the DNS proxy!

On Mon, Jun 11, 2012 at 9:46 PM, Vernon Schryver <vjs at rhyolite.com> wrote:
>> From: Chris Adams <cmadams at hiwaay.net>
>
>> Once upon a time, Mark Andrews <marka at isc.org> said:
>> > If we have Attacker -> CPE -> Auth -> CPE -> Target why isn't the CPE
>> > returning answers from its cache?
>>
>> Most of the CPE just run a DNS proxy (e.g. dnsmasq on Linux-based
>> boxes), not a full cache.  Even if they ran a cache, the attack would
>> still be CPE->Target (just not going to another server in-between).  It
>
> Why aren't ISPs blocking UDP source port 53 to the core under their
> old no-servers-for-consumers term of service?
> What is the common consumer ISP current practice for TCP port 25
> at the ISP/core boundary?  If it is one of the many old flavors of
> blocking (e.g. always, prior arrangement, "business service"), why
> can't it be applied to UDP port 53?
>
> How many consumers would object if their "modems" can't answer or
> perhaps even hear UDP port 53 from the outer Internet?
>
> In other words, as with port 25, why must the rest of the Internet
> subsidize some often very big outfits by dealing with abuse that the
> outfits could deal with or at least contain within their own networks?
>
> Why not a blacklist/ACL/whatever similar to Spamhaus' PBL for TCP
> port 25?  For that matter, why not apply the PBL to UDP port 53 on the
> grounds that IP addresses that should never be seen sending email also
> never need outside DNS service?
>
> Of course, blocking consumer port 53 would not be a panacea, but
> it might reduce the proxies available for abuse.
>
>
> Vernon Schryver    vjs at rhyolite.com
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs



-- 
Kyle Creyts

Information Assurance Professional
BSidesDetroit Organizer