rpz2+rl patches
rpz2+rl patches for BIND 9.8.6 and 9.9.5 are available on the web page linked from "Patch files for BIND9" on http://www.redbarn.org/dns/ratelimits I did not make the rpz2-only or rl-only variations. That page of patches is more than a year old but refuses to die. Let's hope that 9.9.10 drives a stake through its heart by its inclusion of the contents of those patches. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS passthrough on no explicit result?
> You have records which absolutely > need to be public: SPF, MXs--mail won't work otherwise. I hope I misunderstood the intended meaning or context of those words, because their literal, context free meaning that SPF and MX records are required by SMTP is wrong. SPF might be considered required by unsolicited or semi-solicited bulk mail senders to help large scale "free" mailbox providers gauge the legitimacy of mail advertisements. Otherwise SPF is *not* required. As proof consider both this message and the DCC mailing lists (i.e. old school solicited bulk mail.) In some cases SPF harms SMTP delivery, especially when combined with DMARC. Because I'm in neither the email advertising business nor the large scale "free" mailbox businesses, the only unambiguous use I've found for SPF records is to try to prevent mail. I publish SPF RRs for some domains that send no mail in order to reduce NDRs or "bounces" of forged mail from bad SMTP servers (mail receivers) that fail to validate SMTP Rcpt_To values during the SMTP transaction. The case for MX records being required for SMTP is clear. In the absense of an explicit MX record, the standards require SMTP clients (mail senders) to infer an implicit MX from derived A or records. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RPZ2 patch for 9.9.4-release -- can I use the -rc1 patch?
> From: jen...@promessage.com > I need to maintain the current server's RPZ2 functionality in 9.9.4. > > Looking, there's no patch there for the 9.9.4 release. > > There IS a 9.9.4-rc1 patch. > > Can/should I apply the 9.9.4-rc1 patch to 9.9.4-release sources? or do I > need to wait for a new version patch? > > I asked in #irc -- they suggested I bring this question back here. The 9.9.4-rc1 patch does not apply cleanly to 9.9.4. I'm working on a new set of RRL/RPZ2/RRL+PRZ patches. When I finally finish, I will announce them in the RRL and RPZ mailing lists. I've promised to finish this week. Please see http://www.redbarn.org/dns/ratelimits http://lists.redbarn.org/mailman/listinfo/dnsrpz-info http://lists.redbarn.org/mailman/listinfo/ratelimits Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RRL probably not useful for DNS IP blacklists,
> From: Noel Butler > you clearly have a bias set-in-concrete mindset about rbldnsd, maybe you > and its author hate each others guts, I dunno, dont care, our decision > is based on real world live usages, tests, and experiences, for over ten > years of using rbldnsd and twenty with bind, so Vernon I suggest the > only person here who is "hand wringing" as you put it, is yourself, > whatever your problem is, get over it. To see who else has been wringing their hands for years about IPv6 spam, consider the obvious https://www.google.com/search?q=dnsbl+ipv6+spam Notice the reference to "a B-tree data structure" in http://www.spamhaus.org/organization/statement/012/spamhaus-ipv6-blocklists-strategy-statement The problem is since essentially very IPv6 host has at least 281474976710656 and often 18446744073709551616 IPv6 addresses available, a spammer can use a unique IPv6 address with every mail message. No DNSBL can contain 2^64 IPv6 /128 address to cover a single PC in a botnet, not to mention the 2^72 or 2^80 IPv6 addresses of a lawful spammer with its own IPv6 allocation. The obvious solution is to put wildcards into your IPv6 DNSBL, which works fine for the authorities for your IPv6 DNSBL. But what happens at most SMTP servers (mail receivers) that use local, recursive DNS resolvers that cache DNSBL data from authorities? Every spam SMTP transaction will involve a unique SMTP client IPv6 address that the recursive DNS resolver will fetch from the DNSBL authority and cache locally. That is fine for the first few thousand or maybe million SMTP transactions. If you run a small mail+DNS system that sees only 100K mail transactions per day, you can stop reading. If you run a system that handles millions or billions of SMTP transactions per day, and you recall that even NXDOMAIN no-entry DNSBL results must be cached, you'll probably do one of: 1. give up on DNSBLs. 2. make all of your recursive DNS servers for your SMTP servers authoritative for your chosen DNSBLs. 3. try to change the DNS protocol to include something like wildcards on the wire instead of only as abbreviations in zone files, such as John Levine's B-tree proposal. You can't do #2 with simple rbldnsd configurations, because your SMTP servers require full featured recursive DNS servers that support wildcards, MX RRs, DNSSEC, etc. You might use forwarding for the DNSBL zones, but it's going to be fragile and complicated. Even if you already didn't know practically impossible it it is to make even tiny changes to the DNS protocol, the fact the I-D for DNS B-trees expired 2.5 years ago ought to be a clue that #3 is not a real alternative. My solution is #2 but with real DNS servers with local copies of DNSBLs maintained with IXFR. There are obvious problems with that, starting with the tree of authorities for those IXFRs, but I think it's better than #1 and not as completely and utterly hopeless as #3. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RRL probably not useful for DNS IP blacklists,
> From: Noel Butler > We used to run our int bl on bind, it was a resource hog compared to > rbldnsd > But there is no way in hell, I'd run rbldnsd on anything else other > than a BL, > > IMO, they are both designed to do different things, and they both do > their own thing, much better than the other because if it. 10 years ago rbldnsd was the right choice for a DNSBL. Today rbldnsd is an egregious mistake engrained the uninformed and unexamined preconceptions and prejudices of DNSBL users. The hand wringing about IPv6 spam ending the usefulness of DNSBLs and the proposals to put B-trees into the DNS wire protocol make only if you assume that rsync is the only way to distribute DNSBL data and that wildcards cannot be used in DNSBLs because rbldnsd didn't like them and that rsync is the only way to distribute DNSBL data. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RRL probably not useful for DNS IP blacklists,
> From: Tony Finch > > As a matter of interest, if one had a DNSBL with 5.5 million entries > > (i.e. 5.5 million IPs): > > > > 1) What needs to be done to rewrite that to a BIND zone? > > 2) What sort of machine would be required to load that zone? > > 3) How long would it take to load into BIND? > > I did a quick test. Generating and parsing the zone in text format took > about 80s wall time; loading the raw zone file took 30s. In both cases > named-checkzone used about 1.25GB RAM. > > I don't have enough RAM on this machine to run dnssec-signzone in a > reasonable length of time - it goes into swap death after 3GB. It's convenient that with binary zone files and the dynamic update protocol, loading from text (or signing a whole zone) is not something you need to do every hour on the hour. I assume you'd use NSEC instead of NSEC3 when signing, since protecting a DNSBL from zone walking makes little more sense than protecting a reverse zone. By the way, how much smaller would that DNSBL be if it could use wildcards? I suspect a real (as opposed to synthetic) DNSBL has a lot of repetition in all except the last labels. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RRL probably not useful for DNS IP blacklists, was Re: New Versions of BIND are available (9.9.4, 9.8.6, and 9.6-ESV-R10)
> From: Eliezer Croitoru > > Major DNSBL providers have years since limited anonymous clients for > > business or other reasons. For example, I think Spamhaus limits > > anonymous clients to fewer than 3 queries/second. > and I doubt they use RRL in the application level.. > I assume they limit that on either IPTABLES\FW level. The only technical reason I know that might stop Spamhaus and the Spamhaus mirrors from using RRL to throttle anonymous DNSBL clients is the lingering enthusiasm for RBLDNSD and rsync in the DNSBL community. RBLDNSD+rsync made sense before the (de facto standard) DNS protocol had incremental zone transfers and updates. It is a bug today. That use of RBLDNSD+rsync has become a serious problem. Among the problems it causes are: - IPv6 DNS server caches If IXFR were used to distribute DNSBL data, then wildcards for cover entire CDIR blocks (both IPv4 and IPv6) could be published and there would be no IPv6 cache explosion issue. - Authentication RBLDNSD doesn't support DNSSEC, so that any of the many men in the middle between small DNSBL clients and the servers they use can "improve" passing DNSBL data. I know nothing about how Spamhaus and the Spamhaus DNSBL mirrors control access, but I doubt they use firewalls except to completely block persistently abusive clients. Firewalls trying to rate limit need to keep state, and stateful firewalls are infamous for collapsing under the weight of irrelevant state when someone tries to apply them to this kind of problem. > What is the way to provide DBSBL using bind?? BIND and other full featured DNS implementations are used to answer DNSBL requests as well as requests for records in larger and more frequently changing DNS zones than any of the DNSBLs. Consider what happens in the major gTLDs today. Things have changed since RBLDNSD appeared and when a change to example.com took weeks. Consider the fact that some Spamhaus DNSBL zones are available as RPZ zones. See https://www.google.com/search?q=dns+rpz > I was looking for something like that but I am sure a dynamic DB is > needed for the task right? Large DNSBLs are not very dynamic, because they have relatively few changes per day. From another perspective, with the popularity of dynamically updating forward and reverse DNS zones as end-user IP addresses changes, why isn't the the machinery in any full featured DNS implementation a "dyanamic DB"? The term "database" should not imply "sql" or even "relational." Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RRL probably not useful for DNS IP blacklists, was Re: New Versions of BIND are available (9.9.4, 9.8.6, and 9.6-ESV-R10)
> From: Shane Kerr
> With a 50% packet loss and 3 retries you'll have about 1 in 16 lookups
> fail, right? If you've got enough legitimate lookups going on to
> trigger RRL then you're going to get lots of failures.
If 6% is "lots", then yes.
> One workaround for this is to set SLIP to 1. I know Vernon recommends
> against that, but personally I don't think there is any downside.
Before using SLIP=1, please read
http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/
If you need RRL, then RRL with SLIP=1 is a bad idea.
With SLIP=1, your mail system will be slowed by asking with UDP, getting
a TC=1 response, and using TCP. With SLIP=1 instead of excempt{} or views,
your DNS server will also waste lots of computron counting responses
to your own computers and answering with TC=1
You need to use views and/or ACLs to allow recursion for your own
computers but deny it to strangers. So using 'excempt{}' or views to
excempt your own computers from RRL should be painless.
> > limit NXDOMAIN responses to /24 for zen.spamhaus.org ,=20
> This doesn't indicate that anything actually failing for the querying
> hosts, just that they are issuing a lot of queries.
indeed.
> I think the actual issue is that for DNS IP blacklists (or whitelists)
> RRL is probably harmful. Many or even most queries to those servers
> will result in the same NXDOMAIN response. This is expected and desired
> behavior, but RRL interprets this as potential abuse.
>
> While the fallback to TCP (combined with my recommendation of SLIP 1
> above) will mean that service will continue without problem, one reason
> that DNS was chosen for such services is that it is very lightweight,
> and forcing traffic to TCP is an anti-goal. :)
>
> Probably you should disable RRL for servers that are primarily used for
> IP-based blacklists (or whitelists).
That is reasonable if you ensure that those DNS servers are not available
to the bad guys by putting them behind firewalls, using views or ACLs,
or whatever. And again, those defenses against unauthorized recursion
can be used to apply RRL only to the outsiders.
The potential RRL problem is when you provide high volume DNSBL service
over the open Internet to DNS clients that are not authenticated.
However, that is unlikely to be a worry, because providing DNSBL
services over the open Internet is dubious idea for unrelated reasons.
Major DNSBL providers have years since limited anonymous clients for
business or other reasons. For example, I think Spamhaus limits
anonymous clients to fewer than 3 queries/second.
Vernon Schryverv...@rhyolite.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: New Versions of BIND are available (9.9.4, 9.8.6, and 9.6-ESV-R10)
> From: Noel Butler > now, I never ran it as patches, my policy is only use official upstream > sources, so my first play around was with 9.9.3.b2 I think it was. BIND 9.9.4 and its immediately preceding "beta" and "release candidate" releases are the first versions of BIND that were not "patched." Some third parties including FreeBSD and a Linux distributor added RRL patches to their versions, but those BIND+RRL versions differed from any other version of BIND+RRL patch only by someone else having applied the patch. > plenty of delayed mail - hostname lookup failures (mostly because of > URI/DNS BL's), so it certainly works as intended :) That sounds unrelated to RRL. Again, RRL affects standards compliant DNS clients no more than a 50% packet loss rate on the path from the DNS client and to the server. If your mail system suffered hostname lookup failures, then I think something else was broken. Recall that the design goals of RRL include contining to provide services to legitimate DNS clients at the same IP address as are being forged in a DNS reflection DoS attack. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: New Versions of BIND are available (9.9.4, 9.8.6, and 9.6-ESV-R10)
> From: Noel Butler
> I have been using this since 9.9.4bx, and although documentation is/was
> lacking at the time, so there might be a whitelisting somewhere , but in
> its absence, I highly advise against using RRL if your mail servers use
> those DNS servers
I believe there been no significant changes to the RRL documentation
since long before any versions BIND 9.9.4.
BIND RRL has had whitelisting for trusted DNS clients that send repeated
DNS requests since early days, long before any version of BIND 9.9.4.
Look for 'exempt-clients{address_match_list};' in either the ARM that
comes with 9.9.4 or via the old link labeled "Draft text for BIND9
Administrators Reference Manual (ARM) describing DNS Response Rate
Limiting (RRL)" on the original ratelimits web page at
http://www.redbarn.org/dns/ratelimits
[ rate-limit {
...
[ exempt-clients { address_match_list } ; ]
...
} ; ]
...
DNS clients within a view can be exempted from rate limits with
the exempt-clients clause.
RRL is not recommend for recursive DNS servers, because in theory
it could squelch repeated requests from legitimate DNS clients
without caches such as some SMTP servers.
However, I do not recall reports of significant real, as opposed to
anticipated or minor problems with RRL on recursive DNS servers. The
worst that should happen is that legitimate clients will be slowed,
such as SMTP servers (mail receivers) receiving spews of spam or SMTP
clients (mail senders) spewing spam or without required DNSBL whitelisting.
A legitimate DNS client that is squelched by RRL will time-out every
other repeated request and (with the default SLIP=2) retry with TCP.
What problems did you see with your mail system and your recursive DNS
server with RRL?
Vernon Schryverv...@rhyolite.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND Performance with Huge RPZ
> From: Noel Butler > > BIND9 releases can be with the BIND RRL patches by following the link > > labeled "Patch files for BIND9" on http://www.redbarn.org/dns/ratelimits > > > > Both of those versions are or will be in official BIND releases. > > I've lost track of which releases have or will have which of those > > two RPZ sets of performance improvements. > > 9.9.4 will have them Not exactly. Checking source finds the min-ns-dots speed-up in 9.8.5-P1, 9.9.3-P1, and 9.9.4b1 and so in 9.9.4. On the other hand, I think the more substantial set of RPZ speed improvements for multiple policy zones is in none of those and so will not be in 9.9.4. My bet would be on 9.10 along with client IP address triggers and "drop" and "truncate" actions. I think the multiple zone speed-up is in the subscription-only 9.9.4-S and so will be in 9.9.4-S1. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND Performance with Huge RPZ
> From: Steven Carr > It's very difficult to predict the impact on performance in general. Yes, the reasonable tactic is to build a representative list of queries from your query logs and use queryperf to hit a test server with those 800K policy zone labels. > But > every query will hit the RPZ zone to be checked against, so make sure you > have enough RAM to hold all 800k records in memory then that will > significantly speed things up. RAM for all 800K records would be sufficient, but might not unnecessary. Names in policy zones are kept in the same kind of red/black trees that are used for ordinary DNS zones, because policy zones are ordinary BIND9 DNS zones. Policy zone IP addresses are kept in radix or patricia trees. Sufficent RAM is the size of the working set. For example, if you have 800K labels below obscure.example.com and almost never resolve any of them, then keeping them in RAM would not help your server's average performance. > The guidance figures that I've seen banded around by a BIND based DNS > appliance is that it will have ~30% impact on query performance per RPZ > feed that has to be looked up against. RPZ performance with zones with NSIP or NSDNAME policies is significantly improved in versions of the RPZ code with the new min-ns-dots parameter with a default value 1. This turns off checking the many server names and IP addresses of TLDs. The version after that has min-ns-dots and also no longer hits every policy zone with every IP address and name in every response, but instead hits a summary red/black tree of names or radix tree of IP addresses summarizing all policy zones once for each address and name. This radically improves RPZ performance with multiple policy zones. The BIND9 tests in bin/tests/system/rpz include a quick and dirty performance test to ensure that nothing is not unexpectedly broken. This is typical output from that test: I:checking performance with RPZ I:checking performance without RPZ I:17758 qps with RPZ is 75% of 23596 qps without RPZ Previous versions of that test did not turn off some very expensive run time checks and so produced much smaller numbers for both cases. Patches for both of those versions of RPZ speed improvements for some BIND9 releases can be with the BIND RRL patches by following the link labeled "Patch files for BIND9" on http://www.redbarn.org/dns/ratelimits Both of those versions are or will be in official BIND releases. I've lost track of which releases have or will have which of those two RPZ sets of performance improvements. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RRL and avoiding contributing to DDoS (Was: How to suppress ADDITIONAL SECTION per zone)
> From: Dave Warren > I haven't been following the RRL discussions too closely, is this patch > scheduled to be included in BIND9 proper or will it remain a patch? } From: Evan Hunt each at isc.org } > It's not built into bind (yet). } } Correct. For the record, it'll be in 9.10.0 by default and 9.9.4 as a } compile-time option (--enable-rrl). https://lists.isc.org/pipermail/bind-users/2013-June/090872.html > In the mean time, would it make sense to set "minimal-responses yes" > proactively, or only if a spike of activity is detected (noting that it > will take us 1-3 days to notice a spike unless it's disruptive to > performance) Depending on your DNS data, a minimal response offers bad guys between significant and more than enough amplification for a DNS reflection attack. While a "minimal-responses yes" without RRL DNS server is participating in a DNS reflection attack, it can be sending a lot of bits/second. Some DNS servers are not bothered by few extra Gbit/sec of DNS output bandwidth, but many are In other words, as I see them, as DNS reflection mitigation, "minimal-responses yes" is like blocking ANY, just wishful thinking. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to suppress ADDITIONAL SECTION per zone
> From: John Wobus > > Other possibility is to implement packet rate limiting - a patch was > > discussed here a few days/weeks ago. > > I endorse this suggestion: we were faced with such attacks and were > naturally leery about issues we might run into running a patched bind > and the additional tuning it could require. Our experience is: the RRL > patch, used with its default parameters, simply does the job. (thanks for the good new.) See http://www.redbarn.org/dns/ratelimits Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RPZ - how to modify NS records in answer?
> From: John Horne > > dns1.plymouth.ac.uk.rpz-nsdomainCNAME *. > But the example zone file further down the page has the example: > >ns.domain.com.rpz-nsdname CNAME . > > So is 'rpz-nsdomain' wrong then in the zone file and 'rpz-nsdname' > should be used instead? "rpz-nsdomain" is wrong. The special RPZ owner labels are rpz-ip, rpz-nsdname, rpz-nsip, and some day rpz-client-ip. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Rate-Limit Question
> From: Drunkard Zhang
> Great patchset, and I found this docs will be in ARM:
>
> [ rate-limit {
> [ responses-per-second number ; ]
> [ referrals-per-second number ; ]
> [ nodata-per-second number ; ]
> [ nxdomains-per-second number ; ]
> [ errors-per-second number ; ]
> [ all-per-second number ; ]
> [ window number ; ]
> [ log-only yes_or_no ; ]
> [ qps-scale number ; ]
> [ ipv4-prefix-length number ; ]
> [ ipv6-prefix-length number ; ]
> [ slip number ; ]
> [ exempt-clients { address_match_list } ; ]
> [ max-table-size number ; ]
> [ min-table-size number ; ]
> } ; ]
>
> I wondering if all these functions are implemented?
Yes, of course. Why do you ask? Have you found something missing?
If so, are you using the version of the patch that corresponds to
the ARM text?
If there is another version of the patches, I should change the
script that generates that ARM HTML text from the XML patches to add
a date and perhaps extract some version numbers.
Vernon Schryverv...@rhyolite.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
> From: Doug Barton > > RRL needs only authority and open recursive servers to be updated. > > The vast majority of DNS installations are closed recursive and stubb > > servers that do not need RRL. (A case could be made for RRL on a > > minority of private recursive servers.) > > You're right of course, but unfortunately at least where open resolvers > are concerned the same people who operate open resolvers are also those > least likely to know what RRL is, or why it's needed; and are also least > likely to actually upgrade old software. So a statistically significant > percentage of the "long tail" problem is going to apply to those who > would provide the most benefit from making the change. hence my talk about an RPZ black zone of open resolvers that have been used in reflection attacks, and another RPZ zone of current attack victims that want TCP for a while. (I've mentioned serious flaws in both, so don't feel obligated.) > I could therefore make a pretty strong case that RRL should be on by > default, but I realize that's incredibly unlikely to fly. :) Me too, but it wouldn't help that long tail of orphans. Contrary to recent statements and how it might seem to most users, my spam traps still see open-relayed spam. Today some got into my mailbox. Those long tails never really go away. > > Other ideas that I like such as DNS cookies would need more widespread > > changes, which makes enthusiasm for them taxing. > > Yeah, that's unfortunate since if it's a good idea it's worth > implementing no matter how long it takes to be beneficial. The time will > pass either way. I see less value in DNS cookies when and if BCP 38 is the de defacto standard. DNS cookies only assure the DNS server that it is answering the client, and BCP 38 does cheaper that except on intranets. DNS Cookies are mostly insurance against the incentives against BCP 38 never being overcome. I've heard recent BCP 38 good news, but too little if any of it is about the long tail of networks with reasons they find compelling for never doing BCP 38 (or sufficent equivalents). It would take 10 or 15 years to get DNS cookies on most systems but we might never get BCP 38. As you said, an Austrailan law for BCP 38 would fall short, even if Austraila moves faster and more on point on the first try on BCP 38 than on spam. I'm waiting for the EU to declare BCP 38 an unlawful privacy violation. If IP addresses are PII, then the privacy right of anonymity implies the right to forge IP source addresses. I don't know if I'm joking. > Personally I've never understood why RRL wasn't already baked in. I've been saying for decades that rate limiting should be on the IESG checklist for any UDP based protocol. A year+ ago, Paul said "Make it so" for BIND9 DNS, and we started hashing out details. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
> From: Doug Barton > is that (like RRL) your proposal relies on people updating their > software. RRL needs only authority and open recursive servers to be updated. The vast majority of DNS installations are closed recursive and stubb servers that do not need RRL. (A case could be made for RRL on a minority of private recursive servers.) Other ideas that I like such as DNS cookies would need more widespread changes, which makes enthusiasm for them taxing. > RRL is actually useful for DDOS > attacks against the authoritative server itself. There are likely other > reasons, but those are the most obvious (to me anyway). That's in the RRL sales story that I've been flogging since before the first version of the RRL patch, but so far it has been only incidentally true. Some DNS server operators have reported drastic reductions in network and CPU load during attacks thanks to RRL, but they were not the intended victims of the attacks. Vernon Schryverv...@rhyolite.com Please join me in trying not to feed the troll. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
> From: "Ronald F. Guilmette" } That is an interesting contention. Is there any evidence of, or even any } reasonably reliable report of any DDoS actually being perpetrated IN PRACTICE } using strictly 512 byte packets? } } If that's actually a real problem, then I am forced to assume that there } must have been numerous reliable reports of successful and devastating } DNS reflection DDoS attacks which pre-dated the widespread adoption of } EDNS0. I am not sure where or how I would be able to unearth archived } but contemporaneous news accounts of such incidents, so if you could } send me some links to archived copies of a few such pre-EDNS0 DDoS } reports, I sure would appreciate it. Expecting to get detailed (e.g. packet dumps, packet sizes, IP addresses, ASNs) reports of DDoS attacks is like expecting samples of spam from anti-spam operators. Even the general outlines of reports tend to be private. > At which server? The numerous DDoS-participating individual intermediaries? > Or the (singular) DDoS victim? It wouldn't hurt to learn about the DNS protocol in general and DNS reflection attacks in particular before parachuting in with the Final Ultimate DNS Reflection DoS Attack Solution. Besides the facts that DNSSEC makes the problem worse and that EDNS0 was not the genesis of DNS reflection attacks, "intermediary" is a poor fit for a recursive DNS resolver (but might fit a stubb resolver). A recursive server answers from its cache. After it has recursed and until TTLs expire, a recursive server acts like an authority. That is why the query handling code in a DNS server implementation tends to treat its cache like a zone file. "Intermediary" simply does not fit the problem of open resolvers in DNS reflection attacks, because a DNS referral can give plenty of amplification. For example, I get more than 500 bytes of UDP payload from `dig +norecurs example.com` and almost 900 bytes from `dig +dnssec +norecurs example.com`. (If a recursive answering with a referral is an "intermediary", then so is every non-leaf authority.) "Singular DDoS victim" is off the mark compared to "DDoS victim." For obvious reasons, multi-Gbit/sec attacks often affect entire networks. (Multi-Gbit/sec attacks are more common than one might understand from some press releases.) In addition, there can be multiple IP addresses in an attack, and none of the target IP address need be in use by any hosts. Any host that is at a targeted address is not expecting the DoS packets and is be sending send as many ICMP Port-Unreachable error messages as its ICMP rate limits and firewalls allow (often none)--not to mention what the incoming flood might have done to BGP sessions and so forth and so on. Consider the implications of those facts, as well as the general meaning of "denial of service attack" on any Final Ultimate Solution that requires DDoS victims to send packets to DNS servers. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
> From: "John Levine" > The real solution is BCP 38, to keep spoofed packets out of the > network in the first place. Indeed. As many have mentioned, DNS reflection attacks are merely the current fad, driven partly by 10X or higher amplification (<50 byte queries, >500 byte responses) and partly by the lemming syndrome of any fad. There are have been, are, and will be many other protocols used in reflection attacks until BCP 38 is the de facto standard. Smurf was an old example https://www.google.com/search?q=smurf+reflection+attack See also ntp https://www.google.com/search?q=ntp+reflection+attack Chargen is another one from the ancient suite of of the small services https://www.google.com/search?q=small+udp+service+reflection+attack that is reportedly popular again. https://www.google.com/search?q=chargen+attack&tbs=qdr:m See also NTP, timed, and others. The standard reaction to a list like that from experts who invent Final Ultimate Solutions to the Spam Problem is incoherent nonsense about TCP and/or authentication. They neither know nor care TCP has long been and still is a very popular in reflection DoS attacks. https://www.google.com/search?q=tcp+syn+attack Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
> From: David Miller > >> Basically, the whole idea is just simply to allow a victim to switch to > >> "safe TCP only mode" with all of the intermediaries that are > >> participating > > > > The problem with that idea is that it needs software updates on both > > the reflecting DNS server and the victim. It also seems to require > > keeping a lot of soft state in the endpoints. > > This would require both software updates and an update to the DNS protocol. > > This idea does require state at the endpoints. We seem to have already > lost that battle - example RRL. Would this require more state at the > endpoints than RRL? I think that this probably would require more state. I think that the use of RRL on some roots shows that keeping state is not a problem if the state keeping is not utterly stupid. DNS cookies could do something similar but better than that "safe TCP only mode" idea. Unfamiliar (no cookie) DNS clients that show some (or no) sign of badness could be sent to TCP, could be given lower rate limits, ignored entirely (dropped), or whatever makes sense at the server. The state could be kept only on DNS clients and could be fewer and smaller than the state needed for RRL. See https://tools.ietf.org/html/draft-eastlake-dnsext-cookies-03 DNS cookies suffer less from the update-the-world problem, because they are optional. > > Altogether, it seems easier for everyone to just apply RRL patches, do > > BCP38 and de-peer with people who don't do BCP38. > > Agreed. Close all open resolvers as well. me too. Sufficiently distributed or disbursed DNS reflection attacks (e.g. qps<1 at reflectors) are hard even to detect except at the victim. I hope eventually to release BIND patches that add RPZ client IP address triggers and "drop" and "TCP-only" policies. See https://www.google.com/search?q=dns+rpz An RPZ zone of client IP address triggers of victim IP addresses and TCP-only policies, maintained by victim requests and certain other mechanisms could let participating DNS servers mitigate even extremely distributed reflection attacks. If there were an RPZ zone of client IP address triggers of open resolvers used in attacks and if that zone were used at many authoritative DNS servers, then users of those open resolvers would be inconvenienced and might pressure open resolver operators to act. The problem with those RPZ ideas is recruiting DNS server participants. That is similar to the problem of recruitng SMTP servers to use anti-spam DNSBLs, but worse because these ideas help victims instead of participants. It might be helped by including anti-reflection rules in other RPZ products. The RPZ "TCP-only" policy might be used in private kludges. Consider these rules in the external view on an open resolver: *. CNAME tpc-only-rpz. *.mydomain CNAME passthru.rpz. Like RRL, such ideas not as good as closing the resolver, but less bad than leaving it unprotected. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
> From: Tony Finch
> Sendmail at one time tried to use ANY for combined MX+A lookups, which
> doesn't work.
That would be true and relevant if sendmail did that. Requesting ANY,
not getting all of the MX, A, and/or records needed, and failing
to continue making other DNS requests simply does not work. If sendmail
did that, then given what BIND has done for eons, that bug would have
been noticed immediately eons ago.
Tony Finch pointed out privately that it wasn't until sendmail 8.12
that stopped asking for ANY records. I found 8.11.6 on
http://rpm.pbone.net/index.php3/stat/26/dist/4/size/1399432/name/sendmail-8.11.6-1.62.3.src.rpm
sendmail/domain.c in 8.11.6 started by requesting ANY. However it
continued requesting , A, and/or MX and parsing ANSWER sections
until it got the records needed. It did not stop with the ANY response
unless the ANY response was dispositive (e.g contained all types or
NXDOMAIN). My superficial code reading says it ignored ADDITIONAL
sections and so ignored potentially interesting A or RRs in
ADDITIONAL sections. My quick side-by-side comparison of the old
8.11.6 and current 8.14.7 domain.c says that the relevant difference
is that 8.14.7 starts with A or and never tries ANY.
However, that is about dns_getcanonname(). getmxrr() in both 8.11.6
and 8.14 starts and ends with MX and never messes with ANY.
There is broken in that ANY scheme. It might or might not reduce
average DNS traffic for sending mail. I'd vote against it today for
various reasons, but that doesn't make it wrong.
There is an interesting comment in the 8.11.6 version of domain.c:
** The ANY query is really meant to prime
** the cache so this isn't dangerous.
If your SMTP client is very close to your recursive resolvers (typical
10 or 20 years ago), then making an ANY request that you ignore could
reduce your external DNS traffic by priming (not refreshing) the
resolver's cache. I don't know that getmxrr() in sendmail is not
called before dns_getcanonname(), which would prevent cache the priming
by an ANY request.
About chasing CNAMEs safely or otherwise, please recall the somewhat
controversial DontExpandCnames. The current cf/README says:
confDONT_EXPAND_CNAMES DontExpandCnames
[False] If set, $[ ... $] lookups that
do DNS based lookups do not expand
CNAME records. This currently violates
the published standards, but the IETF
seems to be moving toward legalizing
this. For example, if "FTP.Foo.ORG"
is a CNAME for "Cruft.Foo.ORG", then
with this option set a lookup of
"FTP" will return "FTP.Foo.ORG"; if
clear it returns "Cruft.FOO.ORG". N.B.
you may not see any effect until your
downstream neighbors stop doing CNAME
lookups as well.
Vernon Schryverv...@rhyolite.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
> From: Dave Warren > >> I thought Google Public DNS re-fetched RRsets as they were expiring in > >> >order to keep the cache populated, which would explain what you see, > > I don't understand how they could pre-fetch the gazillions of RRsets > > that are rarely requested. > ... > I'm not convinced they really bother with any of that though, I wonder > if they don't just have giant shared caches on powerful, well connected > boxes. I don't know about "shared," but there's no doubt about the rest of that. > Either way, when you're playing with a single test domain, > experimentally, they'll absolutely expire just the way anybody else does. If I were doing what I might understand them to be doing, and if I were obsessed with initial page loading speed, then I might play an easy game with TTLs and extra recursing. When the remaining TTL of an RRset is positive but small, answer the DNS request from the cache as usual but also start fetching. When the remaining TTL is large or <=0, do the usual things. That would keep popular RRsets in the cache without having needing to decide explicitly which domains are popular today or for a particular instance of the recursive server. If "positive but small" were a small multiple of the RTT to the authority (including the authority's queue and processing time), such as a constant 0.75 or 1.0 seconds for all RRsets everywhere, then its ratio to the original TTL would prevent more than 1% on average of the pre-emptive fetches from being wasted. It sounds hard to see whether they are playing that sort of game from outside. On the other hand, I think too many of the records in their responses to my ANY requests for my test domain have TTLs of 0. I think it would not be too hard to hack that early recursion into BIND, and so perhaps other DNS implementations. Making an ANY psuedo-RRset sounds messy, because of maintaining its TTL as the minimum of the TTLs of the RRsets at the node even as non-ANY requests refresh individividual RRsets. The point of all of this that is not mere gossip is: - Don't just assume that ANY requests are useless. - Don't just assume that no applications have used, use them now, or will use them in the future. - Don't just assume all DNS servers treat ANY requests the same. - Don't just assume that no significant DNS servers respond to them in any way that is not explicitly outlawed by a standards track RFC. And you might need to deal with some outlawed responses. ANY requests are like the SMTP <> sender, missued and abused by attackers and filtered by operators based on dubious assumptions. Filtering ANY is not as bad is blocking all ICMP or blocking TCP/53, but it comes from the same school of security "expertise." Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
> From: Tony Finch > > a few minutes playing around, you might come to my conclusion. I think > > they treat ANY as if it were psuedo-rdataset containing some of the > > RRs for the domain with a TTL equal to the minimum of all of the TTLs > > of the contained rdatasets. (I thought I sometimes get only some of > I thought Google Public DNS re-fetched RRsets as they were expiring in > order to keep the cache populated, which would explain what you see, I don't understand how they could pre-fetch the gazillions of RRsets that are rarely requested. It certainly doesn't explain what I see in DNS queries and responses and in my server logs with a test domain with a dozen fat RRsets with TTLs ranging from 5 to 65 seconds. (They started SERVFAILing when I added the last RRset; I don't know whether they don't like bogus DNSKEYs, I tested too much, or I hit a size limit.) I'd be happy to disclose my test domain name in private mail, but that wouldn't get my server logs. Only one of us could play with it at a time. You could add to a zone of your own and start testing faster than I could answer private mail. > It was a bad hack then and it has remained a bad hack :-) I would not agree if you could rely on the open resolvers continuing to do what they're doing, if you didn't care about parsing 3 or 4 KBytes of irrelevant bits to get the RRsets you want, and if you don't care about spending 9 or 10 IP packets on a truncated UDP responce and then a full TCP response instead of 6 on 3 separate queries. With BIND as your DNS server, it could be a win for bursts of mail to a single SMTP server if your SMTP client is too dumb to do the obvious, safe caching. At worst you would need to ask for ANY, MX, A, and , but some of the time the ANY would have all of the RRsets. However, in both cases, the proverb applies. "If wishes were horses, beggars would ride" Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
> From: Tony Finch > You are not quite correct. See http://fanf.livejournal.com/10.html for > details. It is obvious to anyone willing to spend a few seconds experimenting that is true of current BIND9 code (and as far as I know old versions): } If a DNS cache already has any records (usually an A record) for } a domain, an ANY query won't make its resolver fetch the other types However, it is also obvious to anyone to spend almost as little time that is not true about Google, OpenDNS, and some intentionally other open DNS resolvers. If you have a domain to which you can can add records for a subdomain with differing 5-30 second TTLs and can spend not just 5 seconds but a few minutes playing around, you might come to my conclusion. I think they treat ANY as if it were psuedo-rdataset containing some of the RRs for the domain with a TTL equal to the minimum of all of the TTLs of the contained rdatasets. (I thought I sometimes get only some of the record types for my Christmas tree test domain from 8.8.8.8, but now I seem to always get all of them.) That means that if - you assume (in my view unwisely) that those open DNS resolvers won't change how they handle ANY - your SMTP client (mail sender) uses one of those DNS resolvers, then it can get the MX, A, and records (or their absences) with a single ANY request. 5 years ago that might have been a good hack, because it would reduce the number of DNS round trips for SMTP clients. In the future it won't be a good hack and probably is not good today, because the ANY psuedo-rdataset can be enormous and can require the truncated-UDP/TCP-retry dance as well as the CPU costs of parsing and discarding almost all of a giant response. When you ask for ANY, you should not only get MX, A, and , but also TXT, SRV, SPF, DNSKEY, and any others as well as RRSIGs for everything. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
> From: Matus UHLAR - fantomas > On 02.06.13 20:28, hugo hugoo wrote: > >I plan to block these kind of requests on the dns cache servers in order to > > avoid any amplification attack. > hard to say, but as I stated before: don't do that. Instead, use RRL to mitigate many kinds of amplification attacks instead of only those using ANY. See http://www.redbarn.org/dns/ratelimits Blocking DNS ANY requests is to DNS amplification DoS mitigation as blocking SMTP envelope Mail_From values of <> is to spam filtering. In early spam days, people who either knew far less than they pretended or had special agendas prescribed blocking the <> sender as almost the FUSSP, and never mind RFCs that require accepting mail from <>, the value of mail from <>, and the vast floods of spam that don't and never did involve the <> sender. Blocking DNS ANY or SMTP <> fit the old saying by H. L. Mencken: For every complex problem there is an answer that is clear, simple, and wrong. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DDOS attack Bind 9.9 - P2
> From:
> >What if both authoritative and recursive are running on the same
> >server since RRL does not apply to recursive servers?
> Found the answer to below.
>
> According to isc-tn-2012-1.txt hybrid authority/recursive servers
> are out of scope.
I disagree. What isc-tn-2012-1.txt says is
Deliberately open recursive DNS
servers, or hybrid authority/recursive servers or server views, are
outside the scope of ***THIS DOCUMENT.*** (emphasis added)
Recursive servers should be closed instead of open to the Internet.
When a single BIND instance is used for both local recursive service
and global authoritative service, a good way to close the recursive
service to the Internet while providing authoritative service to the
Internet is with two views. The external view can disable recursion
and include a rate-limit{} statement to apply RRL to responses to
external DNS clients. Another way to close recursion to the Internet
is to use allow-recursion{address-match-list}; and
rate-limit{exempt-clients{address-match-list}}; statements in the main
options statement.
If you must keep your recursive server open, Internet, then you MUST
do some sort of rate limiting. If you cannot do rate limiting that
is even fancier than RRL such as Google's, then an open recursive
server with RRL is far better than a naked open recursive DNS server.
See https://developers.google.com/speed/public-dns/docs/security#rate_limit
The problem with RRL on recursive servers is that it works. Any rate
limiting sufficiently low to minimize the danger of DNS reflection DoS
attacks including RRL can affect applications such as web browsers and
SMTP servers (mail receivers) that send bursts of identical DNS requests.
With RRL, those effects are generally limited to pauses and slow downs
as affected applications time out and retry.
Vernon Schryverv...@rhyolite.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: DDOS attack Bind 9.9 - P2
> From: > So based on the response below how critical is it to implement > RRL via Bind RRL patch provided the servers resources are available? Even if I knew which server resources are at issue (I don't), I think you must decide for yourself whether to install RRL and if so, how urgently. > And where do I download this patch? See the links on http://www.redbarn.org/dns/ratelimits Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DDOS attack Bind 9.9 - P2
> From: "Lawrence K. Chen, P.Eng." > So does rate limiting cover when the attacker walks my DNS zone to > attack an IP? that depends on what is meant by "rate limiting" and "walking a DNS zone". Simple rate limiting that counts all requests ostensibly from a single IP address regardless of (qname,qtype) differs from response rate limiting (RRL) which counts distinct responses. "Walking a zone" can differ from walking a zone's valid names (perhaps based on NSEC RRs or arithmetic as in a reverse zone). Simple rate limit is required to mitigate zone walking for valid names not based on a wildcard, because the valid responses differ for RRL. If you read the BIND9 RRL documentation, then you will find that simple rate limiting is supported by the BIND9 RRL patch. However, simple rate limiting is best done in a separate firewall to avoid spending CPU cycles, memory bandwidth, and other resources of the DNS server. Responses based on a wildcard or error responses such NXDOMAIN or REFUSED responses are considered identical by RRL and so are limited by the BIND RRL patch. On the other hand, an attack from ambitious bad guy who has built a list of 1,000,000 triples of (qname,qtype,DNS server IP) and does not hit any single DNS server more often than 5 requests/second will not be detected by any of the servers and so cannot be mitigated at the servers even with simple rate limiting. It is in a sense fortunate that DNSSEC is still so rare that finding 1,000,000 DNS server IP addresses with large amplification requires more effort than other reflection mechanisms. Vernon Schryverv...@rhyolite.com P.S. Maybe there should be an FAQ somewhere, because it seems as if I've written something similar often enough to irritate others. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DDOS attack Bind 9.9 - P2
> Patch BIND to include the RRL (Response Rate Limiting) patches > (http://www.redbarn.org/dns/ratelimits), blackhole/ignore those > clients requesting. The fact that Response Rate Limiting (RRL) does not blackhole/ignore clients is a feature and why it is a better mitigation for DNS Reflection DoS attacks than mechanisms that do blackhole/ignore clients. The apparent DNS clients in DNS reflection attacks is usually not the source of the evil requests, but forged by bad guys trying to attack the nominal clients. Because RRL limits rate of any particular response sent to any particular client address block, the client is generally able to get responses for its legitimate requests and often will not notice the attack. Naively blackholing/ignoring the forged client as with common firewall rules does stop attacks, but lets the bad guy deny name service to the client. Breaking host name resolution has been a part of many security attacks over the years. ... } > I have isc.org attack." isc.org internet *?". It comes from my own clients } > that I have allowed in my ACL. the question is how to stop this attack? } If the queries are really from your clients, find & fix them. They are } probably attacking others in addition to you, so you'd be doing the rest of } the Internet a favor while solving your own problem. Simple request flooding with forged DNS client IP addresses sounds unlikely, because there are many other DoS attacks that are more effective and harder to filter. In other words, the smart money bets on the requests not really coming from the apparent clients, but that they are forged and intended to attack the apparent clients. } If the traffic is spoofed as being from your clients, stop accepting traffic } from elsewhere sourced from your client address space. That is best, if possible and relevant, as with closed recursive resolvers. It is generally irrelevant and impossible for authoritative DNS servers. The RRL patch is intended for authoritative servers, but can be used as better than nothing on recursive resolvers. The best mitigation for open recursive resolvers is to close them except to trusted clients. When that is not possible, RRL can be used at the cost of significantly slowing applications such as browsers and SMTP servers (mail receivers) that make large bursts of identical requests. ... ] Many people will not compromise critical daemons by using third party ] *unofficial* patches. I don't know the status of the CZ-NIC Knot DNS or the NLNetLabs NSD RRL code. Perhaps that either of those is "third party" or "unnofficial," although I have the impression that is at least partly wrong. The BIND RRL patch on http://www.redbarn.org/dns/ratelimits are unofficial, and so it is reasonable to be skeptical and wait for an official release. However, for obvious reasons it is not really accurate to label the BIND RRL patch as "third party." "Pre-pre-release" is a more accurate characterization of the BIND RRL. Please note that users of the FreeBSD bind98 and bind99 ports can get the RRL code without messing with the patch command. See https://www.google.com/search?q=site%3Afreebsd.org+bind+rrl ] iptables does just as good of job. That is widely known to be false in general. In principle one could write iptables rules that do as good a job as RRL. However, the common iptable rules that rate limit incoming requests based entirely on either query types or DNS client IP addresses block ilegitimate queries and so are distinctly inferior to RRL. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: I'm having thousands of queries ...
> From: Denis Laventure > > Subject: RE: I'm having thousands of queries a domain isc.org and this > > increasesmy cpu percentage to 100%. That may be happening and how I > > can controlthis? is an attack? attachment of the log I made an update to > > version 9.9.2-P2 as recommended but still continuo > I'm having the same problem but for those domains... > >hao.360.cn. > ... > 15-Apr-2013 15:00:08.485 security: info: client 117.21.187.20#52538: view e= > xternal: query (cache) 'hao.360.cn/A/IN' denied The IP address mentioned in the previous mail message does not seem to be an open recursive resolver. That and the reference to 9.9.2-P2 suggest that RRL would be a good fit and might save CPU cycles. I don't know whether this DNS server is recursive or authoritative, but that log entry suggests at least "closed". If it is closed or authoritative, then RRL in the "external" view would automatically save CPU cycles and bandwidth that would otherwise be spent sending those REFUSED responses. The best by far solution for an open recursive server being hammered (or not yet being hammered) is to close it. If you can't close it and can't afford the fancy defenses of commercial open recursive servers such as https://developers.google.com/speed/public-dns/docs/security#rate_limit RRL is a lot better than no defense. The reason RRL is not recommend for recursives server bcause RRL can slow down browsers, SMTP servers (mail receivers), and other applications that repeat DNS requests. See http://www.redbarn.org/dns/ratelimits Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: trouble compiling bind 9.9.2-P2 with rate limit patch rl-9.9.2-P2.patch
> From: Red Cricket > here's a link to pastebin http://pastebin.com/RxcsJMLe > > I used ... > > > > patch -s -p0 -i rl-9.9.2-P2.patch > > > > like it says in the documentation. It looks like the patch was applied after running ./configure. That doesn't work because the some Makefile.in files are changed by the patch, and those changed Makefile.in files are used by ./configure to generate some change Makefiles. Those changed Makefiles compile rrl.c and other things. Where does the documentation advise running `./configure` before `patch`? It needs to be corrected. Instead try: 1. fetch BIND tarball and matching RPZ/RRL patch 2. unpack the BIND tarball 3. change directory (cd) to the unpacked BIND source directory 4. use `/what/ever/named -V` where /what/ever/named is the currently installed version of BIND to get the ./configure parameters from the current version for the target platform. 5. run `./configure stuff` where "stuff" are the parameters from step #4 6. `make` I can't help past that point, because it involves installing at least named-checkconf and named itself. You might try `make install` but that might break things. It certainly should not be done before saving the currently installed rndc, named-checkconf, and named. Those who are not familiar with building and installing UNIX C programs from source and don't intend to get that familiarity by fighting with BIND and the RPZ/RRL patches should wait for BIND releases with RRL. Currently there are at least FreeBSD ports and a Red Hat Enterprise Linux Desktop update. See https://rhn.redhat.com/errata/RHSA-2013-0550.html https://bugzilla.redhat.com/show_bug.cgi?id=906312 and http://www.freebsd.org/ports/dns.html#bind99-9.9.2.1 Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: trouble compiling bind 9.9.2-P2 with rate limit patch rl-9.9.2-P2.patch
> From: Red Cricket > I have been attempting to follow the instructions here: > http://ss.vix.su/~vjs/rrlrpz.html > but make fails with this error ... > undefined reference to `dns_rrl'query.o: In function I bet that there is are a passle of stray files including rrl.c in the top of the BIND source pool and that something like this patch -s -i FILE.patch was used instead of this from http://ss.vix.su/~vjs/rrlrpz.html patch -s -p0 -i FILE.patch Without "-p0", new files from the patch file are created at the current directory. See https://www.google.com/search?q=patch+command Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RPZ and negative answers
> From: Torsten Segner > subdomain.domain.de 60 A 172.26.30.231 > The above setting is rewriting NXDOMAIN answers for subdomain.domain.de > to the above IP address while every other host still has the information > of the customers outside zone. > > Am I doing something substantially wrong here RPZ wise? If it works the way you want it to work, then you're probably not doing anything wrong. In any case, I'm all wet and all wrong. That example with subdomain.domain.de works for me too when I add it to a test zone. (It might also be necessary to list *.subdomain.domain.de.) I don't know what I did to make the test I tried fail. Besides, when trying to rewrite based on names, the code uses the current state of query name (possibly along a CNAME chain) or ns.name, the name of a relevant name server. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RPZ and negative answers
> From: Chris Buxton > A company wants to halt the spread of a piece of malware that > uses DNS lookups to find its C&C. ... > The company has determined the first N domains of the sequence, > but does not know how to calculate the complete set of domains. > ... > Unfortunately, because RPZ doesn't return a policy-based answer when > there is no positive answer to be found out on the Internet, RPZ is > not a suitable solution. Therefore, the customer is forced to create > the individual zones normally, mixing them with other data in their > management solution, rather than using RPZ to trap the malware into > contacting the honeypot server. Why isn't it both sufficient and better to list the NS servers or NS servers for the NS servers of the evil domains? Won't NS servers for the N domains be known, espcially after the first of the N domains goes active? Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rate limit dns query response ...
> From: prakash
> We are using bind 9.x on linux and would like to create rate limit for DNS
> query from any users ie 10 query per second. Can anyone guide us
I would:
1. read http://www.redbarn.org/dns/ratelimits
2. read the new ARM text about RRL by following the link labeled
"Draft text for BIND9 Administrators Reference Manual (ARM)"
on http://www.redbarn.org/dns/ratelimits
3. fetch one of the BIND releases and matching patches on the
page in the link labeled "Patch files for BIND9" and then
build and install them. I would probably use BIND9 9.9.3b2.
4. add something like this to named.conf
rate-limit { responses-per-second 5; };
Vernon Schryverv...@rhyolite.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: RPZ and negative answers
> From: Chris Buxton > If a name exists in the response policy, and also exists in the real > Internet namespace, the value from the policy is returned. But if it > doesn't exist out on the Internet, then the value is not returned -- > an NXDOMAIN (or SERVFAIL, or whatever) is returned instead. > > I've known this for a while but haven't understood why it is thus. > Today, it has become a problem for me. If I set a policy of "this > name gets response X", I expect that policy to be used rather than > "this name gets response X unless it doesn't exist out on the > Internet or can't be resolved due to an error." RPZ stands for "response policy zone" and concerns rewriting responses instead of queries. The answer section of an NXDOMAIN or SERFVAIL response does not contain a domain name that could trigger rewriting. Rewriting queries instead of responses would fail to rewrite CNAME chains. Even when the unrewritten response is an error such as NXDOMAIN, an RPZ action can be triggered by the name or address of any NS RR that is authoritative for the response and that is found in glue or otherwise. Previous versions of the RPZ mechanism in BIND required ./configure settings to enable rpz-nsip and rpz-nsdname rules. They are enabled by default in future released versions of BIND as well as the speed-up patches that can found by following the link labeled "Patch files for BIND9" on http://www.redbarn.org/dns/ratelimits Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Blocking private addresses with a optionq
> From: "Lawrence K. Chen, P.Eng." > First thing that got my attention was that "The rules encoded in a > response policy zone (RPZ) are applied only to responses to queries > that ask for recursion". But, these are authoritative only nameservers > So, would RPZ work in this case? This is some more complete text from the 9.8.4-P1 ARM without patches: By default, the actions encoded in an RPZ are applied only to queries that ask for recursion (RD=1). That default can be changed for a single RPZ or all RPZs in a view with a recursive-only no clause. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Does 9.9.2-P2 support rate-limit configuration?
> From: Red Cricket > Does 9.9.2-P2 (the recent release that fixes > CVE-2013-2266: A Maliciously Crafted Regular Expression Can Cause Memory > Exhaustion in named) > support rate-limit ? not without patching. > If not is there a way to patch the source code to > allow for rate-limiting? Yes, there are 12 more patches for 9.9.2-P2 and 9.8.4-P2 in the usual place. That place can be found by following the link labeled "Patch files for BIND9" on http://www.redbarn.org/dns/ratelimits Two of the new patches are copies with names that includd the version string for the FreeBSD ports. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Hack Attempt?
> You wouldn't normally expect to see NOTIFY from clients, but maybe that > IP is (or thinks it is) a master for a zone you slave? or it thinks it is an authoritative slave and hasn't been told with "notify master-only;" to not send NOTIFY messages. http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.html#options notify If yes (the default), DNS NOTIFY messages are sent when a zone the server is authoritative for changes, see the section called "Notify". The messages are sent to the servers listed in the zone's NS records (except the master server identified in the SOA MNAME field), and to any servers listed in the also-notify option. If master-only, notifies are only sent for master zones. If explicit, notifies are sent only to servers explicitly listed using also-notify. If no, no notifies are sent. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Suspecious DNS traffic
> > Still not convinced because if i need to allow >1024 port from our > > DNS server to external world(internet).. where is the security? Every UDP and TCP packet has two port numbers, the source port and the destination port. When a resolver sends a request to a distant DNS authority, it sends to destination port 53 with a random local source port number. When the distant resolver responds, it will send a UDP packet with source port 53 and with destination port equal to the source port number in the request. If you block all packets from port 53 to local ports other than 53, then you will block all response to your resolver's requests. Some DNS resolver software in ancient days sent requests to distant authorities with source port 53, so that both the source and destination port numbers in DNS/UDP packets were 53. There are many reasons why that was a bad idea. For one modern reason, see https://www.google.com/search?q=cache+poisoning+attack and https://www.google.com/search?q=dns+source+port+randomization Contrary to claims in this thread, that source port need not be greater than 1024 except on some operating systems. The notion of "privileged ports" smaller than 1024 is an ancient "BSDism" that many consider a mistake. However, the source ports in DNS/UDP requests (as well as DNS/TCP) are likely to be restricted to parts of the complete [1,65535] range of port nubmers, but those partial ranges depend on the operating system, operating system configuration, DNS resolver software, and the resolvers configuration. For TCP and stub DNS resolvers, see https://www.google.com/search?q=ephemeral+port For DNS/UDP and BIND as a resolver, see the BIND Administrators Reference Manual (ARM) including the query-source,use-v4-udp-ports, use-v6-udp-ports, avoid-v4-udp-ports, and avoid-v6-udp-ports options. > You send request via UDP from random high port to an authoritative server. > Answer is too large to fit in UDP packet, so it responds via TCP to the > source port of the request (random high port from above). If you block > that TCP connection, you cannot receive answer to your query. No, a distant DNS authority certainly does not respond via TCP after a UDP response fails to fit in a DNS/UDP packet. Instead, the distant authority responds with a DNS/UDP packet with the TC or "truncated" error bit. A resolver will react to TC bits or truncation errors by making the same request with TCP unless it has already received the required data from some other DNS authority. This can happen after the local resolver has tired of waiting for an answer from one authority and sent the request to some other authority. Making a request via TCP consists of sending a TCP segment (or packet) with SYN bit sent to port 53 at the distant authority and with yet another random source port number. The distant authority will respond with a TCP segment with both the SYN and ACK bits set. The local resolver will respond with another TCP segment with both the SYN and ACK bits set. This is the famous "3-way handshake" that establishes a TCP connection. Only after the TCP connection is established does the local resolver send the DNS request through the TCP connection. > Another reason for TCP replies is DNS Response Rate Limiting (RRL). Not exactly. > Some "modern" stateful firewalls understand DNS and if there is a UDP > packet sent to port 53, it will accept TCP connections back from the > destination address on port 53 to the source address/port. That is wrong. UDP packets have nothing to do with telling reasonable firewalls to allow TCP. Firewalls for more than 10 years have automatically dealt with TCP in at least two ways. One is to notice and remember (i.e. save state) the initial TCP SYN segment 3-way handshake and allow the later predictaBle TCP segments. Another mechanism is to blindly block incoming TCP segments with SYN but without ACK. The first mechanism requires saving state or memory for every established TCP connection, and so can be vulnerable to some kinds of "state exhaustion attacks." The second mechanism prevents outsiders from originating TCP connections, but does not protect against using the local system for some kinds of reflection DoS attacks. Many stateful firewalls can also record the source and destination IP addresses and port numbers of outgoing UDP packets and allow subsequent incoming UDP packets with source and destination reversed. This has nothing to do with TCP. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: querying TLD nameservers - limitations
> From: blrmaani > I am developing a monitoring script for internal use and this requires > extensive querying of TLD nameservers (a .. m).tld servers. > > Questions: > 1. Are there any rate limitations imposed by TLD servers i.e these > servers allows only certain number of DNS queries per IP per second? Yes. See https://www.google.com/search?q=dns+reflection about one reason why rate limiting is required. See also https://www.google.com/search?q=dns+rrl > 2. Are there other limitations I should be aware of while developing > my script? First, I don't speak for any TLD operators. Maybe TLD operators don't care if everyone in the world uses their networks and computers for connectivity or local DNS resolver monitoring--and never mind any scaling worries. Second, if I have guessed wrong about what you are doing, please accept my apologies and ignore the following. If I've guessed right, my advice is "Stop Immediately and Forever!" I have web pages with higher Google page rank than I care and I run some anti-spam stuff. Some people feel entitled to take my bandwidth, CPU cycles, and system administration time for their private uses without my let, leave, or hindrance. Some of them continuously send ICMP Echo-Requests. Others ping with DNS. Still others continually fetch web pages. Then there are hours every day of odd 50 UDP pps via 6to4. I treat them the same as the DNS "researchers" that continually probe by my in-addr.arpa zone looking for domains to attack or forge in spam, other "researchers" looking for PHP and other security holes, SMTP dictionary attackers, etc. They should spend their own money to monitor their Internet connectivity DNS clients, or whatever they think they're doing. There are commercial enterprises that sell monitoring. One can also barter with friends. If they were not functionally evil, they would ask first. I'm sure all of them feel their hearts are pure and would be hurt and insulted if they knew I see them as thugs and sociopaths. They can't understand that evil is as evil does and that their claimed motives are irrelevant. They're like those who define spam as that which they don't do. http://www.rhyolite.com/anti-spam/that-which-we-dont.html Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: spf ent txt records.
> From: John Wobus > 1) An RFC (or RFCs) that specifies a set of specific TXT record content > formats that are specified to have particular meanings, e.g. 'don't do > the > following unless it's an SPF record'. I've not been keeping up with the IETF; is there a document that describes what looks like a de facto standard of using _pname labels with TXT RRs that is being followed by at least DMARC and DANE in *._tcp.example.com, *._smimecert.example.com, and _dmarc.example.com https://tools.ietf.org/html/rfc6698 https://tools.ietf.org/html/draft-fanf-dane-smtp-04 https://tools.ietf.org/html/draft-hoffman-dane-smime-04 http://www.dmarc.org/draft-dmarc-base-00-02.txt Is SRV the precedent being followed? Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: spf ent txt records.
> > I'd go along with that, if they can't get their act together within 3 > > years, then that IS pure laziness. I think "laziness" better fits answering port 443 with HTTP/TLS-SSL and not publishing DANE RRs with existing certs or fingerprints. The contrib/dane directory in current versions of BIND has a shell script that I think makes doing that easy. Also, those who are not lazy, who think RFC 4408bis is wrong, and want to use type 99 without violating RFC 4408bis will go to the IEFF. > Laziness can be not reading RFC6686 Appendix A: about how it is not > rational to keep SPF RRTYPE99 and how things got confusing in part > because of pressure from some DNS experts. I agree that laziness can be pontificating without bothering to read, but that text mostly blames SPF enthusiasts in points #1-#4. The complaints about DNS experts concern future RRTYPE problems. } From: Mark Andrews } MX records took over a decade before one could have a MX only domain } safely. MX records have significantly benefits. Switching from TXT to type 99 has no foreseeable operational benefit. There never has been and never will be flag day for MXs. }RFC 4408 } failed to set a sunset date. It would be the same if RFC 4408 had a sunset date, because RFC 4408 came too late. In hindsight today, the relevant error among many far worse and always obvious errors was not using a label like _spf. Regardless of all of that, RFC 4408 did not set a sunset date, and RFC 4408bis does deprecate type 99. } It's not that is is esthetically pleasing to put SPF data into its } own RR type. It's that TXT has been hijacked and contining to add } more uses to TXT does not scale. TXT is a reasonable record for } proof of concept. It isn't and never has been a good long term } choice. I can't argue with that, but reality is that switching from TXT to type 99 has costs and no benefits other than what most people see as mere esthetics. There are many features in the DDN Protocol Suite that could have been better including scaling better, but even 25 years ago was too late for flag days for anything in use. All that can be done is designing something better with very low transition costs and/or significant practical benefits and hoping people won't be too lazy. (e.g. DANE again) } Turning off lookup for TXT record lookup for SPF would have very } little negative impact. You would have some additional spoofed } email getting through and some additional blow back (which could } be eliminated by publish SPF records). I agree with this translation of that statement: Google, Hotmail, AOL, and the other large inbox providers could agree with the ESPs to ignore RFC 4408bis and switch to type 99. They are already violating RFC 4408 and RFC 4408bis with DMARC with far more operational significance. However, my bet is that Google et al will do as many others have done. They will care about the costs that you label "very little negative impact" and ignore those hypothetical TXT abuse scaling problems...not to mention complying with RFC 4408bis. Whatever is done by vanity domains and by domains that publish ~all or ?all without _dmarc will remain irrelevant. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: spf ent txt records.
> From: Mark Andrews > Yet libspf2 requests SPF records and falls back to TXT on NODATA. > It does not do a TXT query if it gets a SPF response. Even if my option of SPF is insane, compare the 2008 dates on http://www.libspf2.org/ and the 2012 date on the surveys in RFC 6686. It's clear that for whatever real world reasons, libspf2 was not dispositive and that draft-ietf-spfbis-4408bis-12 is right to deprecate the SPF type in section 3.1. > The rational course would be to set a sunset date on TXT style spf > records. April 2016 looks like a good date. 10 years after RFC > 4408 was published. The rational course usually starts with accepting reality as it is. In the real world, flag days are ignored by most people until there is clear profit in honoring them or loss in ignoring them. A loss can be "We've stopped updating the hosts file so if you want your stuff to work, you better get busy with the DNS." Wasting a round trip to get NODATA for the SPF RR for google.com or hotmail.com before requesting the TXT RR is not a profit. There is no real world profit in "It is esthetically pleasing to put SPF data into its own RR type." Your flag day for turning off IPv4 in the core must be soon, because IPv6 has already been baking for a lot longer than 10 years. Besides, unlike TXT for SPF, IPv4 has real problems in the real world. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: spf ent txt records.
> 20741, so direct SPF RR hits is about one third of those using TXT RR, > small, but, insignificant? I wouldn't really say so, but some might. I > suspect the SPF wanting to be deprecated is because of the lack of > take-up, due to lazy admins, there are some resolvers in use from > ancient debian boxes that are so old, they dont understand the SPF RR, > yes I know, they have bigger problems than that, but, again, comes down > to laziness, DNS is not rocket science, I'm sure given ARM and access to > google, a 13yo kid could get at least the "basics" right. Laziness?--nonsense. Postel's Law and simple logic predict the deprecating of the SPF type as well as the continued practice of publishing only TXT records by those with rational reasons to publish SPF data. 1. SMTP servers (mail receivers) that have wanted to honor SPF -all been forced to look for for SPF data in TXT records since the beginning. There have been far more TXT records with SPF data than SPF records. Therefore, the best course for SMTP servers has been to request TXT and only request SPF if the TXT request gives NODATA. Requesting both SPF and TXT types would cost extra bandwidth and raise questions about what to do if both are present and differ. Occassional differences between SPF and TXT are inevitable due to caching in recursive resolvers even when the authoritative server always changes both simultaneously. 2. Rational operators of SMTP clients (mail senders) know that well maintained SMTP servers understand #1 and so request TXT first or request neither SPF nor TXT. Publishing only SPF type records would double an SMTP client's DNS costs. Pubishing both SPF and TXT would not help well mantained SMTP servers, but cost maintenance complexity and so potential errors. Therefore, it is best to publish only TXT for well maintained SMTP servers. Badly maintained SMTP servers are likely to only check TXT records. Unlike the situations with IPv6 and DNSSEC, there are only costs and no benefits for rational operators SMTP clients or servers to change those two tactics. Those interested in wider perspectives about SPF and TXT RRs than any single domain or the perceptions of SPF enthusiasts might consider the tables reporting surveys in RFC 6686. One can ignore everything specifically about SenderID and read only about popularity of SPF and TXT records. https://www.rfc-editor.org/rfc/rfc6686.txt Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 100% CPU / wedge with 9.8.3-P4 & RPZ?
> From: Phil Mayers > It's unfortunate I wasn't able to obtain one; gdb wasn't installed on > the box, and I couldn't get the package installed because DNS was down. Depending on the flavor of the system and its configuration, adding lines to /etc/hosts can be effective for working around local or remote DNS problems. > Obviously if we're "lucky" and it happens again (with RPZ disabled or > otherwise) then I'll grab a core, as gdb and the debug symbols for our > binary are now installed. A local copy of gdb is not required to create a core dump, although I understand that some versions of gdb can be used. I use `kill -6` or another fatal signal. Some systems disable by default the creation of core files. This irritating, simplistic misconfiguration (that's only my view) is especially common in the Linux world. See https://www.google.com/search?q=create+core+file Gdb would have been handy for looking at named without creating a core file or disturbing the process by more than what it would see as a jump in time. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 100% CPU / wedge with 9.8.3-P4 & RPZ?
> From: Phil Mayers > If it's not RPZ, those xfr timings are very coincidental. But of course, > I'm just guessing. It could be phase of the moon for all I know at this > stage. That only two large Spamahus transfers of the dozen transfers so far this month were coincident with the problem suggests the phase of something matters. In BIND 9.8.3, response policy zones were merely zones with an auxilary radix tree for IP addesses. All locking for updates was the same as with any other zone. I get no joy from port 80 at spamhaus.org now, so perhaps Spamhaus is under DoS attack yet again. Another random guess is that the problem you saw is related to IXFRs afflicted by DoS attacks on the master. On the other hand, the masters for rpz.spamhaus.org differ. On the third hand, maybe transfers to the RPZ masters were affected and that caused hiccups or other oddities in the transfers to your systems. To debug and so have the least hope of eventually fixing this or any similar problem, I would build BIND with -g and capture a core file and associated libraries for a hung example,. Whether your guess blaming RPZ is right or wrong, no progess is likely to be made without a core file. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 100% CPU / wedge with 9.8.3-P4 & RPZ?
> From: Phil Mayers > >> In the last 12 hours, we've had repeated instances of named getting > >> wedged. The symptoms are: > >> > >> * named consuming nearly 100% CPU, all in user-time > >> * lots of queries apparently not processed, and based on query > >> logging, a sharp drop in the rate of queries that are > >> * a very sharp drop (almost a complete halt, in fact) in the rate of > >> RPZ "hits" in the logs at the exact time this happens > >> * no other interesting logs, as far as I can see How can the rate of RPZ hits not drop along with a sharp drop in the rate of queries? > >> I can't see anything in the release notes for 9.8.4/9.8.5 - any ideas? There have been no recent RPZ hangs, but the release notes for 9.8.5b2 mention a DNSSEC hang and I noticed that imperial.ac.uk has RRSIGs. There is also a hang mentioned in the 9.8.4-P1 release notes. > Examination of the journal suggests they deleted and re-added more or > less every record in the zone (presumably an error at their side). Wouldn't deleting more or less every record in the response policy zone tend to reduce the rate of RPZ hits? > Does anyone else slave the Spamhaus RPZ and saw this? It seems like > there might be a bind bug here with large updates to RPZ. Not to defend RPZ, but what is the evidence that links RPZ to the problem problem, even if it is related to large updates of a zone instead of, for example, NSEC chains? How many times did named get wedged? According to the theory that the problem is related to large updates of policy zones, there should have been at most 3 instances of wedged named processes per computer and they should have happened during or soon after the end of large rpz.spamhaus.org transfers. My logs have these instances of transfers of rpz.spamhaus.org involving at least 100 messages during March (NTP disciplined UTC timestamps): 02-Mar-2013 21:45:42.511 07-Mar-2013 22:47:56.423 08-Mar-2013 03:19:46.419 08-Mar-2013 03:26:50.262 08-Mar-2013 07:27:13.176 08-Mar-2013 07:33:29.203 08-Mar-2013 10:07:05.829 08-Mar-2013 11:18:09.837 15-Mar-2013 22:52:02.969 16-Mar-2013 00:04:14.447 16-Mar-2013 07:21:07.576 16-Mar-2013 11:06:46.515 Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Blocking private addresses with a optionq
> From: "Lawrence K. Chen, P.Eng."
> ... So, being able to filter out these 'bad' things when responding
> queries against that data might be a good thing.
RPZ might be used for such things. However, by design RPZ rewrites
entire responses. It is triggered by individual records in a response,
but changes the entire response and not just individual records within
the response.
To use RPZ for such filtering, you would probably use views with
a response-policy{} statement in the external view to be filtered.
The RPZ rules could be triggered by rpz-ip records for 10.0.0.0/8 or
similar. The rules might rewrite responses to a CNAME or to sets of
A and records suitable for outsiders. That sounds a lot more
fragile and error prone than distinct zones for insiders and outsiders
specified in the view statements. However, RPZ might be good as a
failsafe against leaks (perhaps rewriting to NXDOMAIN).
Vernon Schryverv...@rhyolite.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: how to verify RPZ with a 'known bad' domain from 3rd party zone file?
> From: pgbi...@ml1.net
> I've bind 9.9.2p1 setup to use the RPZ zone provided by spamhaus.
> (1) How/where do you extract a bad domain name from the axfr'd RPZ zone
> file? It's not in what appears to be human-readable form.
As I wrote in answer to your message on Friday, try this command
for the DROP zone:
named-compilezone -j -f raw -F text -o- drop.rpz.spamhaus.org
drop.rpz.spamhaus.org
If you are now using rpz.spamhaus.org, try
named-compilezone -j -f raw -F text -o- rpz.spamhaus.org rpz.spamhaus.org |
head -4
Just now in my copy of that zone, that command suggests trying "forum.ac"
> (2) Once you have that domain, I assume (?) entering it into a browser
> should result in a browser redirect to 127.0.0.1 (?)?
If you use the "CNAME ." policy published by Spamhaus, then your browser
will get NXDOMAIN. You will get 127.0.0.1 only if you override Spamhaus'
policy with a clause similar to this in your response-policy{} statement
zone "rpz.spamhaus.org" policy cname bad-rpz.ml1.net;
and define
bad-rpz.ml1.net.A 127.0.0.1
Before messing with a browser, I'd try `dig forum.ac`
>In which DNS/bind
> log category do I look for evidence of that RPZ-redirection? In the
> query log?
If you read the friendly manual text though the link labeled
"Draft text for BIND9 Administrators Reference Manual (ARM) describing"
http://www.redbarn.org/dns/ratelimits as I suggested last week,
then you should find the "rate-limit" category and the querylog option.
Vernon Schryverv...@rhyolite.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Initial BIND 9.9.2 RPZ xfr (spamhaus) failing with "failed to connect: timed out" ?
> From: pgbi...@ml1.net > i've registered my nameserver IP with spamhaus for use of its RPZ list; > i've been approved for access. > 07-Mar-2013 13:26:25.657 xfer-in: error: transfer of > 'drop.rpz.spamhaus.org/IN/internal' from 199.168.90.51#53: > failed to connect: timed out > the RPZ log @ /var/log/bind-rpz.log is created on bind start, but is > completely empty. The RPZ log captures only information about response policy zone rewriting. A response policy zone is the same as every other local zone, so most problems with the zone itself are logged elsewhere. Depending on your ACLs, you can probe a response policy zone with `dig` or other tools just as you would any other local zone. Because I also have a local policy zone named drop.rpz.spamhaus.org, `dig 1.68.10.103.in-addr.arpa.drop.rpz.spamhaus.org` gives me an ANSWER section of 1.68.10.103.in-addr.arpa.drop.rpz.spamhaus.org. 300 IN CNAME . I chose that domain after looking at named-compilezone -j -f raw -F text -o- drop.rpz.spamhaus.org drop.rpz.spamhaus.org | head -4 I would try to diagnose this problem the same as other zone transfer problems. If a simple TCP request like `dig +vc 1.68.10.103.in-addr.arpa.drop.rpz.spamhaus.org @199.168.90.51` fails, then I'd look for the usual TCP problems such as firewalls. I'd also check that Spamhaus has authorized the local IP address that I'm actually using, perhaps as opposed to the IP address I requested. However, in recent days I have seen manual attempts to resolve individual zen.spamhaus.org domains time out. There are also a few 'timed out' entries in my current xfer log including at 25-Feb-2013 09:11, 07-Mar-2013 22:02, 07-Mar-2013 23:17, and 08-Mar-2013 00:17 GMT. There are zillions of successful transfers, and the last was at 07-Mar-2013 23:11. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 3rd party CNAMEs and open recursion
> > On 3/4/2013 3:26 PM, Verne Britton wrote: > > 1. serve the A records as authoritative > > 2. somehow handle resolutions coming at me for the CNAMEs > > 3. not have a public open recursive server > From: Kevin Darcy > You can achieve all of that as long as you provide recursive service > only *selectively* (otherwise, #2 degenerates into what you're trying to > avoid with #3). If you can't convince your users to use their own > resolvers when they are on the Internet, and you can't constrain them to > only certain source-address ranges (because they are geographically > and/or topologically diverse when they're on the Internet) the only > technical fix that comes to mind is to set up some sort of > crypto-authentication of your client's queries (e.g. TSIG or GSS-TSIG) > on the endpoints. You could use that to allow/deny recursion and/or > match views. Yes, but are they really using only the company resolvers and no other company applications? If they don't care about other company applications, why not tell them to use 8.8.8.8 or equivalents? If they have VPNs for other applications, why not use the tunnels for port 53 as well? On the other hand, DNSSEC seems to me to want a lot more resolvers a lot closer to applications, so why not install simplistic caching resolvers on the user systems? (such as a Windows copy of BIND, since this is the bind-users mailing list) (of course, suitably restricted to answering only 127.0.0.1 or ::1) When traveling with a Windows thing, I want to use my trusted, DNSSEC aware resolver. I wanted to use TSIG or SIG, but could find no way to tell Windows' stub anything about any keys. Tunnelling was easier than fiddling with BIND on Window, and works fine. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problems with resolving a local tld
> From: Robert Moskowitz > could work plugged in or isolated. Really now I could force things to > work as a subzone; or at least I think I am nearly to that point in the > upgrades. But there are some human interaction reasons for a very short > fqdn for a class of testing. It has to be typed in real fast in a > mobility demonstration, and it is the convenience factor for doing some > testing. So it is just for testing, and if I can't get it working to With "search" lists in /etc/resolv.conf (and the Windows equivalent) or checking /etc/hosts (and the Windows equivalent) before DNS (while ignoring the DNS ubber alles crowds), what is the problem with short local names? I often use short names inside my network. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problems with resolving a local tld
> From: Tony Finch > Another reason not to use made-up domain names: CAs are going to stop > issuing X.509 certificates for them. (It baffles me why they ever did so.) > http://ssl.entrust.net/blog/?p=1831 That's another reason to publish your own DANE records including TLSA and SMIMEA. Also consider this comment in that announcement: This issue is particularly a problem with Microsoft Exchange users where non-FQDN names are used frequently I wish that would be enough to get Microsoft to teach Exchange to use DANE. Why am I not surprised to see that the "recommended solutions" of https://www.cabforum.org/Guidance-Deprecated-Internal-Names.pdf linked from that Entrust.net web page mentions DANE or DNSSEC not at all but does include some less plausible "solutions"? Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problems with resolving a local tld
> From: Robert Moskowitz > > Well one really shouldn't be creating one's own tlds. > > As the instigator and a co-author of rfc 1918, I beg to differ. Many people considered the notion in RFC 1918 harmful. See RFC 1627. (My personal view was that standardizing the notion was better because it would minimize the harm suffered and caused by those who were going to use net-10 no matter what the other self-described experts, mavens, and gurus said.) > Many > have been using internal tlds for decades for various reasons. It works > fine for the client going to the servers of the zone, but my namecaching > server that is forwarding to same DNS server fails. Many things have worked fine for decades, are popular, and are even both popular and old. Many of those old and popular things cause significant harm to their perpetrators and to others and are just plain stupid in almost all of their existing installations, such as not following BCP 38 or running open DNS resolvers. In other words, what does your private htt TLD do that could not be done at least as well as a private, secret sub-domain of one of your legitimate domains? Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-recursion slowing server to crawl
> From: "Marco C. Coelho"
> Mark Andrews was right.
> This server was being hammered so hard that logging the rejects was
> killing the performance.
> adding:
> logging {
>category default { null; };
>//category lame-servers { null; };
> };
> On 2/27/2013 5:18 PM, Mark Andrews wrote:
> > I suspect this is just logging. send the security channel to null;
> > for a while. Once your server gets off the I'm a recursive reflector
> > lists you can turn it on again.
> >> I discovered my bind 9 server was being used in a DDOS attack so I
> >> decided (late) to block outside networks from making recursive
> >> requests. The problem is every time I enable this, the time for DNS
> >> queries goes from 0-1ms to 2000-6000ms or just times out completely.
> >> There are thousands of my clients that need recursion from this server.
> >> It is also authoritative for many domains.
> >>
> >> There is a semi busy mail server on this same box that uses DNS as well.
Turning off recursion for outsiders while allowing them authoritative
responses might not entirely stop the use of a DNS server reflection
attacks. If the server is one of the ones I suspect, then even with
recursion for outsiders turned off, it is remains useful for about 6X
amplification in a reflection attack. That's enough lower than the
10X or even 50X available from some others that the bad guys might
demote it. However, many of those have been fixed or are being fixed.
To really stop reflection DoS problem, I would install a current version
of BIND and then the RRL patch with RRL enabled for external DNS clients
and disabled for internal clients. See http://www.redbarn.org/dns/ratelimits
If RRL is too radical or can't be installed immediately, I'd still
get away from BIND8. See https://www.isc.org/software/bind/security
and https://www.isc.org/software/bind8/security/matrix
Vernon Schryverv...@rhyolite.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: disabling lame server logging
> From: Daniel McDonald > That's not to say that there is currently any cache-poisoning vulnerability > that someone might exploit, or that any current malware makes use of this > two-phase approach to exploit desktops. But why take the risk when setting > up bind as a recursive server pointing at roots is so trivial? It's not clear to me the risk of evil mail causing poisonous lookups is enough larger than other vectors for poisonous lookups to balance the costs and risks of additional DNS servers at a small site: - Partitioning your DNS cache among separate servers reduces its overall hit rate and so costs more RAM, CPU cycles, and bandwidth. (given the mention of zen.spamhaus.org, consider the records for .org) - Maintain another server costs additional system administration labor and system administration errors. - Having DNS broken only for mail by an hypothetical evil lookups is likely to be unnoticed for longer than when all DNS is broken, especially at small sites. - Every additional anything increases your attack surface, especially when it talks to the whole Internet. There are many situations where those costs are worthwhile, but they are less common at small sites. When two DNS servers are justified at a small site, I bet the best common tactic is to put all servers in all /etc/resolv.conf files or Windows equivalent, but with differing orders. For example, the mail system might prefer its own DNS server but fall back to another server. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-query and views
> The ARM says in part:
>
> Built-in server information zones
> The server provides some helpful diagnostic information through a
> number of built-in zones under the pseudo-top-level-domain bind
> in the CHAOS class. These zones are part of a built-in view (see
> the section called "view Statement Grammar") of class CHAOS which
> is separate from the default view of class IN; therefore, any
> global server options such as allow-query do not apply the these
> zones. If you feel the need to disable these zones, use the options
> below, or hide the built-in CHAOS view by defining an explicit
> view of class CHAOS that matches all clients.
Now that I read what I wrote, I see that it's wrong.
I found and just now verified that options{allow-query{}} affects
the _bind view at least in 9.10.0pre-alpha with the rrl and rpz2
patches. I found that feature (or perhap bug) when I decided to
stop hiding the version I use lest anyone think I don't do what I
advocate with BIND patches.
I don't know whether the bug is in the ARM or the code. If you
pick one, I can argue the other.
Vernon Schryverv...@rhyolite.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-query and views
> From: Robert Moskowitz > Whow... This is news. A hidden view? Where is this documented. The ARM says in part: Built-in server information zones The server provides some helpful diagnostic information through a number of built-in zones under the pseudo-top-level-domain bind in the CHAOS class. These zones are part of a built-in view (see the section called "view Statement Grammar") of class CHAOS which is separate from the default view of class IN; therefore, any global server options such as allow-query do not apply the these zones. If you feel the need to disable these zones, use the options below, or hide the built-in CHAOS view by defining an explicit view of class CHAOS that matches all clients. >I > have no restrictions in my general options section. Figured that the > specific view ones were all that was needed. Now I am upset. It's not a real view, because that you can't change it except by editing the BIND source, using the version, hostname, and server-id options, hiding it as the ARM says, or with default options. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: allow-query and views
> > correct, no external hosts should query your cache.
> >
> OK.
There is no substitute for testing assumptions, mailing list assurances,
understandings of documentation, etc. Test from outside your network
to see that your DNS servers don't answer requests they shouldn't and
answer those they should as they should (e.g. with(out) consulting the
cache).
Don't forget to check `dig @whatever chaos txt version.bind` whether
your preference is to publish your version, hostname, and server-ID
or not. Restrictions such as allow-query{} in the main options{}
statement can turn off the hidden "_bind" view defined in
bin/named/config.c.
https://www.google.com/search?q=dig+command+web
finds at least three web pages with loose enough parsing to allow not
only simply requests for A records but poking at chaos, so you don't
need to pay for a shell account somewhere or rely on charity.
Vernon Schryverv...@rhyolite.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Registrar that supports self-run domains and provides DNSSEC support
> From: Tony Finch > > GoDaddy supports everything you're looking for. > > Though you might prefer to use a less repulsive provider. > http://kottke.org/11/12/the-internets-go-daddy-issues Those issues seem at most secondary to the objections some people have to how GoDaddy has dealt with the Internet and GoDaddy customers. https://www.google.com/search?q=nodaddy.com http://www.theregister.co.uk/2011/07/12/godaddy_shuts_down_nodaddy/ My experience wrestling the domains of relatives from GoDaddy was not as bad as some of the stories, but it took more time, effort, and sophistication than some people would care or be able to muster. GoDaddy also likes to "up sell" many "protection" and other services whose value I don't understand. During our wrestling match, GoDaddy started sending warnings that some sort of "mailbox" service would not start without the replacement of an expired credit card. The credit card had been previously used for automatic renewal of the domains. I did not knowingly ask for the "mailbox" service, but maybe I clicked the wrong link on a web page. About 8 years ago I got stupid spam from GoDaddy's QuickSizzle bulk mail advertising service. Network Solutions is the only other major registrar that won an entry in my personal email blacklist. Network Solutions was more persistent about trying to send me unsolicited advertising, but it was always for Network Solutions instead of random Internet entrepreneurs like GoDaddy's QuickSizzle service. Never mind the spam support charges; half a decade is long enough to want to forget the less clear cut issues. https://www.google.com/search?q=godaddy+quicksizzle It was not hard to escape Network Solutions when I did it. (I didn't choose Network Solutions after SRI; I think that was the DoC.) I cannot recommend the registrar reseller or the wholesaler that I've used since NetSol to anyone who cares about IPv6 glue or DNSSEC. They couldn't handle my DS RRs in plain text mail (no MIME). It wasn't until I put the RRs on a private web page that they could cope. I've ducked IPv6 glue by using https://sns.isc.org/ for secondary DNS services. I'd recommend SNS@ISC, but you might think me insufficiently disinterested. There are registrars that people recommend generally and for IPv6 and DNSSEC, but I've not used them. I could switch, but even when the old registrar cooperates, switching costs some time and effort and risks breakage. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: broken ISP in china
> I see no problem with your SPF IP records though so long as you dont try > use ns1. Ignoring most of Vernons anti SPF rhetoric, which BTW this > list is NOT the place for (go cry a river on mailop list), he is > correct that you shouldn't really be using PTR, or A for that mater, > just have your ip4: and ip6: ranges, and perhaps "mx" and along with > "-all" you'll be fine, I have no problems with SPF and lists and have > been using it since very early days, Instead of swallowing the SPF liturgy without chewing, use it and what anyone (including me) says as ideas for your own observations and tests. Follow the DMARC instructions on http://www.dmarc.org/ and get the DMARC reports telling you that your SPF -all prevents the delivery of some of your mail to this mailing list. Then get Gmail and Hotmail mailboxes, configure Hotmail to forward to Gmail and send to Hotmail. You will see in your DMARC reports from Google that your SPF -all causes your message to disappear in a blackhole between Gmail and Hotmail. See also http://www.openspf.org/FAQ/Forwarding and note that neither Hotmail forwarding to Gmail nor many mailing lists including this list rewrite the sender addresses. That has generally been considered a wrong thing to do since long before pobox.com existed. Finally, look at the SPF records for AOL, Google, Yahoo, and Microsoft, and ask yourself whether those organizations don't care about SMTP forgery or don't believe SPF is an answer. If they believed, wouldn't they use SPF -all? > I have no problems with SPF and lists and have > been using it since very early days, Maybe it was easier to ignore reality before DMARC. On the other hand, http://www.openspf.org/FAQ/Forwarding is unambigous about the interaction of -all with mailing lists such as this. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: broken ISP in china
> From: Lyle Giese > attention and I tried to email the client in China and got this back: > > For <mailto:ro...@medtecs.com.cn>, Site > (x.com.cn/) said: 559 sorry , your helo/ehlo and > domain in mail are invalid, you don't connect from there. (#5.5.9) > > Because this started within 24 hours of when I published the DS record I'd remove the TXT record for lcrcomputer.net and try again in 24 hours after your TTL expires. In other words, could your SPF record be triggering the mail problem? What is the relationship between medtecs.com.cn and x.com.cn? If your mail must be forwarded to reach ro...@medtecs.com.cn, then your SPF record demands that it be rejected after the first hop. I also wonder about the "ptr" mechanism in your SPF record. RFC 4408 discourages the use of "ptr". The Received: header added by ISC was unhappy with your reverse DNS, although it looks ok to me now: Received: from mail3.lcrcomputer.net (unknown [IPv6:2607:fcb8:1800:7::3]) by mx.pao1.isc.org (Postfix) with ESMTP for ; Mon, 18 Feb 2013 22:07:46 + (UTC) (envelope-from l...@lcrcomputer.net) Contrary to the early marketing manure followed by the years of cult chanting, outside the narrow situations where it can be handy, SPF is useless and ignored (~all or ?all) or harmful (-all). SPF can be useful for authenticating bulk mail, although DKIM is better because of SPF's problem with forwarding. (Of course, plenty of bulk mail is not spam, such as this message after it hits the reflector. Bulk mail is any set of practically identical messages. Spam is bulk email that is also unsolicited.) If you turn on DMARC to get reports about rejections by adding something like this line to your DNS zone: _dmarc 300 TXT "v=DMARC1; p=none; rua=mailto:x...@lcrcomputer.com;"; and send again to this mailing list, then within days or a week, the mailbox x...@lcrcomputer.com should get reports of mail that would have been rejected by your SPF record. If any of your correspondents forward private mail from you to Google, Microsoft, or similar, you will also get reports about those rejections. I've not tried p=none, but recent experiments with 300 TXT "v=spf1 mx -all" _dmarc 300 TXT "v=DMARC1; p=reject; rua=mailto:x...@rhyolite.com;"; generated reports of my messages being rejected because they had been forwarded by lists.isc.org. Look at the headers for your copies of your own messages to this mailing list and consider your SPF record. (I use short TTLs on _dmarc and SPF RRs to remove them quickly.) See http://www.dmarc.org/ about DMARC, but read it with marketing-speak filters set to high. For example, "DMARC Protects 60 Percent of Global Consumer Mailboxes" makes sense only for a narrow meaning of "protect" after you notice the absence of _dmarc records for Google, Yahoo, and Microsoft. See also http://www.dmarc.org/about.html Some of the "receivers" on that page probably send more mail than some of the "senders," so those two words must have special meanings. DMARC is evidently intended to let "(bulk mail) senders" such as American Greetings, BoA, etc. monitor and control their DKIM and SPF authenticators and check inbox placement rates at "(bulk mail) receivers" such as AOL, Comcast, etc. DMARC is also unintentionally great for showing the old "use SPF to protect yourself from spammers" to be the marketing nonsense and cult nonsense for in most cases that it has always been. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Free secondary servers supporting DNSSEC?
> From: Robert Moskowitz > The Redhat docs on bind had a warning about not implementing features, > like DNSSEC if your secondaries doesn't support it. That is all I am > going on. I think I also saw it in some isc.org doc. In your position, I'd publish the RRSIG and NSEC* records (i.e. sign the zone) and see what breaks. Maybe I'm ignorant and naive about DNSSEC (I'd like to hear about it), but I'd expect nothing bad to happen with the secondaries. And if they're running such incredibly ancient code that something breaks, then they probably have serious security issues unrelated to DNSSEC that should disqualify them as secondaries. You'll have to do something like that while you fight with Network Solutions to deal with your DS records or switch to another registrar. My recollections of past mailing list comments as well as https://www.google.com/search?q=network+solutions+dnssec https://www.networksolutions.com/search.jsp?searchTerm=dnssec https://www.icann.org/en/news/in-focus/dnssec/deployment suggest that effort will be interesting. Have you started it? At the end of a long saga to get DS RRs for the handful of my domains, Tucows/Opensrs said "Please try not ask us do that again soon." Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Free secondary servers supporting DNSSEC?
> From: David Forrest > > In any case, some naming and shaming seems appropriate. Basic > > Naming and shaming seems excessive for a "free" service. Services that do not charge users money are often not really free. That this case might cost security instead of eyeballs should not exempt it from scrutiny or criticism. If today were 2003, if the lack of support were for the DANE types, or if primary DNSSEC service with auto-signing was supported, then maybe it would be ok. For a reductio ad absurdum example, what would you say about a free DNS secondary service that replaces your A records with others with IP addresses of an advertiser (and tiny TTLs) for 10% of requests? Done carefully, including not messing with MX and some other types, it wouldn't completely wreck a small web site. https://www.google.com/search?q=dns+hijack The important and undeniable scandal is the lack of support from registrars for DS RRs. Speaking of DNSSEC, I've been watching the graphs on http://scoreboard.verisignlabs.com/ for months with growing incredulity. How can the counts or percentages for .com and .net be growing so amazingly consistently? Where are the dips and bumps you'd expect for holidays? Why isn't there far more noise in the graphs? Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Free secondary servers supporting DNSSEC?
> From: Robert Moskowitz > One of my secondaries, though, does not support DNSSEC How does a secondary authoritative DNS server fail to support DNSSEC? It's not as if it would be doing any signature checking or automagic (re)signing. Does it not tolerate the not at all new RRSIG and NSEC or NSEC3 record types? Or does not not haves EDNS support? In any case, some naming and shaming seems appropriate. Basic DNSSEC support (i.e. maybe not yet TLSA or SMIMEA) is a fundamental checklist item today. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dns_journal_write_transaction on managed-keys-zone
> From: Thomas Leuxner
> After introducing views in my BIND 9.9.2-rpz+rl.028.23-P1 configuration
> the log starts to report managed keys errors periodically. ...
I believe that nothing in the rpz+rl.028.23-P1 patches from
http://www.redbarn.org/dns/ratelimits changes anything that might cause
managed key errors. That raises the obvious questions:
- Was the previous version that did not have those errors BIND 9.9.2?
- Was anything changed besides installing the patch in the BIND source
and the rate-limit{} statement in named.conf?
Vernon Schryverv...@rhyolite.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Exclude a domain from DNSSEC validation, like Unbound's "domain-insecure".
> From: Mark Andrews > > All of that gets back to honesty being the best policy and letting other > > people fix their own stuff in their own time. > > And the more people that validate the bigger the peer presure will > be to fix dnssec problems promptly. However to do that you need > working whois services to be able to contact the administrators of > the zone by other means. Gov's whois service is a joke. No contact > information at all. Can't even list the main switchboards? For better or worse, useful WHOIS data is a lost cause. Spammer fighters too stupid or egotistical to understand or admit how easy it has always been and always will be for illegal spammers to invent, steal, rent, or borrow phone numbers and addresses made themselves such pains to legal spammers that they created a market for spammer shields. Not to miss profits, ultra-cheap registrars catering to spammers flogged their spammer shields to the punters as protection against spam and stalking. Since then the punters have been taught to expect privacy shields bundled for free with their cheap domain registrations. And that's only where governments haven't decided that only they should know everything about everyone and made valid WHOIS data illegal. My view is that if an outfit has so few other users that it doesn't hear when things breaks and doesn't care enough to monitor, then it's not worth my time to be a pest. By time I notice a problem with a non-trivial domain, those responsible will already be on the job and I would only an irritating user or luser. They will already have been alerted by their monitors as well as hordes of other lusers. In other words, when did you last alert strangers about lame delegations? Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Exclude a domain from DNSSEC validation, like Unbound's "domain-insecure".
] from Augie Schwer
] Is there a way to exclude a domain from DNSSEC validation, like
] Unbound's "domain-insecure"?
Unless you start at the root with your own forged root trust anchor,
you cannot do more than lie to DNS clients that rely on you to
validate. DNS clients that do their own validation starting with
their copies of the root trust anchor will always see the problem.
If it were otherwise, then any resolver or firewall in the path
could pervert any and all DNS bits.
] For example if a popular site ( say nasa.gov ) updates their keys
] incorrectly so that their domain fails validation, you contact their
] admins. and with a high level of confidence you determine this is a
] configuration mistake and not a security breach, you can then
] exclude them from DNSSEC validation so your customers can access their
] site while they fix their error.
In such cases, wouldn't it faster, easier, and generally better to
wait a few seconds for those administrators to fix their keys and then
use `rndc flush` or restart your resolver?
There were Comcast's negative trust anchors to address such problems for
Comcast customers.
https://www.google.com/search?q=negative+trust+anchors
It looks as if Comcast has stopped using them.
http://dns.comcast.net/
> From: Carl Byington
> I have not tested this, but if you use RPZ to block the DS record for
> nasa.gov, that should turn it into an insecure zone.
I don't see how to use RPZ to block only the DS record, because the
DS record is in the parent zone and because RPZ lies about all records
for a domain instead of only a single record type.
You might use RPZ to rewrite and fix an entire zone if you include
"break-dnssec yes" on the response-policy{} statement. However, DNS
clients that do their own validation will still notice that your fixed
version does not verify and throw fits. If you could somehow hide the
DS RRs in the parent zone from them, they would notice that the NSEC
or NSEC3 records fail to authenticate the absense of the DS RRs.
I do not see a way to do use RPZ to fix bad keys for nasa.gov,
because nasa.gov contains no A or records.
There are A and records for www.nasa.gov, but trying to fix a
hypothetically broken www.nasa.gov looks painful to me, because
www.nasa.gov has the messy, broken DNSSEC chain of CNAMEs of an akamaized
domain.
All of that gets back to honesty being the best policy and letting other
people fix their own stuff in their own time.
RPZ is a fine tool for breaking and generally trashing a domain.
That can a good thing when bad things such as "drive by malware"
would happen if the domain were working. It's hard to build or fix
things with a wrecking ball.
Vernon Schryverv...@rhyolite.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Selective resolution in a corporate environment
> From: Evan Hunt > > IMHO (and I am really nobody) THIS IS WRONG! BAD BAD BAD! Your giving compa= > > nies the ability to selective lie about DNS without the end user knowing it= > > Unless DNSSEC is in use, in which case the end user can figure it out, > so RPZ doesn't bother lying. Unless the "response-policy" statement says "break-dnssec". In that case, the lie is sent as if the request had not asked for DNSSEC. The DNS client can still notice change even if it doesn't do its own RRSIG verification. > (I've wished before that there were some EDNS(0) options that could > indicate "this answer has been changed due to local resolver policy" in a > response, or "seriously: do not lie to me" in a request, but it's hard to > see how there'd be any enforcement or verification mechanism for these, > whereas DNSSEC already has all the crypto needed to get the job done.) Yes, the only sane strategy is to assume that your adversaries can block whatever they want and introduce any lies they like into any wires you don't control. In other words, a "changed by policy" flag in responses would be as useful as the Evil Bit defined in RFC 3514. A "don't lie" flag in requests might be useful when applications that don't want lies and others that need lies (e.g. browsers using RPZ for malware protection) share a resolver. However, the same effect can be had by with separate resolvers or a resolver that lies only when asked on some ports or IP addresses. BIND views are just as much about lying as RPZ. I've long wanted better ways for application code I've written to adjust resolver choices than whacking /etc/resolv.conf. You can pervert the _res interface, but it's worse than ugly. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Selective resolution in a corporate environment
> From: Shawn Bakhtiar (about RPZ) > IMHO (and I am really nobody) THIS IS WRONG! BAD BAD BAD! Your giving compa= > nies the ability to selective lie about DNS without the end user knowing it= > . Unfortunately (and I have the heights and greatest respect for Paul) but = > after reading this http://www.isc.org/community/blog/201007/taking-back-dns= > -0 I can only think of one thing. China. China doesn't need and doesn't use the BIND RPZ code to lie about DNS records millions of times per day. There are far better ways to do the sorts of things that the Great Firewall does. Ranting about evil RPZ is like demanding that ships off the Horn of Africa be unarmed because trigger happy guards might blow up innocent fishing vessels. In the real ocean, the serious bad guys had big guns and were using them very profitably until the good guys hired guards and warships and made priracy less attract https://www.nytimes.com/2012/08/29/world/africa/piracy-around-horn-of-africa-has-plunged-us-says.html The easy defense against RPZ is DNSSEC. If you care about DNS security, then your DNS zones have good RRSIG RRs. If your interests in security go beyond ranting about the weapons choices of other people, then you are a running current version of a DNS resolver that verifies DNS data by default and says SERVFAIL instead of repeating lies. You are also doing whatever you can to get TLSA to replace the stupid security theater that is commercial PKI. You at least publish TLSA RRs with the fingerprints of your commercial PKI certs. https://tools.ietf.org/html/rfc6698 https://tools.ietf.org/html/draft-fanf-dane-smtp-04 https://tools.ietf.org/html/draft-hoffman-dane-smime-04 Speaking of BIND RPZ code, new versions that I hope are faster are available with the RRL patches. See the link on http://www.redbarn.org/dns/ratelimits There is also the RPZ mailing list at https://lists.isc.org/mailman/listinfo/dnsrpz-interest Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: injecting a temp entry into dns cache
> > There is a credit union website that our users access from work and > > their dns has been broken for the past few days where the www. version > From: Jeff Reasoner > I elected to add the zone in named.conf and answer the query correctly > (and authoritatively) until I could get the owner to correct things. You > will probably need to add other zone records too - MX and any other A > records you can think to search for. > Personally, I wouldn't consider doing something like that in this > situation as you've described. ... On my own computers and for my own busines, I add temporary lines to /etc/hosts every few months to deal with such problems. However, hacking a financial institution by publishing false DNS data to third parties (including employees) would promise too much excitement and too little profit for my tastes, especially after talking about the crime in public. I doubt that I could convince a court of technical facts or that I was doing the credit union a favor. The credit union would probably convince the authorities (including the newly sprouting bureaucracy run by the same people who are in charge of the TSA) that I was responsible for the whole mess from the beginning. Besides, do you really want to help drive business to that kind of financial institution? If its trivial records like DNS are a persistent mess, what about the complicated banking records required by law? If it were competent, the credit union would be using DNSSEC, which make a local DNS zone useless. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: MNAME not a listed NS record
> From: Dave Warren > Various online DNS diagnostic tools throw warnings, Speaking of so called DNS diagnostic tools, one claims that my domains have DNS servers with "private" network addresses. My only guess is that they don't know the difference between IPv6 addresses and RFC 1918 addresses. On the other hand, maybe that was random FUD intended to drum up business, because they've stopped that nonsense in the last 3 days and without my changing anything. Another tool claims that ns3.isc-sns.info is "not sending glue" for one of my domains. That one is among the several that claim that having a single MX record is a defect instead of a feature in this century. (On today's Internet, where all SMTP clients from which you might want to receive mail can reach all of your SMTP servers at almost any time and do proper queuing for during very rare exceptions, one needs only one MX RR. Unless you want to load balance millions of messages per day among SMTP servers on multiple networks, you want a single a MX RR to avoid spam backscatter without having to synchronize your definition of "valid mailbox" at the distributed SMPT servers needed in the multiple-MX wisdom of the previous centurywell, there is the exception of bogus MX RRs for trapping spam.) Then there is the supposed dire insecurity of answering `dig ch version.bind txt` Let's not forget the popular DNS checkers that claim my SMTP servers are open relays. Don't ask me about technical connections to DNS health in seeing whether an SMTP Rcpt_To command is answered with 250_Ok. The spammers who continually hit my SMTP servers with floods of checks of common holes in relay authentication and authorization evidently know that 250_Ok even at the end of a DATA command doesn't indicate that an SMTP server has relayed anything. There is a common thread among the bogus DNS health checks from outfits in the DNS help business and the worst domain registrars. Their sales stories are based on the notion that DNS, HTTP, SMTP, and the Internet in general are too complicated, dangerous, and generally scary for mere humans to handle, and so you'd better buy their patent medicine. On the other hand, good outfits simply sell competent services, perhaps including technical support, but always without acting like proverbial used car and computer saleslime. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: gitnamed, a project to manage name server by git
> When I built my DNS zone creator, I got tired of users complaining that > their zones has "errors" and so I re-coded my serials to start with > followed by six digits based on the current date/time. > > Oddly, that seems to fool most (although not all) of the DNS validation > tools out there, despite the fact that I generate things like 2012804572 > which doesn't exactly have a "valid" MM or dd. For many years I've found serial number checks good indications of whether a DNS validation tool's report will be a bad joke. If it checks the serial number format, then that's often the least harmful among the FUD that it's selling. I just tried some DNS "validation" tools, and revalidated that rule and another. The other rule is that if they sell DNS and other monitoring services, then they will flash red and yellow about your serial numbers, your MX servers, and a host of other non-issues that you almost certainly should not "fix." Even if RFC 1912 were not Informational, it would still only recommend and not mandate MMDDnn. Even if RFC 1912 were on the standards track and said "MUST", it would be violated in zones that change more than 100 times per day. How long has BIND9 had "serial-update-method"? > I've given up contacting so-called validation tools and asking them to > remove warnings about valid serials, they seem happier reporting > non-errors, and at best they'll return a "Not standard, but I guess it's > okay". It's a shame too, as these tools can provide a sanity check. What good are sanity checks from the certifiable or worse? Do you take medical advice (or any advice) from those who claim that DPT vaccines cause autism? https://encrypted.google.com/search?q=whooping+cough+worst+1955 It's sad but predictable that DNS validation/monitoring services are like some auto repair shops. Last week my wife took her car to the dealer for a minor recall. She came back with a long list of expensive things that she should have had fixed before leaving the dealer--provided you're car clue allergic, credulous, and don't have anyone to shout "NO!" when asked. On the other hand, the dealer's careful inspection failed to note the idiot light warning about a low tire. (cue discussion with wife 2 mornings later when I noticed the flat tire about the "flame (sic)" idiot light that she'd been watching since before the trip to the dealer and that obviously didn't matter because high temperatures can only be a good thing given the weather.) Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Getting RPZ statistics
> From: "Howard, Christopher Bryan"
> I recently (as of 2 days ago) enabled RPZ on all of my name servers. I cur=
> rently use "rndc stats", perl, and SNMP to make certain global stats availa=
> ble to our network monitoring system to make charts (number of queries acro=
> ss all views and such). I'd like to do the same for just the RPZ zone so I=
> can get an idea of how many queries are getting handled by RPZ itself.
In a useless sense probably not intended, the number of queries
handled by RPZ is the same as the number of queries handled by
the normal zones in the views with "response-policy{}" statements,
because all queries are tested against the policy zones.
The short answer to the likely intended question is that there are
no RPZ specific statistics. One might want the number of responses
rewritten according to each policy zone, but those statistics don't
exist. I agree that the idea is worth thinking about.
Recent versions of the BIND9 RPZ code has improved logging. On DNS
servers that are not too busy, it might be possible to synthesize
useful RPZ statistics with awk/perl/whatever applied to the RPZ log
category.
Vernon Schryverv...@rhyolite.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
