Re: I am provoked by ISC for the 10 years statement that ISC refuse to fulfill (Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?)
On 2/11/24 02:07, Ole Aamot wrote: "This whole “we support everything for 10 years” is just a sales pitch, not a something that can be fulfilled." – Ondřej Surý — ISC I realize that there was a whole kerfuffle here that I mercifully missed and have absolutely no interest in. But it did "provoke" a question. Does anyone think not restarting *anything* for 10 years is a good idea? I realize there were all these fanbois back in the day that wanted to prove *NIX could stay up longer and with greater stability than Windows. But best practices would suggest that you patch and restart monthly at a minimum and more often for zero-days and more immediate threats. I would include among this the OS itself as well as key infrastructure services. Oh, and for the record, I think ISC does a very fine job ;) -- 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
Bind: Standard Ports And Non Standard Ports
After some months of poking around, we are now certain that our so-called "Business" service from Comcast is compromising our DNS servers because of their execrable "Security Edge" garbage. (They are willing to remove this 'service' only if we are willing to incur a higher monthly recurring fee.) Our master is in the wild and works fine, but the slave is behind the compromised Comcast pipe. The effect of having Security Edge in place is that the slave cannot get updates from the master and is also unable to resolve anything outside our own zone. Comcast is apparently hijacking all port 53 requests and doing unspeakable things with them. Is there a way to have these servers work as usual, listening to resolution request on port 53, but have the slave update AND forward requests to the master over a non-standard port, so as to work around the Comcast madness? TIA, Tim P.S. My guess is that this so-call "security" service is no such thing, or at least its not the only thing. They are probably harvesting DNS lookups to sell as marketing data, or at least that would be my first guess. -- 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
Failing DNS Server Diagnostic Help Requested
Environment: Master/Slave with Split Horizon both on FreeBSD-STABLE Bind 9.16.24_1 Master out in a cloud server Slave on a physical server with a static IP on Comcast Business Problem: After years of stable behavior, Slave intermittently not resolving addresses a few months ago, and then completely stopped working yesterday. We also noticed that the Slave will not update its files upon notify from the Master. Action Taken: Replaced Slave with a clone of the Master instance. That new Master does properly resolve names inside our zone, whether the requestor is on our LAN our one of our trusted servers out on the internet that are allowed to see internal names. HOWEVER, that new master instance will not resolve names in zones other than ours. We're working around this by forwarding these failed lookups to our original master - that is working fine. So, we have two masters with the same configuration and tables, but one resolves outside names and one does not. We've tried disabling DNSSEC validation and opening up our firewalls and got nowhere. When the lookups outside our zone fail, we see this: 13-Jan-2022 14:28:09.702 resolver: notice: DNS format error from 192.203.230.10#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.702 lame-servers: info: FORMERR resolving './NS/IN': 192.203.230.10#53 13-Jan-2022 14:28:09.721 resolver: notice: DNS format error from 192.36.148.17#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.721 lame-servers: info: FORMERR resolving './NS/IN': 192.36.148.17#53 13-Jan-2022 14:28:09.741 resolver: notice: DNS format error from 193.0.14.129#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.741 lame-servers: info: FORMERR resolving './NS/IN': 193.0.14.129#53 13-Jan-2022 14:28:09.763 resolver: notice: DNS format error from 199.7.91.13#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.763 lame-servers: info: FORMERR resolving './NS/IN': 199.7.91.13#53 13-Jan-2022 14:28:09.781 resolver: notice: DNS format error from 202.12.27.33#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.781 lame-servers: info: FORMERR resolving './NS/IN': 202.12.27.33#53 13-Jan-2022 14:28:09.801 resolver: notice: DNS format error from 199.7.83.42#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.801 lame-servers: info: FORMERR resolving './NS/IN': 199.7.83.42#53 13-Jan-2022 14:28:09.820 resolver: notice: DNS format error from 192.58.128.30#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.820 lame-servers: info: FORMERR resolving './NS/IN': 192.58.128.30#53 13-Jan-2022 14:28:09.837 resolver: notice: DNS format error from 198.41.0.4#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.837 lame-servers: info: FORMERR resolving './NS/IN': 198.41.0.4#53 13-Jan-2022 14:28:09.855 resolver: notice: DNS format error from 198.97.190.53#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.855 lame-servers: info: FORMERR resolving './NS/IN': 198.97.190.53#53 13-Jan-2022 14:28:09.875 resolver: notice: DNS format error from 192.5.5.241#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.875 lame-servers: info: FORMERR resolving './NS/IN': 192.5.5.241#53 13-Jan-2022 14:28:09.893 resolver: notice: DNS format error from 192.112.36.4#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.893 lame-servers: info: FORMERR resolving './NS/IN': 192.112.36.4#53 13-Jan-2022 14:28:09.921 resolver: notice: DNS format error from 199.9.14.201#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.921 lame-servers: info: FORMERR resolving './NS/IN': 199.9.14.201#53 13-Jan-2022 14:28:09.937 resolver: notice: DNS format error from 192.33.4.12#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.937 lame-servers: info: FORMERR resolving './NS/IN': 192.33.4.12#53 13-Jan-2022 14:28:09.938 resolver: info: resolver priming query complete So ... could this be Comcast munging about in the DNS traffic? Other suggestions of where to look appreciated as well ... (We have a fair bit of other logging data to be examined, I just didn't want to spam the whole list with all that ...) -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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
Re: Tracking Down Odd bind Behavior
On 8/15/21 9:07 AM, G.W. Haywood via bind-users wrote: > Hi there, > > On Sun, 15 Aug 2021, Tim Daneliuk wrote: > >> I have a bind slave instance running on FreeBSD 13-STABLE. Periodically >> (after >> a few days of perfect operation), it loses its ability to resolve at >> least some names - in this case, git.freebsd.org. ... >> ... >> Aug 14 17:07:03 ozzie named[32292]: running as: named -4 -u bind -c >> /usr/local/etc/namedb/named.conf >> ... > > Wild guess: try running without '-4'? > > Otherwise, see "Troubleshooting" in the ARM. Then, assuming that > you've set up the logging as per the ARM to be sufficiently verbose, > wait until the resolution failures start happening again and post > relevant extracts. > I did have extensive logging setup but only had info level recorded. I've since updated this to debug 3 per the ARM. Let's see what they provides. -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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
Tracking Down Odd bind Behavior
I have a bind slave instance running on FreeBSD 13-STABLE. Periodically (after a few days of perfect operation), it loses its ability to resolve at least some names - in this case, git.freebsd.org. When I look at the logs, I see this: ==> /var/log/named/query-errors <== 14-Aug-2021 16:48:33.376 query-errors: info: client @0x80949d560 127.0.0.1#30170 (git.freebsd.org): view internal: query failed (failure ) for git.freebsd.org/IN/ at query.c:7376 An rndc flush or complete restart of this slave instance fixes the problem. The installed version details follow. Helpful hints to fix would be welcome: Aug 14 17:07:03 ozzie named[32292]: starting BIND 9.16.19 (Stable Release) Aug 14 17:07:03 ozzie named[32292]: running on FreeBSD amd64 13.0-STABLE FreeBSD 13.0-STABLE #0 stable/13-n246370-74ff46ac172: Sun Jul 1 8 12:02:34 CDT 2021 t...@ozzie.tundraware.com:/usr1/obj/usr1/13-stable/amd64.amd64/sys/OZZIE Aug 14 17:07:03 ozzie named[32292]: built with '--disable-linux-caps' '--localstatedir=/var' '--sysconfdir=/usr/local/etc/namedb' '--wit h-dlopen=yes' '--with-libxml2' '--with-openssl=/usr' '--with-readline=-L/usr/local/lib -ledit' '--with-dlz-filesystem=yes' '--disable-dn stap' '--disable-fixed-rrset' '--disable-geoip' '--without-maxminddb' '--without-gssapi' '--with-libidn2=/usr/local' '--with-json-c' '-- disable-largefile' '--with-lmdb=/usr/local' '--disable-native-pkcs11' '--without-python' '--disable-querytrace' '--enable-tcp-fastopen' '--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd13 .0' 'build_alias=amd64-portbld-freebsd13.0' 'CC=cc' 'CFLAGS=-O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/inclu de -fno-strict-aliasing ' 'LDFLAGS= -L/usr/local/lib -ljson-c -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PL UG -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf' Aug 14 17:07:03 ozzie named[32292]: running as: named -4 -u bind -c /usr/local/etc/namedb/named.conf Aug 14 17:07:03 ozzie named[32292]: compiled by CLANG FreeBSD Clang 11.0.1 (g...@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff7 5f2c3fe) Aug 14 17:07:03 ozzie named[32292]: compiled with OpenSSL version: OpenSSL 1.1.1k-freebsd 25 Mar 2021 Aug 14 17:07:03 ozzie named[32292]: linked to OpenSSL version: OpenSSL 1.1.1k-freebsd 25 Mar 2021 Aug 14 17:07:03 ozzie named[32292]: compiled with libxml2 version: 2.9.12 Aug 14 17:07:03 ozzie named[32292]: linked to libxml2 version: 20912 Aug 14 17:07:03 ozzie named[32292]: compiled with json-c version: 0.15 Aug 14 17:07:03 ozzie named[32292]: linked to json-c version: 0.15 Aug 14 17:07:03 ozzie named[32292]: compiled with zlib version: 1.2.11 Aug 14 17:07:03 ozzie named[32292]: linked to zlib version: 1.2.11 Aug 14 17:07:03 ozzie named[32292]: Aug 14 17:07:03 ozzie named[32292]: BIND 9 is maintained by Internet Systems Consortium, Aug 14 17:07:03 ozzie named[32292]: Inc. (ISC), a non-profit 501(c)(3) public-benefit Aug 14 17:07:03 ozzie named[32292]: corporation. Support and training for BIND 9 are Aug 14 17:07:03 ozzie named[32292]: available at https://www.isc.org/support Aug 14 17:07:03 ozzie named[32292]: Aug 14 17:07:03 ozzie named[32292]: command channel listening on 127.0.0.1#953 Aug 14 17:07:03 ozzie named[32292]: 14-Aug-2021 17:07:03.167 general: notice: all zones loaded Aug 14 17:07:03 ozzie named[32292]: 14-Aug-2021 17:07:03.167 general: notice: running TIA, Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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: Debug Approach Help?
On 8/11/21 12:49 PM, Richard T.A. Neal wrote: > There's a very good article on the ISC website which discusses BIND logging: > https://kb.isc.org/docs/aa-01526 > > I recommend reading and implementing the logging as per their suggestion > (backup or make a note of your current logging configuration options in case > you want to revert in future) and then start looking through those logs the > next time your on-prem slave stops resolving. > > Once you spot any errors in the look you can post them here on the list and > others will try and help explain what may be happening. > > Richard. Perfect, will do, and thanks... -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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: AW: Deprecating auto-dnssec and inline-signing in 9.18+
On 8/10/21 11:27 PM, raf via bind-users wrote: > Does that help at all? Very much thank you. I have now discovered my DNS key and corresponding DS record. I believe the DS record is what I have to provide my registrar as I understand it. -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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
Debug Approach Help?
I am running bind 9.16.19 on two FreeBSD 13-STABLE instances. The master is on a Digital Ocean droplet and works fine. The slave is hosted on physical machine here in our offices. This has always worked flawlessly until recently. Periodically, the slave refuses to resolve names like 'git.freebsd.org' and we have to restart bind on the slave to get it working correctly again. Rather than using cron to restart bind every hour (!), we'd like to get to the root of the problem. The slave machine is at the end of a Comcast Business pipe and their execrable security edge garbage may be implicated. We could use some help on an approach to debugging this. Having never had significant bind problems over 20 years of use, we literally have no named debugging experience... TIA, -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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: AW: Deprecating auto-dnssec and inline-signing in 9.18+
On 8/10/21 7:32 PM, raf via bind-users wrote: > To get the DS record information to convey to the > registrar, after starting to use the default policy. > look for the CDS record (the child version of the DS > record) with dig: > > dig CDS EXAMPLE.ORG > > For the default policy, you'll only have to do this > once (or until your server gets compromised and you > start again). But until you've done this, it's not > done. The trust chain has to go all the way to the > root, so you need the involvement of your registrar > (to get your DS published and signed). That's quite helpful, thanks, but still unclear about one thing. When I run the dig command above I do get a result back with a "COOKIE" value in the response. This value changes each time I run the dig. Is any one of these the "DS record" I want to convey to my registrar? Other than this I see nothing that resembles a relevant response AND the COOKIE field does not show up if I do the dig from outside the zone. -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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: AW: Deprecating auto-dnssec and inline-signing in 9.18+
On 8/10/21 10:07 AM, Matthijs Mekking wrote: >> So just to be sure I'm doing the right thing, I've added this to my >> options stanza: >> >> dnssec-policy "default"; >> >> Then restarted named and now all the signing magic is taken care of for >> me for all zones? (I was not previously using signing.) > > Correct. > > But you still need to manually submit the DS record to your registrar/parent > and if you see the DS published run: > > rndc dnssec -checkds published . I've never done any of the signing work before (other than for master/slave). Could you kindly point me to something like "DS Record Creation And Implementation For Dummies"? Thanks, Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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: AW: Deprecating auto-dnssec and inline-signing in 9.18+
On 8/10/21 7:51 AM, Matthijs Mekking wrote: > Hi Klaus, > > On 10-08-2021 13:38, Klaus Darilion wrote: >> Hi Matthijs! >> >>> We would like to encourage you to change your configurations to >>> 'dnssec-policy'. See this KB article for migration help: >>> >>> https://kb.isc.org/docs/dnssec-key-and-signing-policy >> >> Some comments to this KB article and dnssec-policy: >> >> - The article should mention how to retrieve the DS record from >> Bind. So just to be sure I'm doing the right thing, I've added this to my options stanza: dnssec-policy "default"; Then restarted named and now all the signing magic is taken care of for me for all zones? (I was not previously using signing.) TIA, -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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: Corrupted Slave Data?
On 5/20/21 8:43 AM, Anand Buddhdev wrote: > On 20/05/2021 15:30, Tim Daneliuk via bind-users wrote: > > Hi Tim, > >> Recently - and for no obvious reason - the on-prem instance stops resolving >> properly. The fix is to stop it, clear out the slave files, and restart. >> Then it works for a few days and repeats its misbehavior. >> >> The logs show nothing remarkable, at least at first look. >> >> Is there a known slave file corruption problem? >> >> Could someone kindly suggest things we could look into otherwise? > > This is not a useful report at all. Your statement, "the on-prem > instance stops resolving properly", provides absolutely no useful > information about the failure. You haven't provided any configuration > details either. All you're saying is "I have a problem. Help!" We are > not mind-readers, and can't even begin to imagine what might be wrong. > > If you provide more details about your configuration, and about what > kind of failure you're observing (dig queries and responses, for > example), then perhaps some people might be able to assist you. > > Regards, > Anand Fair enough. Although I was just curious about known slave file corruption issue, for now. When this happens again, I will do digs and submit deets here. Thanks ___ 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
Corrupted Slave Data?
Running bind 9.16.15 on FreeBSD 11.4-STABLE. Master is out on a cloud server at Digital Ocean. Slave is on-premise. All on-prem LANs point to the slave instance. Running split horizon to keep nosey parkers out of our local DNS assignments. Recently - and for no obvious reason - the on-prem instance stops resolving properly. The fix is to stop it, clear out the slave files, and restart. Then it works for a few days and repeats its misbehavior. The logs show nothing remarkable, at least at first look. Is there a known slave file corruption problem? Could someone kindly suggest things we could look into otherwise? Many Thanks ... ___ 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: TXT & SPF Record Syntax
On 2/28/21 5:52 PM, Mark Andrews wrote: > Domain names without a trailing period are relative to the current origin. > > Domain names with a trailing period are absolute. > > If you want to add the record > > foo.bar.example.com. TXT … > > and the current origin is example.com. You can enter it as > > foo.bar TXT … > > or > > foo.bar.example.com. TXT … > > or you could set the origin to bar.example.com. and do this > > $ORIGIN bar.example.com. > foo TXT … > > This applies to all domain names in zone files. > > Mark OK that makes sense. Thanks. It's been so long since I configured these servers - and they have worked so flawlessly - I forgot everything I knew about bind config files ;) ___ 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
TXT & SPF Record Syntax
I am trying to understand when the LHS of a TXT record needs to be terminated with '.'. For example, I see this one of the machines I am managing. The server in question is the zone authority for foo.com: foo.com. IN TXT "v=spf1 ... foo.com. IN SPF "v=spf1 ... something._domainkey IN TXT "v=DKIM1 ... _dmark.foo.com. IN TXT "v=DMARC1 ... Could some kind soul explain why the DKIM key name does not require the trailing period, but why all the foo.com entries do? ___ 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
