Nope - I tested this some time ago - mail delivery from certain large providers
will fail as they don't do MX requests, even if the ANY fail's it seems.
-Original Message-
From: dns-operations-boun...@lists.dns-oarc.net
[mailto:dns-operations-boun...@lists.dns-oarc.net] On Behalf Of
Clue appreciated, thanks!
---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com
Luck is the residue of opportunity and design.
-- John Milton
Clue appreciated, thanks!
One word: qmail. Google qmail dns any query.
It would actually be *good* to stop answering the ANY queries if that
would force qmail installations do something about this behavior. But
I don't have high hopes...
Steinar Haug, Nethelp consulting, sth...@nethelp.no
ANY queries, in my *limited* experience, have had higher latencies by an
order or two of magnitude. but that was mostly when I was doing open
resolver research a year or two ago.
On Jun 10, 2012 7:25 AM, DTNX Postmaster postmas...@dtnx.net wrote:
On Jun 10, 2012, at 12:33, Dobbins, Roland wrote:
On Sun, Jun 10, 2012 at 04:24:51AM -0700,
Kyle Creyts kyle.cre...@gmail.com wrote
a message of 65 lines which said:
are there legitimate reasons to continue supporting ANY queries?
They are very useful for debugging. I would regret their
disappearance. What about forcing TCP for ANY requests
On Sun, 2012-06-10 at 12:59 +0200, Jan-Piet Mens wrote:
If that's it, then would asking djb to change its behavior
ROFL. Ask DJB to change its behavior? Good luck with that. ;-)
Indeed, since he publicly declared qmail open source and abandoned back
in, ohh, 2008 IIRC
(even
On 2012-06-10 8:45 AM, Jim Reid wrote:
On 10 Jun 2012, at 09:19, DTNX Postmaster wrote:
The iptables rules mentioned in the first comment work well for us
Well for starters, I [dw]on't use Linux. The server runs FreeBSD.
what f-root has done for the last ten years (also on freebsd) is:
add
On 2012-06-10 12:59 PM, Patrick W. Gilmore wrote:
A single ANY query for a domain gives you the NS, MX, TXT and SPF
records, plus any A/ record present. At scale, who knows, the
reduction in number of queries probably adds up.
It strikes me as laziness and cost-shifting.
If you need to
So if enough people stopped answering users of qmail might change the field,
even if the author won't change the code.
--Michael (from an iPhone)
On Jun 10, 2012, at 5:29, sth...@nethelp.no wrote:
Clue appreciated, thanks!
One word: qmail. Google qmail dns any query.
It would actually
Den 10. juni 2012 kl. 16:11 skrev Paul Vixie:
On 2012-06-10 8:45 AM, Jim Reid wrote:
On 10 Jun 2012, at 09:19, DTNX Postmaster wrote:
The iptables rules mentioned in the first comment work well for us
Well for starters, I [dw]on't use Linux. The server runs FreeBSD.
what f-root has done
One word: qmail. Google qmail dns any query.
thinking about or acting against ANY is bad infosec economics. any
investment along those lines is wasted, since ANY is merely the low
hanging fruit, and an attacker need only switch over to TXT or RRSIG or
NSEC to get a similar amplification
SMTP predates the MX rrtype. In RFC821, c...@stdlib.net means
connect to the host stdlib.net and host records (e.g. A and now
) are what matters [*]. RFC1123 and later RFC2821 regularised
the MX rrtype for mail routing, obviating the need for the host
records at a mail domain.
However, the
On Jun 10, 2012, at 16:23, Paul Vixie wrote:
On 2012-06-10 12:59 PM, Patrick W. Gilmore wrote:
A single ANY query for a domain gives you the NS, MX, TXT and SPF records,
plus any A/ record present. At scale, who knows, the reduction in
number of queries probably adds up.
It strikes
Not supporting
ANY queries would also have side effects - simply dropping the
query maks the authoritative server appear unresponsive to the
recursive server initiating the query.
Note that in many cases the server receiving the ANY query is a
recursive server, not an authoritative server.
limiting EDNS responses to 1460 bytes, as suggested [by me], will
block quite a few legitimate replies (not just ANY replies).
Why? The response will be sent, just with a TC bit, and the client, if
it is not lying about its IP address, will retry with TCP. No
blocking.
Agreed, this
Hi Roland.
At 03:33 10-06-2012, Dobbins, Roland wrote:
If that's it, then would asking djb to change its behavior so as to
issue TXT requests to look for SPF records make sense?
There is a thread at
https://lists.dns-oarc.net/pipermail/dns-operations/2009-October/004542.html
about whether
On Jun 10, 2012, at 1:24 PM, Kyle Creyts wrote:
So, list, I am young and foolish. Aside from being in the RFC, are there
legitimate reasons to continue supporting ANY queries?
Yes, you don't have that power. If you issue an RFC that ANY queries are
deprecated, nothing will happen. People
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
On Jun 10, 2012, at 1:17 PM, Stephane Bortzmeyer wrote:
On Sun, Jun 10, 2012 at 12:47:22PM -0700,
Paul Hoffman phoff...@proper.com wrote
a message of 9 lines which said:
It would be useful if there was a somewhat-up-to-date document that
we can point DNS operators towards that covers
It seems to me that it might be pertinent to split this discussion
into clear threads. There are several different attack patterns being
discussed here, and it is my opinion that they have distinct and
different solutions, and may merit separated discussion, or at least
identification.
The
20 matches
Mail list logo
