[dns-operations] No to port blocking! (Was: Why would an MTA issue an ANY query instead of an MX query?
On Tue, Jun 12, 2012 at 03:32:56AM +, Vernon Schryver v...@rhyolite.com wrote a message of 76 lines which said: 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. A strong NO here. Politically, it would be a big nail in Net Neutrality's coffin. 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). I leave these proposals to MAAWG and the Chinese government. ___ dns-operations mailing list dns-operations@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
Re: [dns-operations] Why would an MTA issue an ANY query instead of an MX query?
On Sun, Jun 10, 2012 at 01:25:06PM +0200, DTNX Postmaster postmas...@dtnx.net wrote a message of 37 lines which said: Google is known to be obsessed with latency, for example, so I wouldn't be suprised if they deliberately request ANY and then parse and cache the results for a multitude of uses. But that's speculation. I checked the ANY requests coming into .FR name servers and Google (which should be an important user) does not appear. ___ dns-operations mailing list dns-operations@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
Re: [dns-operations] No to port blocking! (Was: Why would an MTA issue an ANY query instead of an MX query?
On Jun 12, 2012, at 4:14 AM, Stephane Bortzmeyer wrote: On Tue, Jun 12, 2012 at 03:32:56AM +, Vernon Schryver v...@rhyolite.com wrote a message of 76 lines which said: 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. A strong NO here. +lots. Politically, it would be a big nail in Net Neutrality's coffin. 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). And it seems that the huge majority of lying is being performed at the ISP resolvers. See the numerous papers on NXDOMAIN rewriting, Paxfire / Xerocole / Barefruit, etc, one of the better of which is Christian, Nicholas and Vern's Redirecting DNS for Ads and Profit ( http://www.icir.org/christian/publications/2011-foci-dns.pdf ) There are also a huge number of really poorly run (and slow!) ISP recursive resolvers. Having the ability to run your own validating recursive is critical… W I leave these proposals to MAAWG and the Chinese government. ___ dns-operations mailing list dns-operations@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 -- Go on, prove me wrong. Destroy the fabric of the universe. See if I care. -- Terry Prachett ___ dns-operations mailing list dns-operations@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
Re: [dns-operations] Why would an MTA issue an ANY query instead of an MX query?
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. Warm regards Carlos On 6/12/12 11:46 AM, Vernon Schryver wrote: From: Nicholas Suan ns...@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 p...@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 rdobb...@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 bortzme...@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 Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@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 ___ dns-operations mailing list dns-operations@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
Re: [dns-operations] Why would an MTA issue an ANY query instead of an MX query?
Vernon Schryver v...@rhyolite.com wrote: Yes, how is BCP 38 deployment going? Someone on NANOG recently mentioned http://spoofer.csail.mit.edu/ Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Biscay: West or northwest 4 or 5, occasionally 3 later. Moderate. Thundery showers. Good. ___ dns-operations mailing list dns-operations@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
Re: [dns-operations] dns response rate limiting (DNS RRL) patch available for testing
From: Ken A k...@pacific.net
To: dns-operati...@mail.dns-oarc.net
On a authoritative + recursive server, instead of a separate view, we use:
acl trusted { x.x.x.x/z; };
allow-recursion { trusted; };
Is there any way to apply this patch so that it does not affect a
specific acl, such as trusted addresses?
Or, is it recommended/required that we configure separate views to use this?
Separate views are required to apply rate limiting to some but not
all DNS clients, unless you are of the school that holds
authoritative+recursive servers are always utterly wrong. In that
case separate servers are required.
Would it be easy to transform your configuration file to use views via
the include directive? My named.conf files look something like
view insiders {
match-clients { goodnets; };
recursion yes;
include privatezones;
include publiczones;
response-policy {
...
};
};
view outsiders {
match-clients { any; };
recursion no;
include publiczones;
rate-limit { ... };
};
Vernon Schryverv...@rhyolite.com
___
dns-operations mailing list
dns-operations@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
Re: [dns-operations] dns response rate limiting (DNS RRL) patch available for testing
On 6/12/2012 10:16 AM, Vernon Schryver wrote:
From: Ken Ak...@pacific.net
To: dns-operati...@mail.dns-oarc.net
On a authoritative + recursive server, instead of a separate view, we use:
acl trusted { x.x.x.x/z; };
allow-recursion { trusted; };
Is there any way to apply this patch so that it does not affect a
specific acl, such as trusted addresses?
Or, is it recommended/required that we configure separate views to use this?
Separate views are required to apply rate limiting to some but not
all DNS clients, unless you are of the school that holds
authoritative+recursive servers are always utterly wrong. In that
case separate servers are required.
We are a small ISP, and it has not be necessary.
We do run separate caching servers for mail server use.
Would it be easy to transform your configuration file to use views via
the include directive? My named.conf files look something like
view insiders {
match-clients { goodnets; };
recursion yes;
include privatezones;
include publiczones;
response-policy {
...
};
};
view outsiders {
match-clients { any; };
recursion no;
include publiczones;
rate-limit { ... };
};
Yes, only straight forward / minor changes would be needed.
Thanks,
Ken
Vernon Schryverv...@rhyolite.com
--
Ken Anderson
Pacific Internet - http://www.pacific.net
Latest Pacific.Net Status - http://twitter.com/pacnetstatus
___
dns-operations mailing list
dns-operations@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
Re: [dns-operations] Why would an MTA issue an ANY query instead of an MX query?
From: Tony Finch d...@dotat.at Yes, how is BCP 38 deployment going? Someone on NANOG recently mentioned http://spoofer.csail.mit.edu/ http://rbeverly.net/research/papers/spoofer-imc09.html and the last slides in http://rbeverly.net/research/papers/spoofer-imc09-presentation.pdf suggest that relying on BCP 38 deployment is unsound. Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@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
Re: [dns-operations] Why would an MTA issue an ANY query instead of an MX query?
On Jun 12, 2012, at 14:46, Stephane Bortzmeyer wrote: On Sun, Jun 10, 2012 at 01:25:06PM +0200, DTNX Postmaster postmas...@dtnx.net wrote a message of 37 lines which said: Google is known to be obsessed with latency, for example, so I wouldn't be suprised if they deliberately request ANY and then parse and cache the results for a multitude of uses. But that's speculation. I checked the ANY requests coming into .FR name servers and Google (which should be an important user) does not appear. We are seeing them from 74.125.0.0/16, which is a range owned by Google, and they resolve to '*.1e100.net', a domain owned by Google. I do not know why they originate there; from the queries it seems that they may be the resolvers in use by the crawler bots, Gmail, or their open resolvers. I am speculating about the purpose of those requests, of course, but I am not making them up ;-) Also, they seem perfectly well behaved. Cya, Jona ___ dns-operations mailing list dns-operations@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
Re: [dns-operations] Why would an MTA issue an ANY query instead of an MX query?
On Jun 10, 2012, at 23:59, Kyle Creyts wrote: On Sun, Jun 10, 2012 at 2:33 PM, Paul Vixie p...@redbarn.org wrote: I'm afraid we may need more control. If my clients are generating a DDoS attack at 20 responses per second, and I limit this to 5 per second - the CC can get the same effect by mobilizing four times as many clients to do the job. no. the client ip is spoofed. the number of spoofers doesn't matter, when the reflector is looking at both the apparent client ip and the intended response. when most well-provisioned authority servers are running with some kind of rate limiting, then the only way to do a reflective amplifying ddos will be (a) do it through recursive not authority servers, or (b) send a small number of queries to a large number of authority servers, or (c) switch to some other wide area udp such as ntp or snmp or syslog or whatever. Someone mentioned that as soon as the spoofed client is blocked, that a new spoofed client is used... This behavior seems... strange. How quick is this shift? How would one know when to shift the target? The modes I _can_ come up with largely involve having some sort of information about what is reaching the target. (bandwidth or traffic sources) This just leads to more interesting questions about those perpetrating the attacks, and their intent. Is there an obvious way of discerning the time to switch targets that I am missing? Is this a non-interesting topic? From what I've seen, in our specific case, the apparent source address seems to swap every thousands requests or so, with a few exceptions. This is from running dnstop on our auth nameservers for a few hours. HTH, Jona ___ dns-operations mailing list dns-operations@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
Re: [dns-operations] dns response rate limiting (DNS RRL) patch available for testing
* Paul Vixie: Vernon Schryver and Paul Vixie have been working on DNS Response Rate Limiting (DNS RRL) as a patch set to BIND9 (9.9.1-P1 or 9.8.3-P1) and we are ready for broader external testing. It seems rather straightforward to force recursive resolvers to hit the rate limit. Why isn't this a problem? ___ dns-operations mailing list dns-operations@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
Re: [dns-operations] dns response rate limiting (DNS RRL) patch available for testing
On 6/12/2012 8:13 PM, Florian Weimer wrote: * Paul Vixie: Vernon Schryver and Paul Vixie have been working on DNS Response Rate Limiting (DNS RRL) as a patch set to BIND9 (9.9.1-P1 or 9.8.3-P1) and we are ready for broader external testing. It seems rather straightforward to force recursive resolvers to hit the rate limit. Why isn't this a problem? as described in the documentation (http://www.redbarn.org/dns/ratelimits), we do not recommend this for recursive servers at this time. that's a separate problem, and most of the time the fix is to add an ACL to deny off-net or off-campus query traffic. ___ dns-operations mailing list dns-operations@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
Re: [dns-operations] bad infosec economics Re: something paul wrote
On 6/12/2012 12:34 PM, Edward Lewis wrote: At 14:18 + 6/10/12, Paul Vixie wrote: thinking about or acting against ANY is bad infosec economics. This I agree with. Here are some of my knee-jerk, anti-filtering thoughts: 1 - DNS providers are paid to answer questions, not drop traffic. True, to a point. DNS providers are paid to answer good questions. The very first response I get from a customer who receives a large query bill generated from an attack is that they did not want us to answer (i.e. they do not want to pay for) *those* queries. 2 - Rate limits that are not managed eventually become the reason why address blocks are contaminated. Recall the 512 byte limit devices. 3 - Whenever I've considered limiting any pattern I think of a few other patterns that could be substituted in short order if its an APT. I agree that rate limiting is an effective short-term, immediate reaction to events. But once you leave that time horizon they become liabilities - permanent fixes to temporary solutions. Agreed. All filters and/or limits need to maintained over time. However, general rate limits could be set so high that they will never occur in good traffic and exceeding them is clearly bad traffic. The rate for these general limits would vary from infrastructure to infrastructure - 1,000 qps, 10,000 qps, you choose qps (yes, that limit will likely change over time). Another part of this discussion centered around determining the source of the offensive traffic. Again, bad infosec economics comes here - while it is interesting to diagnose, rarely does the search for answers to this question lead to a permanent solution. We've collectively known about Dan Bernstein's use of t=ANY for a decade and we know he's reluctant to listen to calls for change nor make the change. 10+ years. Nothing's changed - except the newest younger crowd learns about this old tale. Nothing has changed and qmail's installed base remains about the only reason that we haven't thrown ANY queries onto the refuse pile. Since we can't disregard ANY queries, it would be just super if we could stop throwing every new DNS feature into the zone apex, continually bloating further the ANY query responses for the apex of domains. Just a thought. The suggestion to limit EDNS0 to a smaller size might be the first step to decent (but still suboptimal) improvement. Guessing that the malicious data seeks two things - a large, valid and reputable chunk of data to throw at a victim and an reputable and capable address from which to throw it, perhaps at least limiting the data size in a way that does not cause choking to legitimate uses is a good thing. +1 I've said in presentations that the same fertile ground that lets DNS be the beast that it is also enables DDoS (rooted in the nature of UDP). The fact that we are still talking DDoS prevention many years after we started is empirical evidence that DDoS is a hard problem to solve. Rate limiting is one technique, not a cure-all. If it was, we'd not be talking about it in 2012. So, use it with caution. The only real solution is for bandwidth providers to filter garbage at their edges. Unfortunately, there is little/no economic incentive for them to do this and (just like your 1. above) they posit that: 1. Bandwidth providers are paid to route packets, not drop traffic. There is also, of course, little consensus on the definition of garbage. However, if nothing foundational changes, then we will have the exact same discussion in 2022. PS - One possibility, instead of simply not responding, send back rcode=REFUSED. I agree with Tony Finch's reply - TRUNC is better than REFUSED -DMM ___ dns-operations mailing list dns-operations@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
Re: [dns-operations] query source port 53, was Re: Why would an MTA issue an ANY query instead of an MX query?
In message alpine.lsu.2.00.1206121230490.2...@hermes-2.csi.cam.ac.uk, Tony Fi
nch writes:
Mark Andrews ma...@isc.org wrote:
Perhaps because it is a legitimate, though unwise, client source port
that is in lots of old configurations.
listen-on { internal address; };
query-source * port 53;
I did this back in the 1990s because it worked around occasional interop
problems, I think caused by over-enthusiastic firewall configurations that
thought all DNS (queries and responses) should be on port 53. Several
years ago I found that things had changed and the popular over-
enthusiastic firewall configuration requires DNS query source ports to be
greater than 1023.
Both firewall configuration are broken. You don't look at source
ports if you are offering a service.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
dns-operations mailing list
dns-operations@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
Re: [dns-operations] query source port 53,
In message 201206122327.q5cnru5s077...@aurora.sol.net, Joe Greco writes:
In message alpine.lsu.2.00.1206121230490.2...@hermes-2.csi.cam.ac.uk, Ton
y Fi
nch writes:
Mark Andrews ma...@isc.org wrote:
Perhaps because it is a legitimate, though unwise, client source port
that is in lots of old configurations.
listen-on { internal address; };
query-source * port 53;
I did this back in the 1990s because it worked around occasional interop
problems, I think caused by over-enthusiastic firewall configurations tha
t
thought all DNS (queries and responses) should be on port 53. Several
years ago I found that things had changed and the popular over-
enthusiastic firewall configuration requires DNS query source ports to be
greater than 1023.
Both firewall configuration are broken. You don't look at source
ports if you are offering a service.
Sure you can. And sometimes do. That's what the whole privileged port
thing is about, right? Sometimes it is desirable to constrain the
possibilities for various reasons.
Even then you don't examine it in the firewall as those service
still accept connections from non-reserved ports. You just get
extra functionality if you come from a known machine using a source
port less than 1024.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
dns-operations mailing list
dns-operations@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
Re: [dns-operations] query source port 53,
In message 201206130045.q5d0joit078...@aurora.sol.net, Joe Greco writes:
In message 201206122327.q5cnru5s077...@aurora.sol.net, Joe Greco writes:
In message alpine.lsu.2.00.1206121230490.2...@hermes-2.csi.cam.ac.uk,
Ton
y Fi
nch writes:
Mark Andrews ma...@isc.org wrote:
Perhaps because it is a legitimate, though unwise, client source po
rt
that is in lots of old configurations.
listen-on { internal address; };
query-source * port 53;
I did this back in the 1990s because it worked around occasional inte
rop
problems, I think caused by over-enthusiastic firewall configurations
tha
t
thought all DNS (queries and responses) should be on port 53. Several
years ago I found that things had changed and the popular over-
enthusiastic firewall configuration requires DNS query source ports t
o be
greater than 1023.
Both firewall configuration are broken. You don't look at source
ports if you are offering a service.
Sure you can. And sometimes do. That's what the whole privileged port
thing is about, right? Sometimes it is desirable to constrain the
possibilities for various reasons.
Even then you don't examine it in the firewall as those service
still accept connections from non-reserved ports. You just get
extra functionality if you come from a known machine using a source
port less than 1024.
So then you do understand the reason why someone might do this with DNS.
No. The DNS isn't a 'r*' protocol. If you are advertising a
nameserver to the world is the zero, nada, no, none justifable
reason to look at the source port of the query. You have no knowledge
about the client. Even the 'r*' protocols, for all the flaws in
the security model, only paid attention to the source port when the
connection came from trusted machine otherwise they ignored the
port and requested that you login.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
dns-operations mailing list
dns-operations@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
