Re: Observation: BIND 9.18 qname-minimization strict vs dig +trace
work.com ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6461 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1420 ; COOKIE: 64bf6532b614ec210100662be018a98c6134e8cea676 (good) ;; QUESTION SECTION: ;click-network.com. IN NS ;; ANSWER SECTION: click-network.com. 300 IN NS ns102. click-network.com. 300 IN NS ns102.click-network.com. click-network.com. 300 IN NS fs838.click-network.com. ;; ADDITIONAL SECTION: fs838.click-network.com. 172800 IN A 131.191.7.194 ns102.click-network.com. 172800 IN A 131.191.7.12 ;; Query time: 112 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Fri Apr 26 10:10:48 PDT 2024 ;; MSG SIZE rcvd: 165 # dig @127.0.0.1 ns102.click-network.com ; <<>> DiG 9.18.21 <<>> @127.0.0.1 ns102.click-network.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10463 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1420 ; COOKIE: b75215ce03b76bd30100662be03e0d2a5a9b6ab5e6d1 (good) ;; QUESTION SECTION: ;ns102.click-network.com. IN A ;; ANSWER SECTION: ns102.click-network.com. 300IN A 131.191.7.12 ;; AUTHORITY SECTION: click-network.com. 262 IN NS fs838.click-network.com. click-network.com. 262 IN NS ns102.click-network.com. click-network.com. 262 IN NS ns102. ;; ADDITIONAL SECTION: fs838.click-network.com. 172762 IN A 131.191.7.194 ;; Query time: 20 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Fri Apr 26 10:11:26 PDT 2024 ;; MSG SIZE rcvd: 165 # dig @ns102.click-network.com ns102.click-network.com +norecurse ; <<>> DiG 9.18.21 <<>> @ns102.click-network.com ns102.click-network.com +norecurse ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18892 ;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 4208cbc13560fc4325c45599662be069b466b23a5890f8d2 (good) ;; QUESTION SECTION: ;ns102.click-network.com. IN A ;; ANSWER SECTION: ns102.click-network.com. 300IN A 131.191.7.12 ;; AUTHORITY SECTION: click-network.com. 300 IN NS ns102. click-network.com. 300 IN NS ns102.click-network.com. click-network.com. 300 IN NS fs838.click-network.com. ;; ADDITIONAL SECTION: fs838.click-network.com. 300IN A 131.191.7.194 ;; Query time: 24 msec ;; SERVER: 131.191.7.12#53(ns102.click-network.com) (UDP) ;; WHEN: Fri Apr 26 10:12:09 PDT 2024 ;; MSG SIZE rcvd: 165 I don't know what broader implications might accrue. Since Rainier Connect / Lightcurve hasn't seen fit to fix it or get back to me in nearly a full business week I suspect they like it this way. However it doesn't comport with the principle of least surprise. The City of Tacoma doesn't seem to care that the licensee operating in a portion of their /16 is impersonating them (although as a consequence of the reputation service they use they won't accept emails from the block inquiring about it). -- Fred Morris -- 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
Re: Observation: BIND 9.18 qname-minimization strict vs dig +trace
They've got a number of problems. click-network.com is one of them. https://dnsviz.net/d/click-network.com/dnssec/ There is some backstory. The City of Tacoma used to run broadband, and that was Click! Network. The origin story is that this had something to do with SCADA or power distribution, but who knows? They have a /16, and it appears half of it is available to broadband customers. Anyway they privatized it and subsequently sole-sourced that. Like many businesses today, IT appears to be outsourced and the suppliers for various services do strange things sometimes. Here's the verbose log that 9.18.21 spits out in conjunction with the SERVFAIL: 24-Apr-2024 08:43:35.587 resolver: notice: DNS format error from 131.191.7.194#53 resolving 85.191.131.in-addr.arpa/NS for : Name 191.131.in-addr.arpa (SOA) not subdomain of zone 85.191.131.in-addr.arpa -- invalid response 24-Apr-2024 08:43:35.587 lame-servers: info: FORMERR resolving '85.191.131.in-addr.arpa/NS/IN': 131.191.7.194#53 24-Apr-2024 08:43:35.603 resolver: notice: DNS format error from 131.191.7.12#53 resolving 85.191.131.in-addr.arpa/NS for : Name 191.131.in-addr.arpa (SOA) not subdomain of zone 85.191.131.in-addr.arpa -- invalid response 24-Apr-2024 08:43:35.603 lame-servers: info: FORMERR resolving '85.191.131.in-addr.arpa/NS/IN': 131.191.7.12#53 I'm not saying it's the wrong thing to do, although to borrow someone else's line that may be like arguing over the particular weasels chosen rather than the decision to stuff rabid weasels down your pants in the first place. -- Fred Morris On Wed, 24 Apr 2024, tale wrote: Hmm, I wonder if qname-minimisation is at issue here. -- 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
Observation: BIND 9.18 qname-minimization strict vs dig +trace
While BIND 9.18.21 with "qname-minimization strict;" SERVFAILs on the following query, dig with +trace resolves it. Just a data point, and if they fix their s**t and stop impersonating a signed zone then presumably the example will resolve itself (pun intended). dig -x 131.191.85.31 dig -x 131.191.85.31 +trace -- Fred Morris -- 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
Solved Re: Caching ANSWER:0
So the answer is in two parts. 1) An SOA record is required in the AUTHORITY section. The TTL on the negative answer is established by the TTL on this record. 2) "TTL on this record" means the literal TTL applied to the SOA record, not e.g. the minimum TTL specified within the SOA record. -- Fred Morris On Fri, 5 Apr 2024, Fred Morris wrote: When people think of "negative response caching" I suspect they're thinking of NXDOMAIN, but there is another negative response: ANSWER:0. To some extent this is indistiguishable from a referral, and I'm not sure that caching of (upward) referrals is a sensible concept on its own. Testing with BIND 9.12 and 9.18 suggests that ANSWER:0 is not cached at all, and that each recursive request received results in a query from the caching resolver to the authoritatives (the authoritative is not running BIND). I'd appreciate a pointer to an RFC which specifically discusses this. I'd also appreciate (from someone who's read the code) a statement of what the intended semantics are, before I go read the code myself. Presuming that the ANSWER:0 response is authoritative, is there any expectation regarding content in the ADDITIONAL or AUTHORITATIVE sections which affects this behavior? NS? SOA? Thanks in advance... -- Fred Morris -- 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
Caching ANSWER:0
When people think of "negative response caching" I suspect they're thinking of NXDOMAIN, but there is another negative response: ANSWER:0. To some extent this is indistiguishable from a referral, and I'm not sure that caching of (upward) referrals is a sensible concept on its own. Testing with BIND 9.12 and 9.18 suggests that ANSWER:0 is not cached at all, and that each recursive request received results in a query from the caching resolver to the authoritatives (the authoritative is not running BIND). I'd appreciate a pointer to an RFC which specifically discusses this. I'd also appreciate (from someone who's read the code) a statement of what the intended semantics are, before I go read the code myself. Presuming that the ANSWER:0 response is authoritative, is there any expectation regarding content in the ADDITIONAL or AUTHORITATIVE sections which affects this behavior? NS? SOA? Thanks in advance... -- Fred Morris -- 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
Re: Problem upgrading to 9.18 - important feature being removed
On Fri, 1 Mar 2024, Ondřej Surý wrote: I wanted to address this comment. We (the developers) don't remove the features out of convenience or because we have 'better idea'. It's a known problem with humans that the discipline to remove items is oftentimes lacking, and that humans will tend to solve problems or "improve" things by implementing additive rather than subtractive measures. It's enough of a mental schism to consider adding and removing items as equivalent to different processes IMO. A maintainable software can't look like Katamari[1]. With the former insight, this remark may look a little different than it otherwise would. ;-) Removing unused things is an honorable and admirable objective: keep up the good work. You come onto this mailing list and tell us about it, typically well in advance. I'm generally in favor of removing unused features; emphasis is of course on "unused". -- Fred Morris, internet plumber-- 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
ANN: Dnstap telemetry agent supports both unicast and multicast
I updated both ShoDoHFlo and Rear View RPZ (https://github.com/m3047) to consume UDP telemetry instead of connecting directly to the Dnstap unix socket for greater flexibility and to support many-to-one, one-to-many, and many-to-many. Without a doubt, the most-viewed sourcefile in all of the projects I have on GitHub is shodohflo/examples/dnstap2json.py (https://github.com/m3047/shodohflo/blob/master/examples/dnstap2json.py) so I bowed to the wisdom of the crowd and based the new Dnstap Agent (shodohflo/agents/) on it. This means that I updated it to support multicast, and it will get some love from here on out. If shodohflo/agents/dnstap_agent.py or dnstap2json.py itself don't suit your payload needs, you are of course welcome to subclass dnstap2json.py yourself. I couldn't do it without BIND! Cheers... -- Fred Morris, internet plumber http://consulting.m3047.net/pfs-why/ -- 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
Re: secure statistics page
There used to be an example in a directory in the BIND tarball, in contrib/dnspriv/ Here's a link to it from 9.12.3: http://athena.m3047.net/pub/bind/dnspriv/ -- Fred Morris On Sun, 11 Feb 2024, Andrew Latham wrote: I have seen this question a few times so would a note or example in https://kb.isc.org/docs/aa-01123 (or other related documentation) be a good idea? On Thu, Jan 18, 2024 at 7:36 AM Ondřej Surý wrote: Hi, put a real webserver in front of it. Both Apache and Nginx can work as proxy. Ondrej I've activated Bind's statistics, to test I've set port 8080. So I can make http requests on port 8080, it works. but i'd like to secure the page, is it possible to switch to https and therefore use an SSL certificate? -- 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
Re: version errata Re: Remove PDF-related bits from the build system
You know, whenever I run over a spark plug as I'm driving down the road, the first thing that goes through my mind is good on them for ruling out the spark plug as the cause of rough running, and too bad they'll have to have the valves and rings checked. On 12/22/23 12:42 AM, Ondřej Surý wrote: > Are you really complaining about the lack of handholding because you > want to build the documentation yourself and just can’t download it? > Because it really seems like the case here. I concerned you've lost control of your build. However it does look correct in 9.19.19. -- Fred Morris -- 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
Re: version errata Re: Remove PDF-related bits from the build system
Just pulled the 9.18.21 tarball and checked, same thing. m3047@sophia:/opt/downloads/bind-9.18.21> grep -B18 '> Change log' README.md ### Documentation The *BIND 9 Administrator Reference Manual* (ARM) is included with the source distribution, and in .rst format, in the `doc/arm` directory. HTML and PDF versions are automatically generated and can be viewed at [https://bind9.readthedocs.io/en/latest/index.html](https://bind9.readthedocs.io/en/latest/index.html). Man pages for some of the programs in the BIND 9 distribution are also included in the BIND ARM. Frequently (and not-so-frequently) asked questions and their answers can be found in the ISC Knowledgebase at [https://kb.isc.org](https://kb.isc.org). Additional information on various subjects can be found in other `README` files throughout the source tree. ### Change log m3047@sophia:/opt/downloads/bind-9.18.21> sum README.md 37785 11 m3047@sophia:/opt/downloads/bind-9.18.21> md5sum README.md c4e08add5a135ce2573483eb0e5b1207 README.md m3047@sophia:/opt/downloads/bind-9.18.21> sha256sum README.md 080e914decc2ed554d8887b0f719b82736c45380b987f23b3eba4ef7418f03f3 README.md On 12/21/23 12:24 PM, Fred Morris wrote: > > No, I was correct the first time, but I had the wrong version. It is a > 9.18.9 tarball, not 9.18.21. Checksums are correct for that README.md. > > On 12/21/23 12:18 PM, Fred Morris wrote: >> >> I'm sorry 9.18.9 was the version where I discovered that the build >> didn't build the PDF, and all it says is >> >> ### Building BIND 9 >> >> For information about building BIND 9, see the >> ["Building BIND 9"](doc/arm/build.inc.rst) section in the BIND 9 >> Administrator Reference Manual. >> >> The checksums correct for that version of README.md. >> >> I think I must have mistakenly cut & pasted from the source tree in >> GitLab for 9.18. >> >> On 12/21/23 10:50 AM, Fred Morris wrote: >>> On 12/21/23 10:08 AM, Ondřej Surý wrote: >>> >>>> In the commit you referenced: >>>> >>>> https://gitlab.isc.org/isc-projects/bind9/-/commit/561a83a29182b00bda9237ae30343d76a68dcdf4#8ec9a00bfd09b3190ac6b22251dbb1aa95a0579d_147_147 >>>>> On 21. 12. 2023, at 18:59, Fred Morris wrote: >>>>> >>>>> According to the commit >>>>> (https://gitlab.isc.org/isc-projects/bind9/-/commit/561a83a29182b00bda9237ae30343d76a68dcdf4) >>> Not sure how this works, but I'm looking at what came out of the 9.18.21 >>> tarball and it doesn't build the PDF, and neither does README.md contain >>> the build instructions: >>> >>> ### Documentation >>> >>> The *BIND 9 Administrator Reference Manual* (ARM) is included with >>> the source >>> distribution, and in .rst format, in the `doc/arm` >>> directory. HTML and PDF versions are automatically generated and can >>> be viewed at >>> >>> [https://bind9.readthedocs.io/en/latest/index.html](https://bind9.readthedocs.io/en/latest/index.html). >>> >>> Man pages for some of the programs in the BIND 9 distribution >>> are also included in the BIND ARM. >>> >>> Frequently (and not-so-frequently) asked questions and their answers >>> can be found in the ISC Knowledgebase at >>> [https://kb.isc.org](https://kb.isc.org). >>> >>> Additional information on various subjects can be found in other >>> `README` files throughout the source tree. >>> >>> # sum README.md 30538 11 README.md # md5sum README.md >>> 4b7916a768467c54d1d1f0fd96cff505 README.md # sha256sum README.md >>> ed0a9280fe2f1d1fd6616f95184c6901709e79897b22205e5200bf1f5a7b1bea README.md >>> >>> -- >>> >>> Fred Morris >>> >>> >>> >>> **PerlJacket** deleted text/html part. >>> -- 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
Re: version errata Re: Remove PDF-related bits from the build system
No, I was correct the first time, but I had the wrong version. It is a 9.18.9 tarball, not 9.18.21. Checksums are correct for that README.md. On 12/21/23 12:18 PM, Fred Morris wrote: > > I'm sorry 9.18.9 was the version where I discovered that the build > didn't build the PDF, and all it says is > > ### Building BIND 9 > > For information about building BIND 9, see the > ["Building BIND 9"](doc/arm/build.inc.rst) section in the BIND 9 > Administrator Reference Manual. > > The checksums correct for that version of README.md. > > I think I must have mistakenly cut & pasted from the source tree in > GitLab for 9.18. > > On 12/21/23 10:50 AM, Fred Morris wrote: >> On 12/21/23 10:08 AM, Ondřej Surý wrote: >> >>> In the commit you referenced: >>> >>> https://gitlab.isc.org/isc-projects/bind9/-/commit/561a83a29182b00bda9237ae30343d76a68dcdf4#8ec9a00bfd09b3190ac6b22251dbb1aa95a0579d_147_147 >>>> On 21. 12. 2023, at 18:59, Fred Morris wrote: >>>> >>>> According to the commit >>>> (https://gitlab.isc.org/isc-projects/bind9/-/commit/561a83a29182b00bda9237ae30343d76a68dcdf4) >> Not sure how this works, but I'm looking at what came out of the 9.18.21 >> tarball and it doesn't build the PDF, and neither does README.md contain >> the build instructions: >> >> ### Documentation >> >> The *BIND 9 Administrator Reference Manual* (ARM) is included with >> the source >> distribution, and in .rst format, in the `doc/arm` >> directory. HTML and PDF versions are automatically generated and can >> be viewed at >> >> [https://bind9.readthedocs.io/en/latest/index.html](https://bind9.readthedocs.io/en/latest/index.html). >> >> Man pages for some of the programs in the BIND 9 distribution >> are also included in the BIND ARM. >> >> Frequently (and not-so-frequently) asked questions and their answers >> can be found in the ISC Knowledgebase at >> [https://kb.isc.org](https://kb.isc.org). >> >> Additional information on various subjects can be found in other >> `README` files throughout the source tree. >> >> # sum README.md 30538 11 README.md # md5sum README.md >> 4b7916a768467c54d1d1f0fd96cff505 README.md # sha256sum README.md >> ed0a9280fe2f1d1fd6616f95184c6901709e79897b22205e5200bf1f5a7b1bea README.md >> >> -- >> >> Fred Morris >> >> >> >> **PerlJacket** deleted text/html part. >> -- 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
version errata Re: Remove PDF-related bits from the build system
I'm sorry 9.18.9 was the version where I discovered that the build didn't build the PDF, and all it says is ### Building BIND 9 For information about building BIND 9, see the ["Building BIND 9"](doc/arm/build.inc.rst) section in the BIND 9 Administrator Reference Manual. The checksums correct for that version of README.md. I think I must have mistakenly cut & pasted from the source tree in GitLab for 9.18. On 12/21/23 10:50 AM, Fred Morris wrote: > On 12/21/23 10:08 AM, Ondřej Surý wrote: > >> In the commit you referenced: >> >> https://gitlab.isc.org/isc-projects/bind9/-/commit/561a83a29182b00bda9237ae30343d76a68dcdf4#8ec9a00bfd09b3190ac6b22251dbb1aa95a0579d_147_147 >>> On 21. 12. 2023, at 18:59, Fred Morris wrote: >>> >>> According to the commit >>> (https://gitlab.isc.org/isc-projects/bind9/-/commit/561a83a29182b00bda9237ae30343d76a68dcdf4) > Not sure how this works, but I'm looking at what came out of the 9.18.21 > tarball and it doesn't build the PDF, and neither does README.md contain > the build instructions: > > ### Documentation > > The *BIND 9 Administrator Reference Manual* (ARM) is included with > the source > distribution, and in .rst format, in the `doc/arm` > directory. HTML and PDF versions are automatically generated and can > be viewed at > > [https://bind9.readthedocs.io/en/latest/index.html](https://bind9.readthedocs.io/en/latest/index.html). > > Man pages for some of the programs in the BIND 9 distribution > are also included in the BIND ARM. > > Frequently (and not-so-frequently) asked questions and their answers > can be found in the ISC Knowledgebase at > [https://kb.isc.org](https://kb.isc.org). > > Additional information on various subjects can be found in other > `README` files throughout the source tree. > > # sum README.md 30538 11 README.md # md5sum README.md > 4b7916a768467c54d1d1f0fd96cff505 README.md # sha256sum README.md > ed0a9280fe2f1d1fd6616f95184c6901709e79897b22205e5200bf1f5a7b1bea README.md > > -- > > Fred Morris > > > > **PerlJacket** deleted text/html part. > -- 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
Re: Remove PDF-related bits from the build system
On 12/21/23 10:08 AM, Ondřej Surý wrote: > In the commit you referenced: > > https://gitlab.isc.org/isc-projects/bind9/-/commit/561a83a29182b00bda9237ae30343d76a68dcdf4#8ec9a00bfd09b3190ac6b22251dbb1aa95a0579d_147_147 >> On 21. 12. 2023, at 18:59, Fred Morris wrote: >> >> According to the commit >> (https://gitlab.isc.org/isc-projects/bind9/-/commit/561a83a29182b00bda9237ae30343d76a68dcdf4) Not sure how this works, but I'm looking at what came out of the 9.18.21 tarball and it doesn't build the PDF, and neither does README.md contain the build instructions: ### Documentation The *BIND 9 Administrator Reference Manual* (ARM) is included with the source distribution, and in .rst format, in the `doc/arm` directory. HTML and PDF versions are automatically generated and can be viewed at [https://bind9.readthedocs.io/en/latest/index.html](https://bind9.readthedocs.io/en/latest/index.html). Man pages for some of the programs in the BIND 9 distribution are also included in the BIND ARM. Frequently (and not-so-frequently) asked questions and their answers can be found in the ISC Knowledgebase at [https://kb.isc.org](https://kb.isc.org). Additional information on various subjects can be found in other `README` files throughout the source tree. # sum README.md 30538 11 README.md # md5sum README.md 4b7916a768467c54d1d1f0fd96cff505 README.md # sha256sum README.md ed0a9280fe2f1d1fd6616f95184c6901709e79897b22205e5200bf1f5a7b1bea README.md -- Fred Morris -- 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
Re: Remove PDF-related bits from the build system
(Intentionally posting to the mailing list with that string since that was the commit message where it occurred. Hopefully this will improve findability.) So, yeah. I'll take your word for it that Read The Docs can generate PDFs. I'd appreciate your promise that it generated the version of the doc which is here: https://downloads.isc.org/isc/bind9/9.18.21/doc/arm/Bv9ARM.pdf We could talk about the difference in presentation between the HTML and PDF versions, but it's a matter of taste. Is this free, and where are the instructions? According to the commit (https://gitlab.isc.org/isc-projects/bind9/-/commit/561a83a29182b00bda9237ae30343d76a68dcdf4) you removed "PDF-related bits" from not just the build system, but from the documentation itself! You removed the instructions that are in the commit message itself! If your intention was to remove it from the build system, you went too far. I looked for this just the other day in the KB. At the least you should have a KB article. At least there's this post to the mailing list. -- Fred Morris -- 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
Re: Deprecation notice for BIND 9: "resolver-nonbackoff-tries", "resolver-retry-interval"
I welcome birds of a feather. Need to define / refine the problem statement first. On 12/7/23 12:30 AM, Petr Špaček wrote: > On 07. 12. 23 1:05, Fred Morris wrote: >> On Wed, 6 Dec 2023, Evan Hunt wrote: >> I say go ahead, if nothing else consider it a "scream test". But can >> you take a moment and tell us which stakeholder group(s) you think >> you're optimizing for, why, and how? > > On the technical level we optimize using real (anonymized!) traffic > provided to us by operators. Here's what we need: > https://kb.isc.org/docs/collecting-client-queries-for-dns-server-testing > > If you want us to optimize for your use-case let's talk how we can get > the data and replicate your setup! I run Dnstap (for $reasons), but I'd be able to run dnscap and from the look of that KB page you only want the queries. I'm not sure that really captures the qualitative issue(s). I plan to dig into this some more over the winter anyway, maybe I should turn the tables and ask if there are other systemic issues I should look at or for? I'm using DNS largely for purposes other than FQDN -> address mapping. The things I've written have gotten enough uptake that I'm past the "kook" stage and into the "conspiracy" stage, but although I get some feedback at this point it's all basically anecdotal I don't have a "movement" that I can ask for disciplined feedback. I've done a number of different things poking at the same elephant over the past few years, and what I consistently see is a focus on "a query and a response" and I'm not sure that that is adequate systems thinking for the issues at hand. There seem to be a number of them, and they all point to inadequate systems thinking. That happens. As a neighboring example, adding more packet buffering to routers and wifi hotspots should be an unambiguous Good Thing, right? Even a decade after finding out that it's not, there are still people and constituent groups which haven't gotten the memo. The key thing I'm going to set up and examine this winter is the impact of qname minimization. But there are enough of these maybe some sort of memo is in order. Maybe somebody else wants to work on it with me? So here are some things which I've noticed about DNS in the field and lack of systems thinking. The first two (frags and TC=1) are fairly well known, and are provided as known examples where systems thinking is weak and what this means. But most importantly: "systems thinking in the DNS is provably weak". Frags. Frags are good? No they are bad. If a single UDP frag isn't delivered, the packet can't be reassembled. The server thinks all is fine and good and Procrustes' algorithm has made it all fit. The packet failing to be reassembled means that at the application layer no reply was received from the server. It really doesn't matter whether TC=1 is set or not, because it will never make it to the application. If traffic shaping mistakenly and simplistically thinks "dropping UDP is ok" it is double good for UDP frags. TC=1 is permission-based; (different implication) what if it only works over TCP? There is no provision in the algorithm to try TCP if no response is received via UDP. The 1980s recursion algorithm makes the decision to use TCP a polite society thing. The querant doesn't just try it. It waits for the server to say "here you are, this is what I can do for you; but I encourage you to please try again with TCP" and the querant thinks "oh how nice of you, what an excellent idea; thank you I will". There is no provision in the algo to unilaterally try TCP when UDP has failed to perform well or at all. This is arguably most important for stub resolvers. If the issue was simply buffer bloat, then forcing queries over TCP wouldn't provide observably better performance (which is often the case and why this is worth mentioning). The suspicion has to be traffic shaping, but I don't know that that's the case; crappy SOHO routers are largely black boxes. As an aside: are people still blocking TCP/53? Wasn't that long ago when this was conventional security theater. Aggressive UDP retry presumes fast over correct responses, or at least "correct enough" even if not the most timely. In pursuit of happy eyeballs, speed over everything else! The fastest thing is a static zone file which never changes. But the real world today encompasses forwarders as well as database backends (and this is for FQDN -> address mappings!) and in the quest for the fastest possible response caches get built on top of the database so that something can be served meeting the objectives of what is measured (response time). Without going into technical details, please accept that this increases complexity and the work needed to be done to keep what's served to the querant as fresh as practicable. On the other hand if a typical response time of 1/10
Re: Deprecation notice for BIND 9: "resolver-nonbackoff-tries", "resolver-retry-interval"
They don't seem well documented. Even in the ARM for 9.12 they're listed as options but no explanation is provided. It's easy to suspect that nobody is going to use an option which isn't documented (unless they're of a mind to browse sourcecode). This could be a self-fulfilling assumption. On Wed, 6 Dec 2023, Evan Hunt wrote: In line with ISC's deprecation policy, I am notifying the mailing list of our intent to deprecate the "resolver-nonbackoff-tries" and "resolver-retry-interval" options in named. [...] They are not thought to be useful in a production environment, and we know of no operators using them. (Please let us know if this is incorrect!) Exactly who is the "user", anyway? Am I to assume that "operator" is supposed to mean "somebody administering a naming service in conjunction with internet resources (addresses) to be located with said naming service? The default aggressive retry profile suggests that it's all about addresses and "happy eyeballs". However as an example email doesn't need that level of aggression, either for locating SMTP servers or for filtering done with such as SPF or DANE. And how about all of the PYLM TXT records (and all of those SPF includes)? The behavior of qname minimization in an environment with a lot of empty non-terminals strongly suggests that things are increasingly optimized towards namespaces which don't have a lot of them; and is there any problem domain addressed by the DNS where that is more the case than name to address mapping? (Counterexample: PTR records, now more than ever.) I say go ahead, if nothing else consider it a "scream test". But can you take a moment and tell us which stakeholder group(s) you think you're optimizing for, why, and how? Thanks... -- Fred Morris -- 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
Re: Help about DNS documentation
On Fri, 3 Nov 2023, Amaury Van Pevenaeyge wrote: * Would you have some articles and researches or others about DNS protocol, DNS protocol security or good research practices for DNS amplification attacks? The "go to" book on my bookshelf for IP generally is Comer's _Internetworking with TCP/IP, Volume 1_. -- Fred Morris -- 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
Re: Help about DNS documentation
Hello. Your interpretation of what is occurring may be interfering with your understanding of it. On Fri, 3 Nov 2023, Amaury Van Pevenaeyge wrote: [...] As part of my Master's thesis, I have to implement a DNS amplification scenario within a Cyber Range. However, before achieving this final goal, I first need to make amplification rate measurements within a virtual machine system. I therefore have a few questions about the DNS protocol and DNS servers. * Why do some DNS servers respond via TCP to an ANY query made under UDP? I have read in RFC8482 that modern DNS servers try to limit responses to ANY queries in order to limit the impact of their use in DNS amplification attack but I would like to learn more about the security measures/best practices currently in place for this type of query and for big TXT responses. Does anyone have any sources or other RFCs that might be useful? It is impossible for a DNS server to respond via TCP to a UDP query at a networking level. In general there are two kinds of amplification, number of packets (velocity) and size of packets (volume). It seems you understand that it is only possible to present a source address "on behalf of another" with UDP. This is incorrect. While TCP is a mitigation for blind trust in the source address of a packet, TCP SYN itself results in amplification (velocity) in the form of SYN/ACKs in the default tuning of most network stacks. When a DNS response via UDP is unable to be accommodated within the size (volume) constraints dictated by path MTU two things can happen: 1) the UDP response can be fragmented, resulting in multiple packets to be reassembled; or 2) the server can indicate to the client to retry over TCP (TC=1). TC=1 is also used as an at least partial mitigation for (spoofed) amplification traffic, as seen with response rate limiting. The typical resolver doesn't retry over TCP at all if it doesn't receive a (UDP) response with TC=1, for instance if it doesn't receive any response at all. So you have knobs in the zone data, the server, the networking stack and all of intermediating routers to twiddle. You can throw "buffer bloat" in there too. It's interesting that Dig automagically tries TCP first with ANY queries, since that is not the default behavior with e.g. A queries. -- Fred Morris, internet plumber -- 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
Re: consolidating in-addr.arpa data
You can't resolve differences in both directions automatically without inevitable conflicts, similar to merging code changes. That said, RPZ for fun and profit... On Fri, 15 Sep 2023, John Thurston wrote: A host which auto-registers in MS DNS, creates an A in foo.alaska.gov and PTR in whatever.10.in-addr.arpa. MS DNS is happy to publish those. But the DNS system running on BIND also has a whatever.10.in-addr.arpa zone. So if I want to find the PTR for 13.12.11.10.in-addr.arpa, I must query both DNS systems in turn. If I get NXDOMAIN from both, then I can say the PTR doesn't exist. On each system, I'd like to be able to take the 10.in-addr.arpa data from the other, compute the differences, and incorporate them locally. Then I'll be able to query either system, and accept an NXDOMAIN with confidence. Something in an RPZ will take precedence over what's in the delegated zone. RPZs are zones like any other zone and can be AXFR / IXFRed. The choice of MS DNS taking precendence might be the obvious choice, but the namespace in the RPZ won't be the same (e.g. 1.0.0.10.in-addr.arpa.rpz.example.com): it won't be "naked". So that won't work off the shelf (I know of no option to automagically rewrite the delegating zone). However, if you made BIND a secondary for the MS DNS PTR zone then it should serve it; and you could put BIND-specific edits in an RPZ. Then the BIND-specific values would take precedence over what's in the MS DNS zone, at least as seen when BIND is queried. Rear View RPZ (https://github.com/m3047/rear_view_rpz/) watches (BIND) Dnstap telemetry for A/ queries and uses it to update PTR records in an RPZ, as an example. -- Fred Morris -- 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
Dnstap Re: Deprecation notice for BIND 9.20+: Unix Domain Sockets for control channel (rndc)
No objections, however I hope somebody lets me know if the same thing is
contemplated for Dnstap and what the timeline is. I won't be unduly
lathered by such an occurrence but I'd rather not have fire drills (and
it's not just me it's people / projects downstream of me).
FTR, I've always used an IP address with RNDC.
On Tue, 12 Sep 2023, Ondřej Surý wrote:
[...] The support for Unix
Domain Sockets is already non-operational since BIND 9.18.0 and it is a fatal
error in named. This is properly documented in BIND 9.18.0 release notes and
known issues.
We are now proceeding to complete remove the rest of the code and documentation
from BIND 9.20+ (future release).
[...]
1. Using 'unix' option in 'controls {}' block in named.conf is already a fatal
error in named
The original issue is tracked under:
https://gitlab.isc.org/isc-projects/bind9/-/issues/1759
This wasn't particularly reassuring considering the Dnstap case. It
discusses something called "netmgr" which is used for "incoming DNS
queries and responses" and that now is apparently being adapted to a
control channel; it talks about modifying it to support outbound TCP
connections.
Dnstap has never been a server, it establishes an outbound connection to a
listener (server) on a unix socket. Seems like TCP has always been an
option for rndc, while it's never been an option for Dnstap; so that's a
difference, there's no explicit migration path at this moment.
Personally I'd be happy to see the last of framestreams (we don't need the
handshake, I've never used it and I've only ever seen it create confusion
for people trying to roll their own servers). I'd love to see UDP so that
we could get multicast (without a T/MG), but that doesn't allow for the
Dnstap overhead since DNS message sizes are already capped at the maximum
possible size of a UDP message.
Doing nothing is an option. ;-)
Thanks for all the work you do...
--
Fred Morris
--
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
Re: Is this KB example backwards? Re: Multiple master servers for the same zones
Hi Greg. So somebody referenced this KB article because presumably it was tangentially relevant, but I don't know that the OP is working with standby infrastructure (good question!). All they say is that after an upgrade all servers were masters. The amount of direct relevance of the article is questionable. Nonetheless, paragraph two seems factually incorrect on its face: changing type master; to type slave; does not swich a server from secondary to master, last I checked it did the opposite. On Thu, 7 Sep 2023, Greg Choules wrote: Hi Fred. No, the sense is correct. Imagine you have a server with a secondary zone of (say) "example.com", which transfers data for that zone from a primary somewhere. The KB article talks about multiple masters. At the outset there is no secondary. The secondary loads data received during a zone transfer straight into memory and uses it. It is optional for the secondary to also write that data to a file on its local storage, if you specify a "file" statement in the zone declaration. All examples (barring questions of relevance) of configuration syntax in the article specify a file statement. In one case it's implicit as in masterfile-format raw; and in the other it's quite explicit (but both of the examples are talking about standby primaries, which are not an explicit thing in the software although they are conceptually understood). Please re-read the second paragraph and try again. If the server currently being secondary for "example.com" does write that zone to disc then it is easy to switch it to become primary because it already has the zone file stored locally. Just change the "type", leave the "file" statement alone and delete (or comment) the "primaries". Agreed. Does that help? No. I have personally set up and administered a corosync / pacemaker cluster to do a standby to master promotion (for publishing RPZs with BIND) in a past life. Respectfully... -- Fred -- 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
Is this KB example backwards? Re: Multiple master servers for the same zones
Re-reading the KB article referenced below... On Tue, 5 Sep 2023, Leroy Tennison via bind-users wrote: [...] I'm assuming i can use https://kb.isc.org/docs/managing-manual-multi-master to "demote" one of them but is there anything to look for concerning possible inconsistencies and how do I check for those issues? Second paragraph: In BIND 9, it is relatively simple to switch a server from secondary to primary in real time: if you store the data in a file, simply redefine the zone type and change type master; to type slave;. That seems to me to be saying secondary == master and primary == slave. There seems to be a mixing of metaphors here. I don't think combining the traditional and newspeak terminology contributes to clarity. In any case I'd rewrite this as: In BIND 9, it is relatively simple to switch a server from primary to secondary in real time: if you store the data in a file, simply redefine the zone type and change type primary; to type secondary;. -- Fred Morris -- 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
Re: Multiple master servers for the same zones
On Tue, 5 Sep 2023, Leroy Tennison via bind-users wrote: After some recent upgrading it was discovered that both DNS servers were configured as master. I'm assuming i can use https://kb.isc.org/docs/managing-manual-multi-master to "demote" one of them but is there anything to look for concerning possible inconsistencies and how do I check for those issues? Before you do anything, back up both zone files! Merge and deconflict any differences. Set the "true" master to a higher serial number. Disable zone updates on the secondary. Pause for a scream test. Then "the usual" applies: set one of them to be a secondary and the master to allow zone transfers from it. Configure Notify if desired. Make sure it works, i.e. a zone transfer (AXFR / IXFR) occurs and the correct serial number is represented in the SOA. Pause for another scream test. -- Fred Morris -- 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
Re: Dynamic updates to multiple masters
You have more than one hypothetical problem there. On Wed, 2 Aug 2023, Shailendra Gautam wrote: I have four authoritative dns servers, all running in master mode for my zone for high availability, Can you give me the justification for why this was chosen and why it works in 100 words or less? I expect at least 50 words each for why it was chosen, and why it works. Am I bad with math? Isn't the DNS Way to secondary zones from a master to achieve this? I'm trying to implement dynamic updates but I am wondering if there is any way to avoid sending an update to each of them Good luck with that! Would like to know if anyone has faced this problem before. Don't do that if it hurts... but I'm a plumber not a doctor. You have multiple engineering problems here. You have eschewed the "DNS Solution" for zone management (zone transfers). Now you want to adopt the DNS Solution for updates (dynamic updates). I have engineered a solution which switched masters in the case of failover and it wasn't too bad, although it required restarting BIND to reload the config file so that nodes would know that one of them was the new master. There were dynamic updates, although ironically my recollection is that the change in config somehow addressed that (it's been a few years). As for the Dynamic Updates Generally problem, have you looked at idempotence as a paradigm? With this idea, updates are applied to converge with the "ideal image" that the updater holds; hopefully your updaters agree on that image, otherwise you have another problem related to conflict resolution (or in the parlance: distributed locking). It's a wonderful world isn't it? Anyway, the "way out" for us, even though the scenario was in someways different, was idempotence: the updaters would continue to attempt to update whatever the master was until it conformed to their ideal image, and their ideal image could change in consideration of what the zone held. -- Fred Morris, internet plumber -- 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
Re: Best way to handle multiple retries from BIND?
Well in this case... I'd be more interested in ways to tune BIND's internal resolver behavior. On Sun, 25 Jun 2023, Randy Bush wrote: If you have a true duplicate you only need to answer it once otherwise you have different clients and you need to answer all of them. Note there can be multiple clients on the same address. True, in the general case. Here, not so much. i gotta ask. so, for address foux, how do i know if there is one client or more than one? In this case DNS is a gateway sitting in front of a source of telemetry data on a private network, and I know it only has defined clients because I set it up that way. Anything that needs the data can ask those clients (e.g. BIND) and that's the point: to hand off caching and access control instead of reinventing the wheel. Nothing else running on the machine where BIND is running in this example has any need to access the data in the zone, whether directly or via BIND. -- Fred Morris -- 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
Best way to handle multiple retries from BIND?
I have an authoritative server which performs a resource intensive operation to determine an answer; sometimes it takes long enough that BIND asks again (and again!). Firing off multiple attempts to determine the answer just digs the hole deeper. What's the best approach, assuming the same client asks repeatedly: * Discard later queries, answer the first one? * Discard earlier queries, answer the last one? * Send same the response (when we get it) in response to all queries (I don't like this one)? And does anyone know can the recommended mitigation be presumed to be the best option regardless of the recursive server (BIND, Unbound, etc.)? Thanks in advance... -- Fred Morris -- 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
Re: replace "SERVFAIL" to "NXDOMAIN" with rpz
Admittedly, since I'm writing software to do "off label" stuff with DNS I make mistakes. But I have seen things along this line (interactions between RPZ and regular resolution in the context of "broken" domains): in some cases it has seemed impossible to ameliorate / mitigate SERVFAIL utilizing RPZ. I'll try to pay more attention and see if I can isolate a test case if the problem recurs. (I was kind of hoping someone would have a solution!) -- Fred Morris On Fri, 16 Jun 2023, Crist Clark wrote: That should return a NXDOMAIN. Returning SERVFAIL is never a normal RPZ action. Something is wrong with your configuration. On Fri, Jun 16, 2023 at 1:39 PM wrote: For monitoring reasons I try to change the return code of a domain name from "SERVFAIL" to "NXDOMAIN" with the rpz classic configuration of BIND9.16.42 as follows: example.com IN CNAME. *.example.com IN CNAME . But it still doesn't work, I still have the message " SERVFAIL", is it feasible or not 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
Re: Delegation NS-records when zones share an authority server
TLDR: NS records occur above and below zone cuts. On Wed, 12 Apr 2023, John Thurston wrote: We have authority over state.ak.us, which we publish as a public zone. We also publish challenge.state.ak.us as a public zone. The public NS records for state.ak.us are: ns4.state.ak.us and ns3.state.ak.us The NS records for challenge.state.ak.us are the same. I recently noticed there were no NS records _in the state.ak.us zone_ for challenge.state.ak.us. So nothing above the zone cut == there is no zone cut. (IMO) This had me scratching my head . . "how can this be working?", until I remembered the same instances of BIND were serving out both zones. There _were_ NS records in the challenge.state.ak.us zone, BIND had them, was authoritative, so would answer with them; BIND didn't need to look in the state.ak.us zone to find them. Yup. Some experimentation shows that even if I insert NS records into state.ak.us (for challenge.state.ak.us), BIND does not add them to its answer when asked "dig NS challenge.state.ak.us". I interpret this to mean that while this instance of BIND is authoritative for both zones, it answers with information from the most specific zone it has, and ignores values in the delegating zone. And that makes sense to me. Yup. Now the question is, should I insert NS records into state.ak.us (for challenge.state.ak.us) anyway? [...] Unknown: * Does the answer change if we want to start signing either zone? I suspect you don't need the NS records in challenge.state.ak.us and if you remove them then the records in challenge.state.ak.us are simply part of the state.ak.us zone since they're served off of the same server. Glue records (above the cut) are essentially the same NS record(s) published on nameservers above the zone cut as within the zone on the nameservers for the zone proper (below the cut). On the other hand maybe whatever software you're using to manage / serve DNS does something with those records (or requires them since / if the two namespaces are loaded as separate zones). In terms of NXDOMAIN and SOA queries, both state.ak.us and challenge.state.ak.us seem to do the right thing in terms of pretending to be separate zones, e.g. in the first case returning the correct domain in the AUTHORITY and in the second case returning the relevant SOA records directly in the ANSWER. -- Fred Morris, internet plumber -- 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
Re: Response Policy Zone returns servfail for time.in Trigger
Since one of the corner cases where RPZ is used is for mitigation of failures of legitimate resources, I have a question... On Sat, 8 Apr 2023, Ondřej Surý wrote: time.in is currently broken - I am guessing this is the reason why are you trying to rewrite the answers. RPZ does try to resolve the name first, and it fails, so there’s nothing to rewrite. Does this mean that in the default configuration an e.g. A record in an RPZ overriding brokenness in the global DNS with a QNAME override might fail due to the same brokenness? As far as I know I've never experienced that. Going forward, what is anticipated to be the proper configuration for that scenario? Thanks... -- Fred Morris -- 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
Re: BIND 9.16.30 - $INCLUDE file in the rpz zone file not reloading content and dig not working
Hello On Thu, 16 Mar 2023, Nagesh Thati wrote: [...] When named is restarted using systemctl above rpz rules are working fine, but when I add a new rule *nagesh3.com <http://nagesh3.com> A 3.4.5.6 * manually in the include file and run "rndc reconfig and rndc reload", named is not picking up the updated include file and *nagesh3.com <http://nagesh3.com>* rpz rule is not working. Are you incrementing the SOA serial number? -- Fred Morris, internet plumber -- 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
Re: Correlation between NOTIFY-Source and AXFR-Source
I've found myself in situations in the past where NOTIFY has been fetishized as "real time", and nobody ever ever asked which upstream server was being queried as a result. So this has been an eye-opening thread, and if I ever find myself in that situation again it'll give me something else to look at. -- Fred -- 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
Re: Incremental transfers generate complete zone reloading
On Sun, 15 Jan 2023, Jesus Cea wrote: I have a huge zone receiving a constant flow of small dns updates. My secondaries receive notifications and transfer the zone incrementally. Cool, everything works as expected. [...] Ok, my updates are coming too fast (first line). No problem, the secondary will eventually retrieve the changes. What worries me is the last couple of lines: The rpz zone (big, around 800.000 domains) is being reloaded constantly and it takes a couple of seconds eating CPU, when the incremental changes are actually pretty tiny. [...] not a full zone reload taking a couple of seconds and sucking an entire CPU core. Is that a fact or conjecture? There's a lot of "marketecture" in threat indicators generally. We can start with notifications versus polling. Secondaries can do either. Tell me why one is better, other than the vendor says so. Polling just does an SOA query, so two UDP packets; notify sends one. Is that extra packet more important than control? If this is a vendor and they're doing this why don't other customers see this as a problem? Is this just a "tax" for dealing with that vendor? What proof do you have that the CPU usage correlates, and that it's a problem? What are the vendor's recommendations (for provisioning and operational management), and are you following them? -- Fred Morris -- 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
Re: TIL: Restricting DiG to UDP only with +ignore
Hello Petr: On 12/5/22 4:35 AM, Petr Špaček wrote: > On 05. 12. 22 3:49, Fred Morris wrote: >> If the UDP query returns TC=1 DiG retries with TCP. I want to see the >> UDP results and am unable to. Specifying +notcp makes no difference. >> The correct option is +ignore: >> >> # dig @127.0.0.1 >> 'web_client\;*\;athena\;*.keys.redis.sophia.m3047' txt +notcp | tail >> [...] >> ;; SERVER: 127.0.0.1#53(127.0.0.1) (TCP) >> >> # dig @127.0.0.1 >> 'web_client\;*\;athena\;*.keys.redis.sophia.m3047' txt +ignore | tail >> [...] >> ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) >> >> The "tell" is that on the footer SERVER line it reports the protocol. >> Note that in the first case it's TCP, even though +notcp was >> specified. (The MSG SIZE is also a clue.) >> > If you have a specific proposal for docs we would be happy to improve > the dig man page. First off, the parenthetical reflecting the protocol would appear to be relatively new (that's DiG 9.18.9). It's not in 9.12. So props for that. (That's what reminded me of why I was reflexively firing up tcpdump during testing and made me go looking. Unfortunately it's a little bit late to choose a different mnemonic than "ignore". Most concepts are more readily accessible if they are part of a mythology or story. I don't have a good story for what is being ignored, doesn't seem to me that if I expect UDP and don't get it because TCP=1 that I'm in any manner trying to "ignore" it. I note that there is no +udp option.) Are you aware that if +tcp is specified along with +ignore, then +ignore is ignored? This behavior is not dependent on the ordering of the options on the command line. The behavior of these two options is demonstrably not orthogonal (not sure how it could be, although maybe it should have been). What is the expected behavior of DiG when conflicting directives are given? Regarding the manpage specifically, once someone realizes there is no such thing as +udp, they're likely to fixate on +tcp / +notcp. > +ignore, +noignore > This option ignores [or does not ignore] truncation in > UDP responses instead of retrying with TCP. By default, TCP > retries are performed. This is relatively straightforward. Doesn't say that +tcp invalidates it, but I'm not sure that would add clarity. I suppose what's being "ignored" here is TC=1. Might as well say so: "...ignores that the intent of TC=1 in the DNS protocol is to force retry over TCP, which is what DiG will do under normal circumstances.". You could add "Do not use with +tcp, this applies strictly to the (default) UDP query mode." but that sacrifices brevity. To me, talking about the intent makes context the DNS protocol rather than making this about DiG. > +tcp, +notcp > This option indicates whether to use TCP when querying > name servers. The default behavior is to use UDP unless a > type any or ixfr=N query is requested, in which case the > default is TCP. AXFR queries always use TCP. I think this needs to be expanded to indicate that if you don't want TCP, use +ignore rather than +notcp: "To prevent retry over TCP when TC=1 is returned from a UDP query, use +ignore." Actually dig -h fares better, with even more brevity: > +[no]ignore (Don't revert to TCP for TC > responses.) Apologies in advance if I've generated more heat than light... -- Fred -- 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
TIL: Restricting DiG to UDP only with +ignore
If the UDP query returns TC=1 DiG retries with TCP. I want to see the UDP results and am unable to. Specifying +notcp makes no difference. The correct option is +ignore: # dig @127.0.0.1 'web_client\;*\;athena\;*.keys.redis.sophia.m3047' txt +notcp | tail web_client\;*\;athena\;*.keys.redis.sophia.m3047. 30 IN TXT "web_client;194.55.186.216,404;athena;1670154435" web_client\;*\;athena\;*.keys.redis.sophia.m3047. 30 IN TXT "web_client;43.134.92.151,400;athena;1670132664" web_client\;*\;athena\;*.keys.redis.sophia.m3047. 30 IN TXT "web_client;35.162.155.28,200;athena;1670132664" web_client\;*\;athena\;*.keys.redis.sophia.m3047. 30 IN TXT "web_client;159.89.118.246,200;athena;1670132664" ;; Query time: 9 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (TCP) ;; WHEN: Sun Dec 04 18:42:19 PST 2022 ;; MSG SIZE rcvd: 7500 # dig @127.0.0.1 'web_client\;*\;athena\;*.keys.redis.sophia.m3047' txt +ignore | tail web_client\;*\;athena\;*.keys.redis.sophia.m3047. 30 IN TXT "web_client;80.94.92.40,200;athena;1670111034" web_client\;*\;athena\;*.keys.redis.sophia.m3047. 30 IN TXT "web_client;161.35.213.88,200;athena;1670154435" web_client\;*\;athena\;*.keys.redis.sophia.m3047. 30 IN TXT "web_client;103.10.62.92,404;athena;1670176114" web_client\;*\;athena\;*.keys.redis.sophia.m3047. 30 IN TXT "web_client;54.185.160.223,200;athena;1670154435" ;; Query time: 16 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Sun Dec 04 18:42:26 PST 2022 ;; MSG SIZE rcvd: 1193 The "tell" is that on the footer SERVER line it reports the protocol. Note that in the first case it's TCP, even though +notcp was specified. (The MSG SIZE is also a clue.) Searching the intertubes wasn't much help. When I tried to search the list archives I got a Gateway Timeout. :-( Anyway, it's been a minor personal annoyance for a while; hopefully this helps somebody else with a problem they didn't know they had. -- Fred Morris, internet plumber -- 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
Re: forwarder cache
Errata.. On Thu, 1 Dec 2022, Fred Morris wrote: "authoritative" zone served by an authoritative server configured to return complete 1024/1025 responses look like? 1034/1035 -- FWM -- 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
Re: forwarder cache
On Thu, 1 Dec 2022, Hamid Maadani wrote: [...] I can see "AUTHORITY: 0" in the answer, and now I understand NS1 does not cache this because of that (did not know only authority 1 answers are cached when I sent the initial email. Confusion of causes and effects: "AUTHORITY:0" is reportage regarding of an artifact of the message over the wire. There are no records in the AUTHORITY section, hence this reporting. [...] My question still stands: shouldn't NS2 answer with AUTHORITY: 1, regardless of DLZ or local-file backend, since the definition for the zone is as below? Have we gotten to 20 questions yet? Here's mine: Is what's in the "regardless of DLZ or local-file backend" properly constituted so that the desired information can be conveyed? Regarding the preamble to your standing question: you need to figure that out. If nothing else, RFCs should help. Comparing the meta contents of a working zone to this one: are they the same? By which I mean SOA, NS, dnssec... What does a query against that nameserver for NS records for the zone return? How does a nameserver know if it is authoritative if the copy of the zone it relies on (to differentiate from caching) does not list it as authoritative? (What is the definition of "authoritative"?) What is a server which is caching the result of querying it supposed to do when it sees that it is authoritative for that zone? Now, these are good questions, can't say I definitively know the answer; I have seen enough to know that people come up with notions. I strongly suggest starting with a configuration for which an analogous configuration works, and breaking it from there. What do the contents of an "authoritative" zone served by an authoritative server configured to return complete 1024/1025 responses look like? Is the server configured to return complete responses, and does it have properly constituted zone data to do so? I would expect a server so constituted to be able to answer the following questions when queried on port 53: * What is the SOA? * An NS response containing: * The FQDN of the server; * resolving to the address at which it was queried. You don't even have it queryable on port 53 from what I can tell. (You've got 2^24 IPv4 loopback addresses to work with, right?) Have fun arguing about whether or not a server which is "authoritative" should have an NS record in the zone, once you have something which demonstrably works. I don't have a lot of patience for "experts" who can't demonstrate a working system, so I probably won't be back. -- Fred Morris, internet plumber -- 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
copr.fedorainfracloud.org for Fedora 37
Hey there, that was me (a linguistic "sturdy indefensible"), trying to enable it so I could download the package for Fedora 37. Don't panic, I comiserate. Somebody made Fedora 37 (Python 3.11, actually) an Issue for another asyncio reliant project I support so I thought I'd get ahead of it and bring ShoDoHFlo up to spec. I'll compile from source. (Although it would be nice if somebody from Fedora could speak to support for Dnstap in the available BIND package...) -- Fred Morris, internet plumber -- 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
Re: automatic reverse and forwarding zones
"Garbage" records... On Mon, 7 Nov 2022, Matus UHLAR - fantomas wrote: On 07.11.22 15:42, Petr Špaček wrote: That's part of normal resolver operation: Garbage in - garbage out - garbage eventually cleaned out from cache. There is nothing special about PTR records in that regard. sooner or later, but filling up cache with garbage could result in other non-garbage records being flushed out. Are there any mechanisms that would wipe this garbage before other records, used more often even if not very recently? The only reason you get records in cache is because you requested them. From my vantage most PTR records are demonstrably garbage. Caching exists because if you requested it once you might request it again. Who knows, maybe you didn't believe it the first time. In any case, that's why the aphorism "garbage in garbage out" is a thing. -- Fred Morris -- 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
Re: Reverse lookups not working when Internet connection failed.
"Problems"... On Sun, 6 Nov 2022, Grant Taylor via bind-users wrote: On 11/6/22 6:39 AM, Matus UHLAR - fantomas wrote: alternatively they can choose to 0/28.66.136.193.in-addr.arpa. or 0-15.66.136.193.in-addr.arpa. instead of 0-28.66.136.193.in-addr.arpa. N.B. I've had some problems with the forward slash character "/" in domain names multiple times in the past. I'd stick with the hyphen "-" for compatibility. I've had problems with web browsers with "non-hostname" characters. I don't consider web browsers or their ilk the likely use case for resources under in-addr.arpa. There are some things I would avoid as a courtesy to others if I was so inclined: escape, completion and wildcard characters in shells and SQL implementations... -- Fred Morris -- 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
Re: Reverse lookups not working when Internet connection failed.
Don't kid yourself. This is wishing for a security outcome which will never reach fruition because of asymmetric interests and capabilities. On Sun, 6 Nov 2022, Grant Taylor via bind-users wrote: [...] I find that $CLIENTNAME or some other stand in for the client is a potential for information lek. The PUBLIC DNS is not secure against eavesdropping or parallel construction and never will be. Just like the destruction of whois (never was a good tool) doesn't prevent reconstruction of people's networks. People like me get paid a lot of money to see that this is so, and at least in some cases I remain convinced it's a good enough idea I don't care what people think about it. I even offer software to accomplish this for free on the internet; I even leverage features of e.g. BIND to do this. I can make arguments for being generic, or provider centric, or customer centric; I can also make arguments for outright lying. Hey, choose your own adventure; other people will judge you accordingly. -- Fred Morris, internet plumber -- 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
Re: Reverse lookups not working when Internet connection failed.
Hi. On Fri, 4 Nov 2022, Grant Taylor via bind-users wrote: 2) Leverage Response Policy Zone(s) to try to influence the lookup as others suggested. E.g. cause 1.66.136.193.in-addr.arpa. to become 1.0-28.66.136.193.in-addr.arpa. locally. -- I'd have to read about how to do this. [...] 1 IN PTR dns.di.ubi.pt. This. It's really like that but within the response policy zone. It depends on how your RPZ is scoped. If you just take over the world it looks like this: $ORIGIN . $TTL 600; 10 minutes REARVIEW.M3047.NET IN SOA DEV.NULL. M3047.M3047.NET. ( 2114499; serial 30 ; refresh (30 seconds) 15 ; retry (15 seconds) 86400 ; expire (1 day) 600; minimum (10 minutes) ) NS LOCALHOST. $ORIGIN 1.0.10.in-addr.arpa.rearview.m3047.net. 207 PTR fire3-10-inch.m3047. TXT "depth=1,first=1665768627.2416348,last=1667531692.5136201,count=264,trend=3935.662293321998,update=1 667540875.2942646,score=6.057739570203342" $ORIGIN 21.100.in-addr.arpa.rearview.m3047.net. 103.0 PTR arcus-uswest.amazon.com. TXT "depth=1,first=1665810308.1564665,last=1667535958.6280398,count=152,trend=11758.670145495724,update= 1667540875.2953703,score=5.3302068902418895" $ORIGIN 24.100.in-addr.arpa.rearview.m3047.net. 64.188 PTR s2s.aniview.com. TXT "depth=2,first=1667458140.2700894,last=1667507046.0667324,count=12,trend=3481.8259883810015,update=1 That is a BIND generated zonefile. Takeaways: * The zone is rearview.m3047.net. * The zone is being used as a response policy zone. * The rewrites are fully specified WITHIN THAT ZONE: 103.0.21.100.in-addr.arpa.rearview.m3047.net. PTR arcus-uswest.amazon.com. * Note the trailing terminal dot on both the LHS and RHS. # dig -x 100.21.0.103 ;; QUESTION SECTION: ;103.0.21.100.in-addr.arpa. IN PTR ;; ANSWER SECTION: 103.0.21.100.in-addr.arpa. 300 IN PTR ec2-100-21-0-103.us-west-2.compute.amazonaws.com. ;; AUTHORITY SECTION: 0.21.100.in-addr.arpa. 300 IN NS ns2-24-us-west-2.ec2-rdns.amazonaws.com. 0.21.100.in-addr.arpa. 300 IN NS ns4-24-us-west-2.ec2-rdns.amazonaws.com. 0.21.100.in-addr.arpa. 300 IN NS ns1-24-us-west-2.ec2-rdns.amazonaws.com. 0.21.100.in-addr.arpa. 300 IN NS ns3-24-us-west-2.ec2-rdns.amazonaws.com. ;; ADDITIONAL SECTION: ns1-24-us-west-2.ec2-rdns.amazonaws.com. 300 IN A 205.251.197.77 ns4-24-us-west-2.ec2-rdns.amazonaws.com. 300 IN A 205.251.194.254 ;; SERVER: 10.0.0.220#53(10.0.0.220) # dig @10.0.0.230 -x 100.21.0.103 ;; QUESTION SECTION: ;103.0.21.100.in-addr.arpa. IN PTR ;; ANSWER SECTION: 103.0.21.100.in-addr.arpa. 5IN PTR arcus-uswest.amazon.com. ;; AUTHORITY SECTION: REARVIEW.M3047.NET. 600 IN NS LOCALHOST. ;; ADDITIONAL SECTION: REARVIEW.M3047.NET. 1 IN SOA DEV.NULL. M3047.M3047.NET. 2114509 30 15 86400 600 ;; SERVER: 10.0.0.230#53(10.0.0.230) # dig @10.0.0.220 103.0.21.100.in-addr.arpa.rearview.m3047.net. PTR ;; QUESTION SECTION: ;103.0.21.100.in-addr.arpa.rearview.m3047.net. IN PTR ;; ANSWER SECTION: 103.0.21.100.in-addr.arpa.rearview.m3047.net. 600 IN PTR arcus-uswest.amazon.com. ;; AUTHORITY SECTION: REARVIEW.M3047.NET. 600 IN NS LOCALHOST. ;; SERVER: 10.0.0.220#53(10.0.0.220) # dig @10.0.0.220 103.0.21.100.in-addr.arpa.rearview.m3047.net. TXT ;; QUESTION SECTION: ;103.0.21.100.in-addr.arpa.rearview.m3047.net. IN TXT ;; ANSWER SECTION: 103.0.21.100.in-addr.arpa.rearview.m3047.net. 600 IN TXT "depth=1,first=1665810308.1564665,last=1667535958.6280398,count=152,trend=11758.670145495724,update=1667540875.2953703,score=5.3302068902418895" ;; AUTHORITY SECTION: REARVIEW.M3047.NET. 600 IN NS LOCALHOST. ;; SERVER: 10.0.0.220#53(10.0.0.220) -- Fred Morris, internet plumber -- 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
RE: Reverse lookups not working when Internet connection failed.
Ok. This is public address space. Delegation for reverse zones is separate from forward zones. Kind of depends on where the connectivity failure is, as to whether or not clients can walk the delegation tree (or need to). Then there's the effect of TTLs expiring. -- Fred Morris, internet plumber -- 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
Re: Reverse lookups not working when Internet connection failed.
Not enough information is provided about how your PTR zone is configured to allow anyone to provide a definitive answer. (Is this nonroutable space? Where are the machines located? Are they talking directly to the auth servers or are there recursives in the resolution path?) On Fri, 4 Nov 2022, David Carvalho via bind-users wrote: Reverse (PTR) Dns queries about my.domain from my.domain didn't work. Now that the internet connection is restored, everything is ok. Overall I'm unsurprised. You can put PTR records in a Response Policy Zone as a mitigation or for more advanced purposes. -- Fred Morris, internet plumber -- 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
Re: Question About Internal Recursive Resolvers
People do the funniest things with DNS. It's a pretty good key-value store, especially for read-heavy workloads. Maybe you update counters for "what clients in this OT environment are posting telemetry to this web server"? DNS wouldn't be a good choice for that, but Redis is. But maybe you want to query for the info with the DNS; as a bonus, DNS can offload / cache reads. On Sat, 15 Oct 2022, Grant Taylor via bind-users wrote: [...] How does hosting the zone on an internal server provide any additional security? Or are you simply relying on other security mechanisms to prevent non-secure clients -- as Bob described them -- from accessing the server ~> zone? I feel like, by default -- as Bob described, any hosted zone is going to be accessible by any client that can query the server. DNS is federated, meaning that a server can be both a service and a client, which means in the use case given above that the Redis instances can be distributed close to where the counters are updated; the DNS will go out and collect those counters when you query them, no need to send a constant stream of telemetry to a central location. You probably don't want those counters accessible to every dog on the internet. Some thought is necessary in deploying DNS servers so that intended clients get access. (We don't usually expect DNS clients to issue hundreds of requests per second either, but it works; you just need to give it some thought.) I assume that people have been doing variations on this sort of thing since PDPs were as common as LSD in Berkely. The usual suspects arrive: TSIG, allowed addresses, firewall rules; site-to-site VPNs; that sort of thing. Turns out RPZ is useful as a WAF equivalent, limiting the Redis keys which can be queried as well as the types of allowed queries. Here is my contribution to ensuring employment for DNS subject matter experts: * https://github.com/m3047/rkvdns -- DNS proxy for Redis * https://github.com/m3047/rkvdns_examples -- examples -- Fred Morris, internet plumber -- 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
Re: Seeing lots of DNS issues on OpenWRT
Why are you forwarding at all?
On Fri, 23 Sep 2022, Philip Prindeville wrote:
I've changed locations (moved houses) and consequently ISPs (now on
Sparklight, used to have CTC) and I'm seeing a slew of DNS issues I
didn't have before [...]
As you can see, a LOT of noise.
[...]
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
forwarders {
// Sparklight
// 24.116.0.53;
// 24.116.2.50;
9.9.9.9;
};
--
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
Re: BINd9 Server for Public Website
Nearly identical to what was posted to the unbound list. -- FWM6 On Fri, 23 Sep 2022, JAHANZAIB SYED wrote: I am trying to get some basic ideas on dns/hosting. [...] -- 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
Re: How filter with RPZ only A and AAAA type records ?
On Tue, 9 Aug 2022, sub zero wrote: Short question, is it possible to filter with BIND RPZ only A and type records? If yes, how? A similar question was asked recently on the DNS Firewalls list at Redbarn (http://lists.redbarn.org/pipermail/dnsfirewalls/) Short answer is no, or at least not that I know of. But maybe sort of. You can certainly return some RPZ generated answer (A record), but things like e.g. NXDOMAIN and passthru are done with CNAME and apply to the FQDN. I note that returning NXDOMAIN for an rtype and an answer for a different rtype for the FQDN is not conformant with how the DNS is supposed to behave (the conformant answer is success+ANSWER:0 not NXDOMAIN). Short questions don't always result in short answers. ;-) You might try the DNS Firewalls list, you might also see if you can come up with a scenario and functional tests; that might help people give a better answer. -- Fred Morris, internet plumber -- 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
Specifying EDNS payload size with dig queries
Self explanatory? Maybe it's the nomenclature but I can't spot this in the manpage; search engines haven't been much help. I might have to read code! :-o Thanks in advance, whoever you are; I owe you a beer. -- Fred Morris -- 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
Re: dnstap to Splunk
If you need something for POC / smoke: https://github.com/m3047/shodohflo/blob/master/examples/dnstap2json.py Assuming you can figure out how to get Splunk to consume log oriented json over UDP... -- Fred Morris, internet plumber -- 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
Re: Only one DS key comes back in query
You walk up to me, virtually on the internet, and say "I work for Barclays Bank" or "I'm a prince from Nigeria" my patience is a lot larger than my trust... Yes, example.com is a real thing. It's recommended for written examples in documentation. For some reason people think they can copy and paste from Stack Overflow and when real domains are utilized in examples it causes problems for those real domains. On Mon, 16 May 2022, frank picabia wrote: [...] Check other lists. Postfix. Apache. Whatever. No one ever has an issue when they see example.com It's widely known as the boilerplate value you're leaving out of the equation for the moment. Hopefully an unimportant "equation". I don't think there's a claim here that the problem can be reproduced with example.com, is there? I can't find it. That would be a very good use for example.com, indeed. What the OP has made clear is that they have a problem with their deployment, their domain. Anybody else piling on "me too"? I'm waiting; haven't seen it. I've gone a few rounds with Apache, but nevermind. Let's talk about postfix. Crikey, they can't even be bothered to get an LE cert for the website and catch flak at least monthly. Honey badger don't care. They're very clear about postconf output. If you pasted postconf output from the manual (or Stack Overflow) I think the response would literally be "you are, most def joking". But you be you Mr. Barclay. -- Fred Morris, internet plumber Not associated with either BIND or Postfix except I care. -- 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
Re: DNS traffic tracking
On Mon, 9 May 2022, Alex K wrote: [...] The problem now is that I see sometime 700MB of DNS traffic for 2GB of Internet browsing within one month. That's an eyebrow raiser. Tunneling, antivirus (or some other database using DNS as a key+value store), CDN? IoT fleet? Then comes the inevitable "...or traffic you don't want". Not clear on where the expensive link sits (between the caching resolver and clients, or between the caching resolver and the rest of the internet). Not sure what you're able to do politically or where things like privacy or "net neutrality" come into play, but it does seem to me that not burning precious bandwidth for ads might be a value-added service... if they're really watching cat videos. I second the comment that Dnstap might be your best friend. There are technical considerations, but I think generally this is veering into the realm of what's possible (which is seldom actually technical); this includes your means and ability to analyze the DNS traffic. If you want to discuss further feel free to email me. -- Fred Morris, internet plumber -- 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
Re: getting answers from DNS queries
More specificity would help. OTOH you mentioned the word "compile"...
On Mon, 25 Apr 2022, King, Harold Clyde (Hal) via bind-users wrote:
I asked this last week, but I didn't an answer. Who can I tell if a DNS
query is refused or answered? Is it in the log files?
Not the latest version of BIND (9.12), but here's what I get in the log:
25-Apr-2022 06:54:33.353 debug 2: fetch completed at resolver.c:4176 for
time.nist.gov/A in 10.000446: timed out/success
[domain:nist.gov,referral:0,restart:1,qrysent:4,timeout:0,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
25-Apr-2022 06:56:21.593 debug 2: fetch completed at resolver.c:4176 for
time.nist.gov/A in 10.000430: timed out/success
[domain:nist.gov,referral:0,restart:2,qrysent:10,timeout:0,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]
Here's the config for that:
// Must start named with -d 2 for this to be activated,
// otherwise it's just silent.
channel queryerrors {
file "bind-query-errors.log" versions 2 size 20m;
severity debug 2;
print-category no;
print-severity yes;
print-time yes;
};
I would expect the information you seek to be available via Dnstap.
--
Fred Morris, internet plumber
--
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
Re: Bind and systemd-resolved
There are a lot of extraneous details in here. This is not a BIND problem. On Mon, 18 Apr 2022, Leroy Tennison via bind-users wrote: When I attempt “dig -t AXFR office.example.com -k Kexample_dns.+157+18424.key” on the DNS server (Bind 9.11) sudoed to root I get: Why do you need to be root? ;; Couldn't verify signature: expected a TSIG or SIG(0); Transfer ;; failed. This is an Ubuntu 18.04 system and /etc/systemd/resolved.conf has DNS=127.0.0.1 since the DNS server is running on it. Systemd-resolved has been restarted afterward. I've tried using an actual interface address but it doesn't help. It seems dig tries to use 127.0.0.53 due to its being in /etc/resolv.conf and that fails even though dig for forward/reverse lookups works. I take it you believe you have things properly configured and are implying that you have 127.0.0.1 configured but that it isn't updating resolv.conf (which contains the entry 127.0.0.53). If I add @127.0.0.1 to the above it works. BIND is not broken. What happens when you try 127.0.0.53? Is there a way to get this to work without having to do that and not setting up the entire network configuration using systemd. I realize it's not a big effort to add @127.0.0.1 but the reason for the issue is obscure, the error message is misleading To be determined. and my distaste for systemd is sufficient enough that I would prefer avoiding it as much as possible. I hear you, but avoiding doesn't seem to be making it go away. systemd-resolved is a system service that provides network name resolution to local applications. It implements a caching and validating DNS/DNSSEC stub resolver, as well as an LLMNR and MulticastDNS resolver and responder. (And it listens on 127.0.0.53.) Maybe you should turn it off. -- Fred Morris, internet plumber-- 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
Re: Can an RPZ record be used for a non-existed domain?
On Thu, 24 Mar 2022, VASILAKIS GEORGIOS wrote: I have an RPZ containing 2700 Records using A record redirection. I've got an RPZ with thousands of PTR records! I don't know how many domains that means I took over, although some of them clearly don't exist because I get NXDOMAIN when trying to look up the legitimate records. Is it possible to add records for non-existing domains to the RPZ? I have another RPZ which I use for labeled uses. This results in local search lists being consulted, so I see things like foo.example.com.example.com, foo.example.com.com (and if they exist they shouldn't) and I block them (e.g. *.com.com) to prevent information leakage and garbage traffic. HTH... -- Fred Morris, internet plumber -- 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
Re: Obsoleting keep-response-order option in BIND 9.19/9.20+
It's not BIND's fault or responsibility, but I hope it is well documented and remains well documented. On Fri, 11 Feb 2022, Ondřej Surý wrote: [...] when out-of-order response processing was introduced in BIND 9.11.0, there was a “defensive” option added called keep-response-order that takes ACL as option to enable the previous behaviour where the DNS responses were sent in the same order as the received DNS queries. For BIND 9.19 (development) and 9.20 (stable) release scheduled in 2 years, we plan to make BIND 9 rely on DNS clients being compliant with RFC 7766[1]: 7. Response Reordering [...] For the avoidance of future doubt, this requirement is clarified. Authoritative servers and recursive resolvers are RECOMMENDED to support the preparing of responses in parallel and sending them out of order, regardless of the transport protocol in use. Stub and recursive resolvers MUST be able to process responses that arrive in a different order than that in which the requests were sent, regardless of the transport protocol in use. In order to achieve performance on par with UDP, recursive resolvers SHOULD process TCP queries in parallel and return individual responses as soon as they are available, possibly out of order. Since pipelined responses can arrive out of order, clients MUST match responses to outstanding queries on the same TCP connection using the Message ID. If the response contains a question section, the client MUST match the QNAME, QCLASS, and QTYPE fields. Failure by clients to properly match responses to outstanding queries can have serious consequences for interoperability. Let's face it, DNS is hard to do right. Having done several different things involving DNS over TCP these last few years this behavior has caught my attention, notwithstanding that I hadn't read 7766 for comprehension. Coding a client under these conditions, let me offer a few defensive strategies: * send the prepended length field with the message from the application layer (hopefully it ends up in the same packet) * don't expect the prepended length field to be prepended in the same packet as the reply * for that matter don't expect that a response which would fit in a UDP packet will arrive in a single read * when in doubt, connect + send a request + get a response + close * send a single request and wait for a single response (manage any queueing on your end) even if you plan to send multiple requests * if the response doesn't look right hang up and try again I strongly counsel against premature optimization. I hope those suggestions can also serve to inform server implementers / operators. (I think the RFC has a number of biases towards server implementers / operators, some plain, some more along the lines of moral hazard.) -- Fred Morris -- 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
Re: Best practice for forwarding Dnstap (unix socket) traffic to another address
I should have included this in the first message, and I apologize. What I'm looking at is trying to build a BIND kernel, like a nanokernel. Socat won't work in this case, because because there's no "IPC" layer, because there is only one process in the kernel. One process. No users. I need to get data out of it into the network layer. -- Fred ___ 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
Best practice for forwarding Dnstap (unix socket) traffic to another address
Hello. For a variety reasons: * Dnstap doesn't comport with the usual MTU restrictions, that is an "event" is not reliably going to fit in a UDP frame. * Dnstap casts your application as the "server" and BIND as the "client". * For whatever reasons the implementer(s) saw fit to include a mandatory handshake (all it does it say "ok, I'm sending X, what do you want?" and you have to respond with whatever the client sent). * The only streaming that Dnstap has offered has been unix sockets. What's the best practice for sending this to another address, presumably via TCP... socat? Too bad about the handshake, any best practices for forwarding there? Thanks in advance... (Pure Python implementation of fstrm: https://github.com/m3047/shodohflo/blob/master/shodohflo/fstrm.py) -- Fred Morris, internet plumber and data sous chef ___ 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
Re: what is wrong with DNS name 'covid19booster.healthservice.ie' ? : Google : what is Google's secret DNS service ?
Wow. 1) You're using BIND as a caching nameserver. So you say. Does the nameserver do its own upstream (authoritative) lookups? If yes, then the term of art is "recursive / caching"; otherwise the term is "forwarding". Looks like you're configuring your ISP's nameservers as forwarders. Therefore the proper term is "forwarding". 2) Your ISP's nameservers fail to resolve $FQDN. These are other people's caching nameservers. 3) Google's nameservers resolve $FQDN. These are other people's caching nameservers. 4) Looks like the nameservers for healthservice.ie belong to topsectechnology.net. 5) Looks like those nameservers resolve $FQDN. At least that's what dig +trace tells me. Can't you do the auth lookups directly? Have you tried? So your logic in coming here is that: a) $A's caching nameservers don't resolve $FQDN. b) $B's caching nameservers do resolve $FQDN. c) You use BIND to connect to one of those entities' caching nameservers instead of running your own. d) Therefore, the BIND mailing list is were I should direct my ire. Did I miss anything? Any response you get here is going to involve changing your BIND server's configuration and behavior, probably to convert it from forwarding to caching... although grizzled veterans may tell you horror stories about hotels and other public wifi. -- Fred Morris ___ 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
Re: Rear View RPZ: PTR records from local knowledge
I posted just such a thing a few weeks ago on the dnsrpz list at redbarn. Hrm, seems to be down at the moment. On 12/2/21 11:00 AM, Grant Taylor via bind-users wrote: > On 12/2/21 9:59 AM, Fred Morris wrote: >> Hello, Rear View RPZ (https://github.com/m3047/rear_view_rpz) is now >> generally available: turn your local BIND resolver into a network >> investigation enabler with locally generated PTR records. > > Would you please elaborate on what Rear View RPZ does? > > It seems as if it synthetically fabricates PTR records (which are > served via RPZ) with some additional information for subsequent use by > investigators. > > If that is correct, please provide an example of the original PTR and > the synthetic augmented PTR. \/ \/ \/ \/ \/ (ob ascii art!) Forwarded Message Subject:[DNSfirewalls] I've got smoke! Re: Using DnsTap to populate a reverse DNS RPZ Date: Mon, 15 Nov 2021 09:49:26 -0800 From: Fred Morris To: dnsfirewa...@lists.redbarn.org Hi. It's been a while. Anyway, I did this. It'll be going up on GitHub. I'll post another announcement here, and probably on dnstap and bind-users, when it's got training wheels. The way this works is a "sputnik" which consumes BIND's Dnstap telemetry and uses it to populate the RPZ using dynamic updates. -- FWM On 3/19/21 12:57 PM, Fred Morris wrote: > This is a tactical defender-centric tool, intended to augment everyday > tools' usability, e.g. "iptables -L -v". It's an RPZ, but it's not a > ban hammer. > > On Fri, 19 Mar 2021, Andrew Fried wrote: >> [...] >> You will often see generic 4-3-2-1.some.domain ptr records despite an >> actual host/domain points at the ip, particularly in cloud environments. > > Exactly the point! > -- m3047@sophia:~/GitHub/rear_view_rpz/python> dig @127.0.0.1 www.cnn.com ; <<>> DiG 9.12.3-P1 <<>> @127.0.0.1 www.cnn.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54804 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 04b5f7fa4c6aded4a8b6a4b3619299ce772407a3c447a114 (good) ;; QUESTION SECTION: ;www.cnn.com. IN A ;; ANSWER SECTION: www.cnn.COM. 297 IN CNAME turner-tls.map.fastly.net. turner-tls.map.fastly.net. 27 IN A 151.101.53.67 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Nov 15 09:33:02 PST 2021 ;; MSG SIZE rcvd: 134 m3047@sophia:~/GitHub/rear_view_rpz/python> dig @127.0.0.1 rearview.m3047.net axfr ; <<>> DiG 9.12.3-P1 <<>> @127.0.0.1 rearview.m3047.net axfr ; (1 server found) ;; global options: +cmd REARVIEW.M3047.NET. 600 IN SOA DEV.NULL. M3047.M3047.NET. 2 600 60 86400 600 REARVIEW.M3047.NET. 600 IN NS LOCALHOST. 67.53.101.151.in-addr.arpa.rearview.m3047.net. 600 IN TXT "depth=2,first=1636997584.330454,last=1636997584.330457,count=1,trend=0.0,score=0." 67.53.101.151.in-addr.arpa.rearview.m3047.net. 600 IN PTR www.cnn.com. REARVIEW.M3047.NET. 600 IN SOA DEV.NULL. M3047.M3047.NET. 2 600 60 86400 600 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Nov 15 09:33:10 PST 2021 ;; XFR size: 5 records (messages 1, bytes 382) m3047@sophia:~/GitHub/rear_view_rpz/python> dig @127.0.0.1 infoblox.com ; <<>> DiG 9.12.3-P1 <<>> @127.0.0.1 infoblox.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36850 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 666ea36e97a11479a198007e61929a416afc140bc683c5cc (good) ;; QUESTION SECTION: ;infoblox.com. IN A ;; ANSWER SECTION: infoblox.com. 3600 IN A 23.185.0.3 ;; Query time: 109 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Nov 15 09:34:57 PST 2021 ;; MSG SIZE rcvd: 85 m3047@sophia:~/GitHub/rear_view_rpz/python> dig @127.0.0.1 rearview.m3047.net axfr ; <<>> DiG 9.12.3-P1 <<>> @127.0.0.1 rearview.m3047.net axfr ; (1 server found) ;; global options: +cmd REARVIEW.M3047.NET. 600 IN SOA DEV.NULL. M3047.M3047.NET. 3 600 60 86400 600 REARVIEW.M3047.NET. 600 IN NS LOCALHOST. 67.53.101.151.in-addr.arpa.rearview.m3047.net. 600 IN TXT "depth=2,first=1636997584.330454,last=1636997584.330457,count=1,trend=0.0,score=0." 67.53.101.151.in-addr.arpa.rearview.m3047.net. 600 IN PTR www.cnn.com. 3.0.185.23.in-addr.arpa.rearview.m3047.net. 600 IN TXT "depth=1,first=1636997699.3390522,last=1636997699.3390543,count=1
Rear View RPZ: PTR records from local knowledge
Hello, Rear View RPZ (https://github.com/m3047/rear_view_rpz) is now generally available: turn your local BIND resolver into a network investigation enabler with locally generated PTR records. Ok, sure, some of you may be using it as a network investigation tool already. If so, you're probably well aware of the problems with PTR records for local visibility: * Whoever controls the address space, not the domain, controls the PTR record. * They don't necessarily get updated when domains get updated. * Network owners lie. * The records are just ignored. * Many FQDNs can point at an address (vhosting). * CNAMEs confound the intent of PTR records. What FQDN did /YOUR/ users look up which resolved to that address? Rear View RPZ can tell you. To have success with it in its present state: * You should be familiar with configuring BIND. * You should be capable of building it from source. * You should be capable of resolving prerequisites (e.g. frame streams, protobuf) when doing so. * You should be familiar with Python syntax. * You should understand a systemd service file. And I have one small favor to ask: if you know of a Linux distribution which ships BIND compiled with Dnstap support, please let me know! Cheers... -- Fred Morris This is being posted to the Dnstap, RPZ and BIND Users mailing lists. ___ 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
Re: Possible to condition a view based on the interface the query comes in on?
Thanks for the suggestions, folks. Using views with RPZs just gets problematic. Sharing vs forwarding: forwarding seems cleaner and although there are two copies of /BIND/ I don't know that that visibility really hurts anything. Plus that potentially allows the "rear view" resolver to live on a different machine. https://github.com/m3047/rear_view_rpz/blob/main/install/Optional_DNS_Service.md -- Fred Morris ___ 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
Re: Possible to condition a view based on the interface the query comes in on?
Thanks for the encouragement folks, I forged ahead and I've got a different error now: "response-policy zone 'rpz1.m3047.net' for view standard is not a master or slave zone" That's the final denoument. There are several intermediate steps, such as moving all zone definitions into the views and converting all zone references in the second view to "in-view standard;" (where "standard" is the name of the first view). * There are a total of three RPZs. * Two are utilized in the first view. (actually this is a lie) * All three are utilized in the second view. and the "lie" is that the "unused" RPZ is dynamically updated in the first view (that's where update requests are sent); I suppose I could jigger that so that the updates happen in the second view. But the stopper is that error message, and that RPZ is common to both views. This is 9.12 FWIW. -- Fred Morris ___ 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
Possible to condition a view based on the interface the query comes in on?
I wanted to provide enhanced recursive DNS to (internal) clients on an "opt in" basis, which is to say that clients could choose whether or not to receive enhanced replies based on what they configured as their local caching resolver. The enhanced services come in the form of a Response Policy Zone (RPZ). Didn't see any reason that it had to be separate instances of BIND, thought maybe I could do it with views, but I've run into a couple of roadblocks: 1. listen-on isn't supported in views. 2. internet wisdom augurs that response-policy isn't supported either. Is there a way to do this or should I bite the bullet and run two copies of BIND? Thanks in advance... -- Fred Morris ___ 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
Re: named service suddenly fails to start
Grant Taylor's reply is good, but you might also look at the check-names option. As he says, underscores are frowned on in hostnames but that's about it in theory if not in practice. You could also contemplate changing the logging destination and level... or not. -- Fred Morris On Thu, 4 Nov 2021, Bruce Johnson via bind-users wrote: This morning our server started failing to reload or start. checking the status reveals not a lot of info: systemctl status named-chroot ● named-chroot.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Thu 2021-11-04 11:55:17 MST; 27s ago Process: 2020 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -t /var/named/chroot -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exit> ___ 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
Re: force nameserver(bind) information exchanges with clients via tcp only
I should be clearer about this. The media devices send a lot of traffic. They manipulate the wifi landscape in proprietary (remember the TCP throughput wars 20+ years ago?) or at least unexpected ways. Stupid wifi access point follows "conventional wisdom" and drops UDP traffic. Doesn't bother the media devices, but 1980s stub resolver logic isn't up to competing with 100,000:1 packet contention and doesn't provide any way to do traffic shaping. -- Fred On Fri, 1 Oct 2021, Fred Morris wrote: On Thu, 30 Sep 2021, Carl Byington wrote: On Thu, 2021-09-30 at 16:30 -0700, Fred Morris wrote: https://github.com/m3047/tcp_only_forwarder So what exactly are the media devices doing to screw up dns resolution between the osx laptop and the local dns server? Dropping UDP replies. As a consequence, TCP is never tried. 1980s stub resolver logic. -- Fred ___ 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
Re: force nameserver(bind) information exchanges with clients via tcp only
Exactly! On Thu, 30 Sep 2021, Carl Byington wrote: On Thu, 2021-09-30 at 16:30 -0700, Fred Morris wrote: https://github.com/m3047/tcp_only_forwarder So what exactly are the media devices doing to screw up dns resolution between the osx laptop and the local dns server? Dropping UDP replies. As a consequence, TCP is never tried. 1980s stub resolver logic. -- Fred ___ 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
Re: force nameserver(bind) information exchanges with clients via tcp only
Hi there. Media devices and a crappy SOHO wifi AP? I know that feeling. ;-) On Thu, 30 Sep 2021, Donika Mirdita wrote: I have set up a nameserver and I would like to force all future client requests to TCP only. You can't really. You can try, by setting TC, but if the clients never see the (UDP) response, they'll never try TCP. (1980s logic) What you can do is force the clients to use TCP... or TLS. https://github.com/m3047/tcp_only_forwarder Good luck... -- Fred Morris ___ 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
Re: Minor change req for named.iner shirt
I suggest changing it to "953". Correction: 853. -- FWM ___ 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
Minor change req for named.iner shirt
So I was in public today, and somebody came up to me and asked about the shirt and we talked about it (properly masked, etc.). He asked "what does '555' stand for" and I can't say I'd taken particular notice of the amount showing on the cash register previously. I didn't have a clever story. I suggest changing it to "953". -- Fred Morris ___ 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
Re: REST API for recursive queries
You don't say /why/ you want to do this. This forwarder only does a single
request per TCP connection and also supports TLS:
https://github.com/m3047/tcp_only_forwarder/blob/master/forwarder.py
If you want to run DoT, I'm pretty sure that's on the BIND roadmap. The
BIND distro has provided instructions for setting up Nginx as an SSL
terminator in front of BIND in contrib/dnspriv/.
If you're trying to authenticate DNS queries/responses, you can also look
at using TSIG.
On Tue, 4 May 2021, Roee Mayerowicz wrote:
Do you know of a way to ask multiple DNS queries in a recursive bind
server at the same packet\request? Using DoH might work? How? Is there a
plugin which does that?
There is no way to send multiple requests in a single UDP datagram, but
you can send multiple requests in a TCP connection. There is only ever
supposed to be exactly one RR in the QUERY section.
--
Fred Morris
--
#!/usr/bin/python3
# Copyright (c) 2021 by Fred Morris Tacoma WA
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
"""Multiple requests in a single TCP stream.
There is no way to send multiple queries in a single UDP datagram.
Tweak the following to your needs:
* 10.0.0.220 => your server address
* sophia.m3047. => a query name
* flame.m3047. => another query name
Mind the trailing dot at the end of the FQDNs.
"""
import socket
import dns.message
SERVER = ('10.0.0.220', 53)
BIG_ENDIAN = { 'byteorder':'big', 'signed':False }
def main():
sock = socket.create_connection(SERVER)
req = dns.message.make_query('sophia.m3047.','A')
wire_req = req.to_wire()
sock.send(len(wire_req).to_bytes(2, **BIG_ENDIAN) + wire_req)
resp_length = sock.recv(2)
wire_resp = sock.recv(int.from_bytes(resp_length, **BIG_ENDIAN))
resp = dns.message.from_wire(wire_resp)
print(resp)
req = dns.message.make_query('flame.m3047.','A')
wire_req = req.to_wire()
sock.send(len(wire_req).to_bytes(2, **BIG_ENDIAN) + wire_req)
resp_length = sock.recv(2)
wire_resp = sock.recv(int.from_bytes(resp_length, **BIG_ENDIAN))
resp = dns.message.from_wire(wire_resp)
print(resp)
sock.close()
return
if __name__ == '__main__':
main()
___
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
Re: Authority and forwarding, but not recursion/iteration
Hammers and nails... On Tue, 16 Mar 2021, Marki wrote: On 3/13/2021 12:11 AM, Tony Finch wrote: Marki wrote: But if you need granular filtering, that could become a lot of views... Yes, I think RPZ is really designed to be a ban hammer [...] Standard DNS server software (not only Bind) Is RPZ "standard" now? I know that the US Govt is now calling it "PDNS"... does not provide for easy whitelist filtering, only blacklists seem to be "en vogue". Not true at all. There are large cesspools of compute which I block by default and selectively whitelist into with RPZ. This requires (and it should be SOP) two local RPZs, a whitelist followed by a blacklist. If it's in the whitelist it's shiny otherwise it gets filtered by the RPZ dedicated to replicating the coldest regions of interstellar space. The cesspools in particular are handled via CNAME chains. That seems to be SOP, too. So images.example.com is a CNAME to random.cesspool-example.com. In the second list there is a catchall for *.cesspool-example.com which rewrites it all NXDOMAIN. Because I like example.com, I put a rule in the first list to leave *.example.com alone. (This does a really good job with third party cookies before they even get to the browser.) In fact, this should be SOP: whenever you use cesspool compute or servers, CNAME it from your actual domain m'kay? Granted there are some people who cleverly use random.cesspool-example.com in their dynamically generated pages. So clever. Ooops, not so much. In fact, this blocks stuff I never even thought of blocking but am glad I did! There can also be issues with TTLs, where you had something in a compute cesspool blocked and then you created an exception for it, and it won't resolve until the TTL expires. I solve that locally by disabling local cache: all stub resolver queries (getaddrinfo() I'm looking at you!) get sent to the local recursive/caching resolver by disabling nscd or rewriting TTLs if necessary. For extra credit you can hunt nameservers, although that's perhaps better handled in the mail filtering pipeline, which is where it really seems to matter. -- Fred Morris ___ 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
Re: dnstap shows little logging at debug 10
Greetings. On Tue, 2 Mar 2021, Adam Augustine wrote: # ncat -l -U /var/opt/isc/scls/isc-bind/log/named/dnstap.sock I "chown named.named ./dnstap.sock" : But regardless I don't get anything from the pipe when using the normal "systemctl start isc-bind-named.service" followed by some "dig" commands to test (but see below). I was previously using fstrm_capture like this: [...] And I do suddenly get "protobuf:dnstap.Dnstap" on the pipe, but nothing further. So my root problem seems to be with how systemd is managing the process (maybe a user ID problem with the pipe). But my grepping the strace didn't catch anything opening the "dnstap.sock" pipe. The way they did framestream initialization it requires the "optional" handshake. I documented it (pydoc) here: https://github.com/m3047/shodohflo/blob/master/shodohflo/fstrm.py -- Fred Morris ___ 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
Re: Servfail on Bind -9.16.1
Check your clock. Have you got NTP turned on? Is it working? If it's not, flush cache/restart before you test again. -- Fred Morris ___ 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
Re: How can I launch a private Internet DNS server?
If this is question has a simple answer, you're confounding it by not asking a simple, concise question. On Thu, 15 Oct 2020, Jason Long via bind-users wrote: [...] I need expert advice about it. If you need expert advice that's accurate and guaranteed to work, hire a professional. ;-) I registered a domain name for my web site and in the panel of it, I can enter my DNS server IP addresses. I want to launch a CentOS DNS server that my Web site using it and users can visit my website from the Internet. [...] 1) The simple answer is that you don't need to run your own DNS server, you're done. Once you enter the address and server name correctly in your DNS registrar's control panel, that's how people will use the DNS to find the address of your that (web or whatever) server. 2) If you want to run your own DNS nameservers, you will need to buy a book, read the (BIND) Administrator's Reference Manual, and/or some RFCs to set them up properly. In terms of your registrar, you would enter the names of your DNS servers and addresses as A/ records, and set up NS records referencing the names of those DNS servers. So which is it: * Hi I'm Jason and I want to create a DNS record so that the world can find my web server. How do I do that? (answer #1) * Hi I'm Jason and I want to run my own nameservers for a bunch of irrelevant reasons such as CentOS, web servers and stuff. How do I do that? (answer #2) -- Fred Morris ___ 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
Re: rbldnsd and DNSSEC compatibility issues - any suggestions?
On Mon, 14 Sep 2020, Mark Andrews wrote:
[...] All
the queries to the recursive server with this configuration not answered by
the server will leak. The configuration needs “forward only;” to be added
to prevent the leak. We see this all the time.
zone “non-existant-tld” {
type forward;
forwarders { ; };
forward only;
};
Worth making note of! :-)
Remember forwarding started off as a performance measure. Falling back to
talking to the root servers is desired in that scenario.
--
Fred Morris___
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
Re: rbldnsd and DNSSEC compatibility issues - any suggestions?
I'm a little confused by the "sky is falling" tone of all this. I'm pretty sure that the browser fetish for "search and URLs in the same box!" is pretty high up on the root server pain scale; on any given day .belkin/.cisco can be one of the top 10 NXDOMAIN TLDs (at least as of a couple of years ago); search lists are another source of noise (which doesn't always make it to the roots). It's not just quantity, there is also leakage occurring. My recent brain fart regarding how to turn off the real queries in BIND when something (typically generated because of a search list) is caught by an RPZ is a case in point. (This particular use case is to catch noise from stuff which could be generated from search lists; it's a good use case IMO for RPZ to generate NXDOMAIN responses locally.) Or, look in your passive DNS for 127.0.53.53. I use DNS, the technology, as a distributed key/value store occasionally; there is no reason I should have to point it at a tree with ICANN's roots whatsoever, but for applications which need to be connected to ICANN's world that can be the past of least resistance. Seems to me that if some datacenter is doing beellions of DNS lookups to DNS as a K/V store some caching for hits as well as NX must be occurring, seems insane for that not to be the case. I'm trying to imagine scenarios where those beellions of queries would leak out to the root servers, or to any servers and none of them look sane to me (transport ain't free at scale). My biggest concern for the sane cases would be information leakage, such as the fingerprinting of machines via AV software doing hash lookups via The DNS; just an example. There are too many borked configurations to enumerate them all. The most plausible architecture I come up with, perhaps unsurprisingly the one I would suggest in the absence of explicit mitigating factors, would be a caching resolver running on the same switch, if not the same machine, as the application generating the queries. I might secondary the zone there. Or I might just set it up as a static-stub or forward. What are the possible failure modes in this scenario? The application is configured to use the wrong DNS server: this is not a simple failure, it has to be configured to use a resolver or nothing resolves; if it's an authoritative then queries for what's not in bailiwick there are (hopefully) refused or referred back to the stub resolver (which won't follow them because it's RD not recursing itself), all of them, not just ones from the K/V store and it's going to look really really broken; if it's 8.8.8.8 then surely gmrgle caches the NX response from the root for the bogus TLD; if it's the corporate caching resolver the same (plus I expect the phone to ring). The query generates a legitimate NX response from the zone: that should be the end of it (that's how DNSBLs work); if search list processing occurs, I'm wondering how one got configured but more than that how this solution made it into production (if I was writing the app, I'd probably eschew reliance on the operating system stub resolver for this particular use case entirely). The app is misconfigured not to use the correct domain (for the K/V domain): if it's the wrong domain (or none at all) it doesn't matter whether the "correct" domain is legitimate or locally concocted. Any others? I just don't see how beellions of queries are going to get directed at the roots or any auth server, regardless of what the TLD is, or if that occurs that the choice of TLD mitigates in any fashion whatsoever. There's always a way to make it happen, I just can't imagine it making it sanely into production even by accident. (This applies to DLV.ISC.ORG too, which returns an SOA, but they could make it NX if it suited their purposes.) Quizzically... -- Fred Morris On 9/10/20 10:57 PM, Rob McEwen 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). > [...] > > On 9/11/2020 1:32 AM, Mark Andrews wrote: >>> On 11 Sep 2020, at 15:04, Rob McEwen 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,
Re: Response Policy Zone: disabling "leaking" of lookups
Carl Byington wrote: > On Wed, 2020-09-02 at 17:47 -0700, Fred Morris wrote: > > how do I disable the (useless) resolution directed at upstream > > servers? > > Isn't that just "qname-wait-recurse no;" > You are correct! I got confused and the doc didn't help. The logic is tri-state: *Default* (not present): The lookup is performed, but isn't waited for. *Yes*: Resolution waits for the lookup to complete. *No*: Resolution is not performed. Verified by testing. :-) Thanks for the sanity check. -- Fred Morris ___ 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
Response Policy Zone: disabling "leaking" of lookups
It comes to my attention that when an unresolvable query occurs, it gets
forwarded to the authoritative zone regardless of anything I can set in
named.conf. Closest I can come is qname-wait-recurse which has the
/opposite/ effect sort of, namely waiting for recursion to complete. If
I have something in an RPZ, I want it to accept that; period, full stop,
no outwardly visible effects.
Ironically the text surrounding this option in the ARM is to the effect
that "... not resolving the requested name can leak the fact that
response policy rewriting is in use..." and leaking the fact that it is
in use by not leaking the query in the first place is what I'm trying to
achieve: how do I disable the (useless) resolution directed at upstream
servers?
Here is a use case:
1. A search list is in place for example.com. This means that if
"foo.bar" fails to resolve then "foo.bar.example.com" will be tried,
followed by "foo.bar.com".
2. In addition to the foregoing a rule is placed in the RPZ that
"com.example.com" and "*.com.example.com" are NXDOMAIN.
3. An additional rule is present in the RPZ that
"my-outhouse-example.com" is NXDOMAIN.
In this case:
* "my-outhouse-example.com.example.com" will return NXDOMAIN (it does!)
* There should be /no/ upstream (pointless) query for
my-outhouse-example.com.example.com. (oops!)
Let's stop the leaks.
--
Fred Morris
___
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
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
On Thu, 23 Jul 2020, charlie derr wrote: On 7/23/20 9:49 AM, Michael De Roover wrote: [...] For this to work at all though, they'd have to provide all packages simply as source code (why not use the distribution's own source repositories?) and compile it on the target. [...] While it would still *technically* be security by obscurity, it would seem to me that there's some value to this approach because access to the compiled binary wouldn't necessarily be easy to obtain (especially if the sysadmin provisioning the system takes extra efforts to *not* share it with anyone). Or am i missing something? They actually run a very large build farm in AWS, and they claim that all binaries are made just for you. Basically you change your distro's package repositories to theirs. Preventing people from examining the binaries in order to craft working memory exploits which work across a large installed base is exactly what they're aiming to prevent. Disclosure: I've heckled their CTO in a friendly fashion for making better idiots, but I paid for my own Old Fashioned. -- Fred Morris ___ 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
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
Perhaps slightly OT, but here's a company which has a whole business model based on one nonobvious (?) reason to compile from source: https://polyverse.com/ -- Fred Morris ___ 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
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
If you're running Alpine, you should know that it uses MUSL which has a stub resolver which is/was lacking in some respects: http://postfix.1071664.n5.nabble.com/Outgoing-DANE-not-working-tp105397p105420.html On Thu, 23 Jul 2020, Michael De Roover wrote: [...] With my internal BIND servers now running on Alpine (because super lightweight), that blurs the lines a bit. -- Fred Morris ___ 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
Another DoT client (python)
Hello, I've written a DoT forwarder to be run locally on for example a laptop in python: https://github.com/m3047/tcp_only_forwarder * python3 asyncio * standard modules only * no make, no binaries * one source file * 53 LOC (the irony!) I wrote this a few weeks ago as a DNS-over-Plain-TCP (DoPT) forwarder (see the README for why), but it was trivial to add TLS support. -- Fred Morris ___ 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
Re: Fwd: DNS Misconfiguration on- http://cyberia.net.sa/
Hrmmm... I'm reminded of something else I've seen reported on recently... On Fri, 5 Jun 2020, Ejaz Ahmed wrote: localhost.cyberia.net.sa I don't know if you've been paying attention, but it's been reported that among others EBay has been port scanning visitor's devices [0]. Having localhost.ebay.com could be handy for them in terms of circumventing some rules on setting of cookies and the execution of scripts. Not saying that's what they're doing, heaven forbid. Any domain you visit could have entries in it which point to e.g. localhost or nonrouting addresses commonly used for gateways, things like that. This is not a DNS problem, it's a problem in what commonly used programs aid and abet in the name of "freedom of commerce" or something. -- Fred Morris -- [0] https://www.bleepingcomputer.com/news/security/ebay-port-scans-visitors-computers-for-remote-access-programs/ ___ 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
Best way to force a TC=1 response?
What's the best way to force an A query via UDP to return a TC=1 result: a really long CNAME chain? I want to set up a name that can be used in e.g. ping to perform an end to end resolution check in application context. The longer version is that there was a thread on postfix-users not too long ago about the fact that MUSL libc doesn't do TCP (among other things) and I want a way to test some hardware and statically built apps. No jumbo frames here. I was also mildly surprised to discover that glibc doesn't try TCP if UDP fails to answer; for some reason I thought it did! Instead it reports "Temporary failure in name resolution" in the ping example. -- Fred Morris ___ 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
Re: How to get random subset of large rrset (30+ IPs for round robin)?
It's incredibly hacky, but what about setting different nameservers with different sets of addresses for the FQDN in question? -- Fred ___ 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: Fwd: Re: recursive resolver
To confirm, this is a local caching also-known-as recursive resolver. It
is quick (< 100 msec) when answering from cache, but not when it has to do
lookups itself (> 1000 msec).
On Thu, 12 Mar 2020, ShubhamGoyal wrote:
we made a recurive resolver (Cent OS 7, 8GB RAM ,250 GB Hard disk and network
speed is also good ) . It reply in 1200 msec and 1800 msec (which is very
slow). if it gave Reply by Cache (80 msec or 76 msec).
so i want to know about,
How can i improve my recursive resolver speed.
I can't give you a detailed troubleshooting guide, but I can give you some
general outline of the problem terrain.
The obvious conclusion (until disproved!) is that "DNS lookups to the rest
of the world are slow" but I wouldn't start there. I'd start with looking
at the BIND logs, because it's easy.
I'd start with setting up logging like the following:
// Must start named with -d 2 for this to be activated,
// otherwise it's just silent.
channel queryerrors {
file "bind-query-errors.log" versions 2 size 20m;
severity debug 2;
print-category no;
print-severity yes;
print-time yes;
};
and then I'd look in bind-query-errors.log for entries like this:
27-Jan-2019 11:00:54.185 debug 2: fetch completed at resolver.c:4176 for
addons.cdn.mozilla.net/A in 10.000425: timed out/success
[domain:mozilla.net,referral:0,restart:4,qrysent:13,timeout:12,lame:0,quota:0,neterr:0,badresp:0,adberr:0,find
fail:0,valfail:0]
Don't panic about a few errors, but if you're having problems, that's
where I'd look. ;-)
There are a number of different kinds of errors, this one is "timed out".
(Do you see timeouts or query fails at your caching server's clients (your
workstation / laptop))? Can you confirm or disprove the "obvious
conclusion" from data in the logs? Is some other issue apparent?
Moving back to the "obvious conclusion", your workstation makes a request
to your server with the "RD" (recursion desired) flag. Your server then
makes requests of its own without the "RD" flag. You should be able to see
these queries (and the responses) directed to nameservers on the internet
by dumping packets, and to pair them up and see how long they're taking.
You can even make your own with dig using the appropriate flags.
From here you have to explore whether it's a technical connectivity issue
(such as MTU or blocking of TCP etc.) or provisioning / bandwidth issue
(just too slow / too many hops to anywhere or some (particular) where).
After you've ruled out the obvious conclusion you have to start
considering scenarios such as someone intentionally interfering in path
with port 53 traffic.
--
Fred Morris
___
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: Peculiar DNS queries
Regarding entropy, that is correct. Regarding case, in any case (pardon
the pun) case is not guaranteed. Especially regarding dynamic updates,
your case will not be preserved (and maybe I fat-fingered and left caps
lock on once upon a time without realizing it) in the authoritative zone.
The mixed (within a label) case queries seem to be an artifact of entropy
preservation, but in cache e.g. isc.org matches ISC.ORG or isc.ORG, or
ISC.org... hopefully you get the idea.
I ran into a transient problem last summer with case sensitivity in SuSE
Leap, hasn't come back but my best guess is something to do with NSCD.
There is a tension between the protocol ("any octet") vs what you can
register ("valid hostnames") vs what's sent to the public DNS ("case
insensitive").
--
Fred Morris
___
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: Debugging Information Lacking?
Look in the BIND ARM for dump-file: dump-file The pathname of the file the server dumps the database to when instructed to do so with rndc dumpdb. If not specified, the default is named_dump.db. Regards... -- Fred Morris On Wed, 27 Nov 2019, isc-bind-us...@ics-il.net wrote: [...] I'm trying to see what BIND currently thinks all of the zones are, so I issue the "rndc dumpdb -zones" command. ___ 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
Pure Python Dnstap
All: Here is a pure python implementation of a Dnstap consumer designed to work with Python 3: https://github.com/m3047/shodohflo Implementations of Frame Streams and Protobuf: https://github.com/m3047/shodohflo/tree/master/shodohflo While the implementations of Frame Streams and Protobuf on their own have no dependencies outside of the standard libraries, shodohflo.protobuf.dnstap does have a dependency on dnspython. Sample application: https://github.com/m3047/shodohflo/blob/master/examples/tap_example.py The sample program has no dependencies beyond those required by the modules above (dnspython). If the output of the sample program and the protobuf implementation itself look a bit Scapy-like, that's because I originally implemented it as a Scapy dissector several years ago. Unlike Scapy, this software is released under an Apache license. -- Fred Morris ___ 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
