validate-except (I typo’d it the second time, unfortunately expect and except are both valid words).
https://downloads.isc.org/isc/bind9/9.16.6/doc/arm/Bv9ARM.pdf validate-except This specifies a list of domain names at and beneath which DNSSEC validation should not be performed, regardless of the presence of a trust anchor at or above those names. This may be used, for example, when configuring a top-level domain intended only for local use, so that the lack of a secure delegation for that domain in the root zone does not cause validation failures. (This is similar to setting a negative trust anchor except that it is a permanent configuration, whereas negative trust anchors expire and are removed after a set period of time.) > On 11 Sep 2020, at 15:57, Rob McEwen <r...@invaluement.com> wrote: > > Mark, > > You gave me the "let them eat cake" answer I anticipated. Also, this isn't > fixing a problem that my services produce - it is preventing a problem that a > potential MISTAKE from a large customer would cause - the type of mistake > that is inevitable at some point, but likely short-lived. That's on them, not > me. But I can sleep well at night knowing that such MISuse of my service > isn't going to take out an entire datacenter for hours (with MANY innocent > bystanders taken out, too!) with a DOS attack due to those queries NOT ending > with a valid/public domain name, thus making such an attack impossible. > (again, just referring to our very largest customers' DNSBL queries). The query traffic is still getting answered. It doesn’t magically disappear. Its just a matter of who is paying to answer that traffic. If you actually used a zone names with a DNAME at the apex pointing to EMPTY.AS112.ARPA in the public instance, broken servers would leak a couple of queries until the DNAME is cached then the rest of the traffic would be absorbed by the local resolvers and never leave the machine. e.g. example.invaluement.com. DNAME EMPTY.AS112.ARPA. example.invaluement.com. SOA … example.invaluement.com. NS <name.not.under.example.invaluement.com>. EMPTY.AS112.ARPA. returns NXDOMAIN for all names under it and it is a distributed service. Named and other recursive servers instantiate instances of EMPTY.AS112.ARPA automatically. Mark > I did a search for "bind9 validate-expect named.conf" (but not in quotes) - > and shockingly LITTLE came up that specifically references that - pages came > up regarding everything else under the sun involving BIND, but I didn't see > anything specifically about that. Do you have a link for that? I'll try to > research that more to try to figure out what exactly you were suggesting. > > Rob McEwen > > On 9/11/2020 1:32 AM, Mark Andrews wrote: >>> On 11 Sep 2020, at 15:04, Rob McEwen <r...@invaluement.com> wrote: >>> >>> Mark, >>> >>> The whole usage of DNS by the anti-spam industry in our DNSBLs - is >>> somewhat a hack on the DNS system from the start - I guess if you think >>> that is wrong, maybe you should take that up with Paul Vixie? >> And Paul will tell you to use a name you control. We did that with >> DLV.ISC.ORG. We are still absorbing that traffic despite there being no >> entries in the zone for several years now. We knew we would have to do that >> going in. >> >>> And the whole purpose for MANY of us DNSBLs using ".local" in the first >>> place - was precisely to PREVENT the queries from possibly leaking out of >>> our largest customers LANs - because in many cases, that would an >>> essential denial of service attack against us (and our hosters, etc). For >>> example, some DNSBL customers literally have a billion mailboxes. I have a >>> couple of customers with a few hundreds million mailboxes. I'm pretty sure >>> Spamhaus has a few with a billion. Do you have any idea how many emails are >>> processed per second for a billion mailboxes? (especially mid-morning >>> during a business day!) It's enough to where it takes multiple rbldnsd >>> servers each serving thousands of queries per second. To keep up with that >>> volume, these MUST be locally-hosted rbldsnd servers. In that situation, >>> if/when there is a slight DNS mistake - such as some software update >>> mistakenly rerouting DNS to something like "8.8.8.8" - as OFTEN (stupidly!) >>> happens - and then, in the case of Spamhaus' customers with a billion >>> mailboxes - that traffic will massively hit both Google and "spamhaus.org" >>> DNS servers - or even if the forwarder got deleted mistakenly, the same >>> will still happen for "spamhaus.org" DNS servers. Even if those servers can >>> handle the traffic - it might overwhelm a local router in between, or >>> overwhelm the particular DNS server to which this traffic is assigned. This >>> then turns into a NIGHTMARE DOS attack for such DNSBLs. Therefore, the >>> ENTIRE point of using such zone names (".local", ".dnsbl", etc) internally >>> - is to PREVENT the queries from possibly ever leaving the LAN. That is >>> why, for these largest customers, using hostnames that end in our own >>> domain names - is not an option. (and when it does work, it is often a "let >>> them eat cake" option - where only the largest Internet companies with >>> billions in revenue - can afford to handle such traffic - so please, don't >>> respond with a "let them eat cake" answer!) But that overall point about >>> how DNSBLs work in such situations... seems lost on you. >>> >>> The very reason I used ".dnsbl" as an example - is because I did a little >>> research after before last email - and it turns out that - maybe in >>> response to the RFC you pointed out that took a position against using >>> ".local" - Spamhaus then (apparently) switched to using ".dnsbl" - (or >>> maybe they were using ".dnsbl" all along? - I can't keep track over every >>> other DNSBL - but ".local" was popular for many DNSBLs for many years.) >>> Spamhaus doesn't use that for their direct query service - but it appears >>> that they're using that for the instructions for their customers who RSYNC >>> the data. Therefore, you just harshly criticized me for suggesting doing >>> what Spamhaus ALREADY does - so I guess I'm in good company! >> Two wrongs don’t make a right. If you think queries will leak then >> provision services to absorb those leaks. The root operators shouldn’t have >> to absorb that traffic. RFC 1918 DNS traffic leaked and services where >> stood up to absorb that leaking traffic. There is nothing stopping you from >> doing something similar. Absolutely nothing. >> >>> Really - your purism - and harsh realities of large DSNBL operations - are >>> not compatible. >> No, its taking ownership of the problems that your operations produce. You >> are cost shifting by not doing so. >> >>> And no - you NEVER gave me an answer - and guess what? While I have >>> tremendous respect for RFCs in general, and try hard to follow them - they >>> are NOT perfect - on rare occasion, some of them SHOULD be broken and DO >>> have errors or situations that they didn't anticipate. This one of those. >>> RFCs were written by humans. Humans make mistakes >> Actually I did. I said "add validate-expect entries to named.conf”. >> >>> And it's too bad that the maintainers of BIND didn't anticipate that there >>> might be local-data situations where sys admins should be given the ability >>> to turn DNSSEC off for a particular zone. Your answers are helping me to >>> understand HOW/WHY such decisions were made. But rigidity/purity doesn't >>> always equal wisdom/intelligence. In this case, it doesn't. >>> >>> Rob McEwen, invaluement >>> >>> On 9/10/2020 10:23 PM, Mark Andrews wrote: >>>>> On 11 Sep 2020, at 11:13, Rob McEwen <r...@invaluement.com> wrote: >>>>> >>>>> Mark, >>>>> >>>>> Most invaluement subscribers do direct queries - to hostnames that end >>>>> with my own valid domain names that don't have this DNSSEC issue - those >>>>> are the ONE ones that make use of public DNS and are broadcast across the >>>>> internet. >>>>> >>>>> Our usage of ".local" zones for those who are RSYNC'ing our data - dates >>>>> back to something like 2007, and the RFC you referred to is from 2013. By >>>>> the time this RFC had been published, we'd already had customer using the >>>>> ".local" for 6 years. At the time that came out in 2013, I assessed >>>>> whether I needed to get my clients to change that, but it didn't seem to >>>>> effect anyone. Again, those of our subscribers who RSYNC our data and use >>>>> the ".local" zone names - are just using that for 100% local usage, and >>>>> are not trying to broadcast it across the internet. And in many of THOSE >>>>> cases, if the BIND and RBLDND are on the same computer, as is often the >>>>> case, it doesn't even go out to the LAN - this is all on one single >>>>> computer. >>>> And you squatted on .local then and are paying the price now. It has >>>> always been wrong to use a name that has not been delegated to you. The >>>> point of having delegations in the DNS is to prevent multiple entities >>>> using the same name and to give certainty to those the name is delegated >>>> to. That has been the case since the DNS was developed. >>>> >>>> As for not leaving the machine, that machine is connected to a network >>>> where mDNS may be in use. That creates a namespace collision on that >>>> machine. What does invaluement.local mean on the machine? Does the >>>> machine use mDNS or DNS to resolve the name? >>>> >>>>> So are you claiming that if I simply changed the zone naming form ending >>>>> in ".local" - to something else - such as ".dnsbl" - then all my problems >>>>> would go away? And the forwarder will start working? (even though rbldnsd >>>>> doesn't do DNSSEC) >>>> No. You have not been delegated ".dnsbl”. IANA/ICANN owns *every* >>>> possible tld name not delegated / allocated to someone/something else. >>>> Any TLD that you pick will have the same issue. DNSSEC proves what >>>> exists, what doesn’t exist, and what isn’t secured by DNSSEC. >>>> >>>> You have a effectively infinite number of names below invaluement.com. >>>> Pick some of them and use them. invaluement.com isn’t signed so your >>>> customers won’t have DNSSEC problems. When you decide you want to sign >>>> invaluement.com you will need to break the DNSSEC chain of trust by having >>>> a delegation in the invaluement.com which doesn’t have a DS record with it. >>>> >>>>> That would be EXCELLENT news! Or, if that doesn't actually fix my >>>>> problem, do you have any suggestions that actually address my actual >>>>> question? >>>> I gave you a answer. See below. >>>> >>>> Mark >>>> >>>>> Rob McEwen >>>>> >>>>> On 9/10/2020 7:37 PM, Mark Andrews wrote: >>>>>> .local is for mDNS (RFC 6762). Do not use it for other purposes as you >>>>>> are hijacking the namespace. >>>>>> >>>>>> The best solution is to NOT change the name of the zones from those that >>>>>> you use publicly. That way they have the correct DNSSEC chain of trust >>>>>> down from the root. If you want to use different zone names then create >>>>>> delegations to empty unsigned zones (SOA and NS records only) like those >>>>>> done for 10.IN-ADDR.ARPA in a zone you control. That breaks the DNSSEC >>>>>> chain of trust at the delegation point. If you later decide you want to >>>>>> sign these zones you can do so and link them into the DNSSEC chain of >>>>>> trust. Just sign both the rbldsnd-formatted files and the empty zones. >>>>>> >>>>>> If you absolutely must continue to hijack the .local namespace, which is >>>>>> allocated for a different purpose, then add validate-except entries to >>>>>> named.conf >>>>>> >>>>>> Mark >>>>>> >>>>>>> On 11 Sep 2020, at 01:56, Rob McEwen <r...@invaluement.com> wrote: >>>>>>> >>>>>>> I manage an anti-spam DNSBL and I've been running into an issue in >>>>>>> recent years - that I'm FINALLY getting around to asking about. I just >>>>>>> joined this list to ask this question. Also, I checked the archives, >>>>>>> but couldn't find an answer - at least, not one I understood. >>>>>>> >>>>>>> So basically, while most of our users do direct queries and don't have >>>>>>> this issue - some of our larger subscribers RSYNC the rbldsnd-formatted >>>>>>> files, and then they typically run rbldnsd on the same server as their >>>>>>> BIND server that is answering their DNSBL queries. Then, their >>>>>>> invaluement zone names will all end with "invaluement.local". >>>>>>> Typically, their RBLDNSD server is set up to listen on 127.0.0.2 - and >>>>>>> then they use BIND for answering their DNSBL queries, and so they tell >>>>>>> BIND to get its answers for THOSE invaluement dnsbl queries by doing a >>>>>>> DNS forwarder, telling bind to get the answers for THOSE zones from >>>>>>> 127.0.0.2 - as shown below: >>>>>>> >>>>>>> zone "invaluement.local" in { >>>>>>> type forward; >>>>>>> forward only; >>>>>>> forwarders { 127.0.0.2; }; >>>>>>> }; >>>>>>> >>>>>>> This works perfectly - so long as DNSSEC is turned off. And since most >>>>>>> of our subscribers are running a dedicated instance of BIND that is >>>>>>> ONLY used for DNSBL queries, they don't mind turning DNSSEC off. >>>>>>> >>>>>>> But, occasionally, we have a customer who cannot turn DNSSEC off. So I >>>>>>> was hoping that THIS command would work: >>>>>>> >>>>>>> dnssec-must-be-secure "invaluement.local" no; >>>>>>> >>>>>>> But it doesn't seem to be helping at all. Is that command suppose to >>>>>>> disable DNSSEC checking for a particular zone? If yes, what did I do >>>>>>> wrong? If not, what does "dnssec-must-be-secure" set to "no" do? >>>>>>> >>>>>>> I've heard that there is NOT a way to get this to work - and that such >>>>>>> subscribers much use DNS Delegation, instead. But I really wish >>>>>>> this could be done by simply turning off DNSSEC for a particular zone. >>>>>>> That could be useful for MANY various types of internal zones that need >>>>>>> this. But if this is that case, how would that DNS Delegation look, to >>>>>>> get the above forwarding example to work using delegation instead? >>>>>>> >>>>>>> Thanks in advance for your help! >>>>>>> >>>>>>> -- >>>>>>> Rob McEwen, invaluement >>>>>>> _______________________________________________ >>>>>>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >>>>>>> unsubscribe from this list >>>>>>> >>>>>>> ISC funds the development of this software with paid support >>>>>>> subscriptions. Contact us at https://www.isc.org/contact/ for more >>>>>>> information. > >>>>>>> >>>>>>> >>>>>>> bind-users mailing list >>>>>>> bind-users@lists.isc.org >>>>>>> https://lists.isc.org/mailman/listinfo/bind-users >>>>> -- >>>>> Rob McEwen >>>>> https://www.invaluement.com >>>>> +1 (478) 475-9032 >>> >>> -- >>> Rob McEwen >>> https://www.invaluement.com >>> +1 (478) 475-9032 > > > -- > Rob McEwen > https://www.invaluement.com > +1 (478) 475-9032 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
