Re: 9.18 behavior change for mDNS queries with dig
Neither wireshark or nor tcpdump (AFAIK) can return the data in a form suitable for use in a shell script (my need was (emphasis on “was”, I’ve already re-worked my configuration to no longer need the lookup) get the current address of example.local and then use it in the shell script). In any event, the bug report was submitted and the response was that dig was never intended to be used for mDNS queries and that it did until 9.18 was just luck. Changes made in 9.18 make it no longer work but since that was never a documented use of dig, there are no plans to make it work again. I am satisfied with that response and since my use of dig for mDNS lookups was legacy code in my script that was no longer needed (there was another way to accomplish the end goal of the script), it was a good excuse to clean up the script. -- Larry Stone lston...@stonejongleux.com > On Jul 1, 2022, at 6:12 AM, Greg Choules via bind-users > wrote: > > Wireshark works just fine on a Mac (I am using it right now) and yes, it is a > great tool. You also have the choice of using tcpdump in a terminal window, > if that's your preference. Personally I usually capture using tcpdump and > view later in Wireshark. > > On Fri, 1 Jul 2022 at 12:01, Petr Menšík wrote: > Wireshark is a great tool with a nice GUI, which can record you traffic > on selected ports. Just use capture filter port 5353. But I am not > certain it works on Mac just as it does not Linux. > > On 6/27/22 15:10, Larry Stone wrote: > > Petr, you are going to have to tell me how to create an appropriate PCAP > > file. As most of this stuff works so well these days, it’s been years since > > I had to do any sort of packet level analysis (moved on to other things > > professionally) and what I knew of how to do that has long since been lost. > > My issue is on a small home network so very little goes wrong. The > > appropriate tcpdump command to get what is needed should be all I need. > > > > -- > 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 > -- > 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 -- 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: 9.18 behavior change for mDNS queries with dig
Thanks. Submitted - #3428. -- Larry Stone lston...@stonejongleux.com > On Jun 27, 2022, at 1:26 AM, Evan Hunt wrote: > > On Sun, Jun 26, 2022 at 10:00:08PM -0500, Larry Stone wrote: >> I recently moved from 9.16 to 9.18 and just noticed that dig no longer >> resolves mDNS queries. >> >> With 9.16: >> dig +short @224.0.0.251 -p 5353 hostname.local >> 192.168.0.82 >> >> With 9.18: >> dig +short @224.0.0.251 -p 5353 hostname.local >> ;; connection timed out; no servers could be reached >> >> I can’t find anything in the Release Notes (or anyplace else) about this. > > "dig" was rewritten in 9.18 to use the libuv-based network manager > instead of the old socket code; it's probably related to that. Please > open a bug report at https://gitlab.isc.org/isc-projects/bind9/-/issues, > we'll look into it. > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. -- 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: 9.18 behavior change for mDNS queries with dig
Greg, thanks. Exactly what I needed. Need to head out for a few hours but will get on this later today. -- Larry Stone lston...@stonejongleux.com > On Jun 27, 2022, at 8:18 AM, Greg Choules > wrote: > > Hi Larry. > sudo tcpdump -ni any -c 1000 -w .pcap port 5353 > > For I usually include the date, hostname and some other meaningful > stuff to help you remember what it was for in 6 months' time. > Whilst this is running, make some queries in another terminal window. > > I hope this helps. > Cheers, Greg > > On Mon, 27 Jun 2022 at 14:11, Larry Stone wrote: > Petr, you are going to have to tell me how to create an appropriate PCAP > file. As most of this stuff works so well these days, it’s been years since I > had to do any sort of packet level analysis (moved on to other things > professionally) and what I knew of how to do that has long since been lost. > My issue is on a small home network so very little goes wrong. The > appropriate tcpdump command to get what is needed should be all I need. > > -- > Larry Stone > lston...@stonejongleux.com > > > > > > > On Jun 27, 2022, at 1:48 AM, Petr Špaček wrote: > > > > On 27. 06. 22 8:26, Evan Hunt wrote: > >> On Sun, Jun 26, 2022 at 10:00:08PM -0500, Larry Stone wrote: > >>> I recently moved from 9.16 to 9.18 and just noticed that dig no longer > >>> resolves mDNS queries. > >>> > >>> With 9.16: > >>> dig +short @224.0.0.251 -p 5353 hostname.local > >>> 192.168.0.82 > >>> > >>> With 9.18: > >>> dig +short @224.0.0.251 -p 5353 hostname.local > >>> ;; connection timed out; no servers could be reached > >>> > >>> I can’t find anything in the Release Notes (or anyplace else) about this. > >> "dig" was rewritten in 9.18 to use the libuv-based network manager > >> instead of the old socket code; it's probably related to that. Please > >> open a bug report at https://gitlab.isc.org/isc-projects/bind9/-/issues, > >> we'll look into it. > > > > Please don't forget to attach PCAP file produced by tcpdump or similar tool > > so we can see if anything happens on the wire or not. > > > > -- > > Petr Špaček > > -- > 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 -- 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: 9.18 behavior change for mDNS queries with dig
Petr, you are going to have to tell me how to create an appropriate PCAP file. As most of this stuff works so well these days, it’s been years since I had to do any sort of packet level analysis (moved on to other things professionally) and what I knew of how to do that has long since been lost. My issue is on a small home network so very little goes wrong. The appropriate tcpdump command to get what is needed should be all I need. -- Larry Stone lston...@stonejongleux.com > On Jun 27, 2022, at 1:48 AM, Petr Špaček wrote: > > On 27. 06. 22 8:26, Evan Hunt wrote: >> On Sun, Jun 26, 2022 at 10:00:08PM -0500, Larry Stone wrote: >>> I recently moved from 9.16 to 9.18 and just noticed that dig no longer >>> resolves mDNS queries. >>> >>> With 9.16: >>> dig +short @224.0.0.251 -p 5353 hostname.local >>> 192.168.0.82 >>> >>> With 9.18: >>> dig +short @224.0.0.251 -p 5353 hostname.local >>> ;; connection timed out; no servers could be reached >>> >>> I can’t find anything in the Release Notes (or anyplace else) about this. >> "dig" was rewritten in 9.18 to use the libuv-based network manager >> instead of the old socket code; it's probably related to that. Please >> open a bug report at https://gitlab.isc.org/isc-projects/bind9/-/issues, >> we'll look into it. > > Please don't forget to attach PCAP file produced by tcpdump or similar tool > so we can see if anything happens on the wire or not. > > -- > Petr Špaček -- 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
9.18 behavior change for mDNS queries with dig
I recently moved from 9.16 to 9.18 and just noticed that dig no longer resolves mDNS queries. With 9.16: dig +short @224.0.0.251 -p 5353 hostname.local 192.168.0.82 With 9.18: dig +short @224.0.0.251 -p 5353 hostname.local ;; connection timed out; no servers could be reached I can’t find anything in the Release Notes (or anyplace else) about this. I get this on two different Macintoshes - one running MacOS 10.15 (Catalina) and the other on 12.4 (Monterey). On the Catalina Mac, I see the behavior with both source-built BIND as well as the port from MacPorts (just converted from source-building to MacPorts); on the Monterey Mac, I have not built from source so just the MacPorts port. -- Larry Stone lston...@stonejongleux.com -- 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.18.0 and Mac OS X 10.15.7 - cannot build
As I am the one who started this, my plan is to start using MacPorts with the new MacBookPro which I plan to buy in March. The current one is almost ten years old (amazing you can make them last that long) and I was so invested in building from source that switching to package system didn’t make sense. But the new computer, new (to me) OS version, and new architecture makes this the perfect time to switch. -- Larry Stone lston...@stonejongleux.com > On Feb 26, 2022, at 3:27 AM, @lbutlr wrote: > > On 2022 Feb 22, at 04:31, Julien Salort wrote: >> For information, bind 9.18.0 compiles fine under Macports on a variety of >> systems, including Catalina. > > And with homebrew as well, though I don't know what versions of macOS it > does back to (Everything here is now on M1s with Monterey). > > -- > All I know is that using the strap makes me feel like a hot woman in > sunglasses. :-) ~jeffcarlson > > -- > 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 -- 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.18.0 and Mac OS X 10.15.7 - cannot build
Ondrej, thanks. Some quick searching tells me it’s a long-standing issue with
Xcode 10 (and before). Since Bind 9.16.26 works, not a pressing issue for me
and the system is likely to be replaced before 9.16 reaches EOL.
--
Larry Stone
lston...@stonejongleux.com
> On Feb 21, 2022, at 10:58 PM, Ondřej Surý wrote:
>
> Hi Larry,
>
> unfortunately, that’s a bug in a compiler as the atomic_load() is defined as
>
> C atomic_load( const volatile A* obj );
>
> See:
> * https://en.cppreference.com/w/c/atomic/atomic_load
> * https://lists.llvm.org/pipermail/llvm-bugs/2015-May/040025.html
> * http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_459.htm
>
> (e.g. this was fixed in 2014 in the C standard)
>
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
>
> My working hours and your working hours may be different. Please do not feel
> obligated to reply outside your normal working hours.
>
>> On 22. 2. 2022, at 5:26, Larry Stone wrote:
>>
>> Thanks. That gave me a good configure and make on the 10.15.7 system. Have
>> not installed or tried to run it yet.
>>
>> Unfortunately, on the 10.13.6 system, with OpenSSL 1.1.1m now installed as
>> well as nghttp2, while it configures OK, make throws an error with
>> references to Xcode (MacOS proprietary subsystem). The 10.13.6 system has
>> Xcode version 10 on it while the 10.15.7 system has Xcode version 11.
>> Unfortunately, Xcode 11 requires MacOS 10.14 so upgrading the 10.13.6 system
>> does not appear to be an option. The 10.13.6 system (a mid-2010 iMac) is
>> also due for replacement so it may just have to live with Bind 9.16.x until
>> it is replaced.
>>
>> But in case anyone has any ideas, the error make throws is:
>>
>> Making all in isc
>> CC netmgr/libisc_la-netmgr.lo
>> netmgr/netmgr.c:3536:10: error: address argument to atomic operation must be
>> a
>> pointer to non-const _Atomic type ('const isc_refcount_t *' (aka 'const
>> _Atomic(uint_fast32_t) *') invalid)
>>REQUIRE(VALID_NMHANDLE(handle));
>>^~~
>> netmgr/netmgr-int.h:236:3: note: expanded from macro 'VALID_NMHANDLE'
>> atomic_load(&(t)->references) > 0)
>> ^
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/include/stdatomic.h:134:29:
>> note:
>> expanded from macro 'atomic_load'
>> #define atomic_load(object) __c11_atomic_load(object, __ATOMIC_SEQ_CST)
>>^
>> ./include/isc/util.h:279:34: note: expanded from macro 'REQUIRE'
>> #define REQUIRE(e) ISC_REQUIRE(e)
>> ^~
>> ./include/isc/assertions.h:46:11: note: expanded from macro 'ISC_REQUIRE'
>>((void)((cond) || \
>> ^~~~
>> netmgr/netmgr.c:3544:10: error: address argument to atomic operation must be
>> a
>> pointer to non-const _Atomic type ('const isc_refcount_t *' (aka 'const
>> _Atomic(uint_fast32_t) *') invalid)
>>REQUIRE(VALID_NMHANDLE(handle));
>>^~~
>> netmgr/netmgr-int.h:236:3: note: expanded from macro 'VALID_NMHANDLE'
>> atomic_load(&(t)->references) > 0)
>> ^
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/include/stdatomic.h:134:29:
>> note:
>> expanded from macro 'atomic_load'
>> #define atomic_load(object) __c11_atomic_load(object, __ATOMIC_SEQ_CST)
>>^
>> ./include/isc/util.h:279:34: note: expanded from macro 'REQUIRE'
>> #define REQUIRE(e) ISC_REQUIRE(e)
>> ^~
>> ./include/isc/assertions.h:46:11: note: expanded from macro 'ISC_REQUIRE'
>>((void)((cond) || \
>> ^~~~
>> 2 errors generated.
>> make[4]: *** [netmgr/libisc_la-netmgr.lo] Error 1
>> make[3]: *** [all-recursive] Error 1
>> make[2]: *** [all-recursive] Error 1
>> make[1]: *** [all-recursive] Error 1
>> make: *** [all] Error 2
>>
>> --
>> Larry Stone
>> lston...@stonejongleux.com
>>
>>
>>
>>
>>
>>> On Feb 21, 2022, at 4:19 PM, Mark Andrews wrote:
>>>
>>> When building with OpenSSL in non system locations ensure that the
>>> PKG_CONFIG_PATH is properly set.
>>>
>>> e.g.
>>>
>>> OPENSSL=/opt/local
>>> PK
Re: BIND 9.18.0 and Mac OS X 10.15.7 - cannot build
Thanks. That gave me a good configure and make on the 10.15.7 system. Have not
installed or tried to run it yet.
Unfortunately, on the 10.13.6 system, with OpenSSL 1.1.1m now installed as well
as nghttp2, while it configures OK, make throws an error with references to
Xcode (MacOS proprietary subsystem). The 10.13.6 system has Xcode version 10 on
it while the 10.15.7 system has Xcode version 11. Unfortunately, Xcode 11
requires MacOS 10.14 so upgrading the 10.13.6 system does not appear to be an
option. The 10.13.6 system (a mid-2010 iMac) is also due for replacement so it
may just have to live with Bind 9.16.x until it is replaced.
But in case anyone has any ideas, the error make throws is:
Making all in isc
CC netmgr/libisc_la-netmgr.lo
netmgr/netmgr.c:3536:10: error: address argument to atomic operation must be a
pointer to non-const _Atomic type ('const isc_refcount_t *' (aka 'const
_Atomic(uint_fast32_t) *') invalid)
REQUIRE(VALID_NMHANDLE(handle));
^~~
netmgr/netmgr-int.h:236:3: note: expanded from macro 'VALID_NMHANDLE'
atomic_load(&(t)->references) > 0)
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/include/stdatomic.h:134:29:
note:
expanded from macro 'atomic_load'
#define atomic_load(object) __c11_atomic_load(object, __ATOMIC_SEQ_CST)
^
./include/isc/util.h:279:34: note: expanded from macro 'REQUIRE'
#define REQUIRE(e) ISC_REQUIRE(e)
^~
./include/isc/assertions.h:46:11: note: expanded from macro 'ISC_REQUIRE'
((void)((cond) || \
^~~~
netmgr/netmgr.c:3544:10: error: address argument to atomic operation must be a
pointer to non-const _Atomic type ('const isc_refcount_t *' (aka 'const
_Atomic(uint_fast32_t) *') invalid)
REQUIRE(VALID_NMHANDLE(handle));
^~~
netmgr/netmgr-int.h:236:3: note: expanded from macro 'VALID_NMHANDLE'
atomic_load(&(t)->references) > 0)
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/10.0.0/include/stdatomic.h:134:29:
note:
expanded from macro 'atomic_load'
#define atomic_load(object) __c11_atomic_load(object, __ATOMIC_SEQ_CST)
^
./include/isc/util.h:279:34: note: expanded from macro 'REQUIRE'
#define REQUIRE(e) ISC_REQUIRE(e)
^~
./include/isc/assertions.h:46:11: note: expanded from macro 'ISC_REQUIRE'
((void)((cond) || \
^~~~
2 errors generated.
make[4]: *** [netmgr/libisc_la-netmgr.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
--
Larry Stone
lston...@stonejongleux.com
> On Feb 21, 2022, at 4:19 PM, Mark Andrews wrote:
>
> When building with OpenSSL in non system locations ensure that the
> PKG_CONFIG_PATH is properly set.
>
> e.g.
>
> OPENSSL=/opt/local
> PKG_CONFIG_PATH=$OPENSSL/lib/pkgconfig
>
> Mark
>
>> On 22 Feb 2022, at 12:29, Larry Stone wrote:
>>
>> So, just for fun, I decided to see if I could build 9.18.0 on my current
>> MacBookPro (where I already run 9.16.26). It’s on MacOS Catalina 10.15.7
>> (cannot go higher - new MacBookPro coming soon!).
>>
>> First attempt to configure told me I either needed libnghttp2 or to
>> configure with --disable-doh. I downloaded nghttp2 (v1.46.0) from
>> nghttp2.org per the link in the release notes, built and installed it.
>> Attempted to configure bind 9.18.0 and this time configure aborted with:
>> configure: error: in `[redacted dirpath]/bind-9.18.0':
>> configure: error: EVP_DigestSignInit/EVP_DigestVerifyInit support in OpenSSL
>> is mandatory.
>>
>> Tried configuring with --disable-doh and received the same error. Googling
>> that message and variations of it have turned up nothing useful (at least to
>> me).
>>
>> OpenSSL version was 1.1.1a, I subsequently upgraded to 1.1.1m but same
>> error. OpenSSL is installed in /usr/local/ssl and built with the standard
>> ./configure; make.
>>
>> From config.log, the relevant part appears to be:
>> configure:17852: checking for EVP_DigestSignInit
>> configure:17852: gcc -o conftest -g -O2 -pthread -I/usr/local/ssl/include
>> conftest.c -lpthread -lssl -lcrypto >&5
>> ld: library not found for -lssl
>> clang: error: linker command failed with exit code 1 (use -v to see
>> invocation)
>> configure:17852: $? = 1
>>
>> (I then tried to build 9.18.0 on an
BIND 9.18.0 and Mac OS X 10.15.7 - cannot build
So, just for fun, I decided to see if I could build 9.18.0 on my current MacBookPro (where I already run 9.16.26). It’s on MacOS Catalina 10.15.7 (cannot go higher - new MacBookPro coming soon!). First attempt to configure told me I either needed libnghttp2 or to configure with --disable-doh. I downloaded nghttp2 (v1.46.0) from nghttp2.org per the link in the release notes, built and installed it. Attempted to configure bind 9.18.0 and this time configure aborted with: configure: error: in `[redacted dirpath]/bind-9.18.0': configure: error: EVP_DigestSignInit/EVP_DigestVerifyInit support in OpenSSL is mandatory. Tried configuring with --disable-doh and received the same error. Googling that message and variations of it have turned up nothing useful (at least to me). OpenSSL version was 1.1.1a, I subsequently upgraded to 1.1.1m but same error. OpenSSL is installed in /usr/local/ssl and built with the standard ./configure; make. From config.log, the relevant part appears to be: configure:17852: checking for EVP_DigestSignInit configure:17852: gcc -o conftest -g -O2 -pthread -I/usr/local/ssl/include conftest.c -lpthread -lssl -lcrypto >&5 ld: library not found for -lssl clang: error: linker command failed with exit code 1 (use -v to see invocation) configure:17852: $? = 1 (I then tried to build 9.18.0 on an older system I have running macOS 10.13.6. I did not try to install nghttp2 on it and configure worked fine with --disable-doh. But it then errored with some SSL issues (./openssl_shim.h:99:1: error: conflicting types for ‘OPENSSL_init_crypto’ was the first) but I have not started to dig into that (this system still has OpenSSL 1.1.1a)). Anyway, I’m stuck on the "configure: error: EVP_DigestSignInit/EVP_DigestVerifyInit support in OpenSSL is mandatory” error and not sure what direction to go. I think it’s an issue with OpenSSL but I can’t see what it is (and Bind 9.16.x builds fine). Probably something simple but I need a nudge in the right direction. Thanks. -- Larry Stone lston...@stonejongleux.com -- 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.13 and Mac OS X 10.13.6 - problems with ./configure
> On Mar 26, 2021, at 12:16 AM, Paul Cizmas wrote: > > I tried now using libuv 1.35 and it failed again during make at Is this during the build of BIND or libuv? Looks like libuv. If it’s during the build of libuv, have you also installed its dependencies? From my notes from when I first built BIND 9.16.x, "Starting with 9.16, needs libuv which in turn needs libtools, automake, and autoconf. After installing libtools, rename /usr/local/lib/libtool and libtoolize to glibtool and glibtoolize” (whatever led me to needing to rename those files is not in my notes). I also found I needed to update Xcode but that may have been for a separate issue. But I agree with Ondřej, having already installed libuv via Homebrew, why are you not using Homebrew for BIND? -- Larry Stone lston...@stonejongleux.com ___ 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: BIND 9.16.13 and Mac OS X 10.13.6 - problems with ./configure
I’ve been building BIND on MacOS for years (currently on Catalina but has worked on almost the entire Mac OS X series. > > On Mar 25, 2021, at 7:50 PM, Paul Cizmas wrote: > > I am new to BIND and I am trying to install version 9.16.13 on a Mac OS X > 10.13.6. > > I downloaded version 9.16.13 and, following the suggestions from > https://krypted.com/mac-os-x/dns-install-bind-macos/, I am trying to > configure using > > ./configure --enable-symtable=none --infodir="/usr/share/info" > --sysconfdir="/etc" --localstatedir="/var" --enable-atomic="no" > --with-gssapi=yes --with-libxml2=no > I don’t know that site and I don’t know what most of the those options do. A simple ./configure has almost always worked for me. > This fails because of libuv > > checking for pthread_set_name_np... no > checking for pthread_np.h... no > checking for libuv... checking for libuv >= 1.0.0... no > configure: error: libuv not found > > I have libuv installed, however. It is version 1.41.0. > Is libuv where the BIND configure is looking for it? My libuv files are in /usr/local/lib. I have libuv 1.35 (doubt the version is making a difference) and it looks like I installed it a year ago. Are you using something like homebrew or macports? I don’t as I was already too established doing everything from scratch when I learned about them. But I believe at least one of them if not both use their own set of directories so something built with one of them will not be found by something coming from the other or done from scratch. Those instructions from krypted.com appear to be doing a “from scratch” version so if you installed libuv with homebrew or macports, I doubt the krypted.com instructions will find it. -- Larry Stone lston...@stonejongleux.com ___ 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: A And Cname-record
But if there is a possibly relevant spelling error, it would be helpful to point out exactly where the error is rather than just saying “check your spelling”. Our eyes frequently see what we expect to see and therefore don’t see the error, even when told there is an error. -- Larry Stone lston...@stonejongleux.com > On Jun 18, 2020, at 9:29 AM, Chuck Aurora wrote: > > On 2020-06-18 06:41, Ondřej Surý wrote: >> Jukka and others, >> I would prefer if we didn’t scold people for typos on the mailing list. The >> typo >> in the message had no impact on the question itself, and here, we are trying >> to build community that’s welcoming to newcomers to the wonderful world >> of DNS. > > Is it a wonderful world? :) > > Anyway, the vast majority of errors posted here DO boil down to things like > the typos and syntax niceties (trailing dot) that Jukka pointed out. Granted, > in this case that was obviously an email typo, not copied exactly from the > zone file, but I'd simply suggest that pointing out a typo is not "scolding." > It's often hard for ME to see MY typos, because I know what I meant to type; > but for fresh eyes they are much easier to spot. > ___ > 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 ___ 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: Compile error Bind 9.16.1 on MacOS 10.14.6
Mark, that’s what I always thought until today. But after Ondrej’s reply,
although I already had the command line tools installed and had updated them
with each major MacOS update, I did a Xcode-select --install which reinstalled
them. Still no good on the bind compile. So did a full update of Xcode to the
latest for my MacOS version and then bind built fine. But my Xcode was very,
very old - version 7. Current is 11.x (11.3.1 for MacOS Mojave, 11.4 for
Catalina).
--
Larry Stone
lston...@stonejongleux.com
> On Mar 24, 2020, at 5:40 PM, Mark Andrews wrote:
>
> You shouldn't need all of Xcode to build BIND 9. Just the command line tools.
> That said Xcode or the Command Line tools should be upgraded with each OS
> upgrade.
>
> From BIND9’s README
>
> macOS
>
> Building on macOS assumes that the "Command Tools for Xcode" is installed.
> This can be downloaded from https://developer.apple.com/download/more/ or,
> if you have Xcode already installed, you can run xcode-select --install.
> (Note that an Apple ID may be required to access the download page.)
>
> Mark
>
>
>> On 25 Mar 2020, at 09:08, Larry Stone wrote:
>>
>> Thanks, Ondrej. It took some doing but got the latest Xcode for my version
>> of MacOS installed (multi GB so long time to download, then a long time to
>> expand). Bind 9.16.1 the built and is now running on my “test” system (it’s
>> my laptop but I use it to test stuff before it goes on my server (but not
>> running MacOS Server) Macintosh).
>>
>> For anyone else having this issue, Apple does not make it easy to get older
>> versions of Xcode. The App Store will only offer the latest which is for
>> Catalina (MacOS 10.15.x). I haven’t upgraded yet so it took some time to
>> find how to get an older version from the Apple Developers website.
>>
>> And honestly, I hadn’t realized how out of date my version of Xcode was as I
>> only use the command line tools and everything had been working fine until
>> today. Something to add to the MacOS upgrade checklist.
>>
>> --
>> Larry Stone
>> lston...@stonejongleux.com
>>
>>
>>
>>
>>
>>> On Mar 24, 2020, at 3:29 PM, Ondřej Surý wrote:
>>>
>>> Hi Larry,
>>>
>>> it seems like your macOS SDK is incomplete or something like this.
>>>
>>> Both clock_gettime() and CLOCK_REALTIME are available since Mac OSX 10.12.
>>>
>>> Please make sure you have up-to-date Xcode and matching Command Line Utils
>>> for Xcode.
>>>
>>> Ondrej
>>> --
>>> Ondřej Surý
>>> ond...@isc.org
>>>
>>>> On 24 Mar 2020, at 21:23, Larry Stone wrote:
>>>>
>>>> I’ve been building Bind from source for a number of years on Macintoshes.
>>>> Made my first attempt at Bind 9.16.1 today. After navigating the new
>>>> dependency for libuv and getting a good configure, I tried make and
>>>> errored at:
>>>>
>>>> gcc -include /Users/larry/ServerAppsNoBackup/bind-9.16.1/config.h
>>>> -I/Users/larry/ServerAppsNoBackup/bind-9.16.1 -I../../.. -I./include
>>>> -I./../pthreads/include -I../include -I./../include -I./..
>>>> -I/usr/local/ssl/include -g -O2 -Qunused-arguments -pthread
>>>> -I/usr/local/include -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual
>>>> -Wwrite-strings -Wformat -Wpointer-arith -Wno-missing-field-initializers
>>>> -fno-strict-aliasing -c time.c
>>>> time.c:117:6: warning: implicit declaration of function 'clock_gettime' is
>>>> invalid in C99 [-Wimplicit-function-declaration]
>>>>if (clock_gettime(CLOCKSOURCE, ) == -1) {
>>>>^
>>>> time.c:117:20: error: use of undeclared identifier 'CLOCK_REALTIME'
>>>>if (clock_gettime(CLOCKSOURCE, ) == -1) {
>>>> ^
>>>> time.c:42:21: note: expanded from macro 'CLOCKSOURCE'
>>>> #define CLOCKSOURCE CLOCK_REALTIME
>>>> ^
>>>> time.c:151:20: error: use of undeclared identifier 'CLOCK_REALTIME'
>>>>if (clock_gettime(CLOCKSOURCE, ) == -1) {
>>>> ^
>>>> time.c:42:21: note: expanded from macro 'CLOCKSOURCE'
>>>> #define CLOCKSOURCE CLOCK_REALTIME
>>>>^
>>>> 1 warning and 2 errors generated.
>>>> make[3]: *** [time.o] Error 1
>>>> make[2]: *** [subdirs] Error 1
>>>> make[1]: *** [subdirs] Error 1
>>>> make: *** [subdirs] Er
Re: Compile error Bind 9.16.1 on MacOS 10.14.6
Thanks, Ondrej. It took some doing but got the latest Xcode for my version of
MacOS installed (multi GB so long time to download, then a long time to
expand). Bind 9.16.1 the built and is now running on my “test” system (it’s my
laptop but I use it to test stuff before it goes on my server (but not running
MacOS Server) Macintosh).
For anyone else having this issue, Apple does not make it easy to get older
versions of Xcode. The App Store will only offer the latest which is for
Catalina (MacOS 10.15.x). I haven’t upgraded yet so it took some time to find
how to get an older version from the Apple Developers website.
And honestly, I hadn’t realized how out of date my version of Xcode was as I
only use the command line tools and everything had been working fine until
today. Something to add to the MacOS upgrade checklist.
--
Larry Stone
lston...@stonejongleux.com
> On Mar 24, 2020, at 3:29 PM, Ondřej Surý wrote:
>
> Hi Larry,
>
> it seems like your macOS SDK is incomplete or something like this.
>
> Both clock_gettime() and CLOCK_REALTIME are available since Mac OSX 10.12.
>
> Please make sure you have up-to-date Xcode and matching Command Line Utils
> for Xcode.
>
> Ondrej
> --
> Ondřej Surý
> ond...@isc.org
>
>> On 24 Mar 2020, at 21:23, Larry Stone wrote:
>>
>> I’ve been building Bind from source for a number of years on Macintoshes.
>> Made my first attempt at Bind 9.16.1 today. After navigating the new
>> dependency for libuv and getting a good configure, I tried make and errored
>> at:
>>
>> gcc -include /Users/larry/ServerAppsNoBackup/bind-9.16.1/config.h
>> -I/Users/larry/ServerAppsNoBackup/bind-9.16.1 -I../../.. -I./include
>> -I./../pthreads/include -I../include -I./../include -I./..
>> -I/usr/local/ssl/include -g -O2 -Qunused-arguments -pthread
>> -I/usr/local/include -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual
>> -Wwrite-strings -Wformat -Wpointer-arith -Wno-missing-field-initializers
>> -fno-strict-aliasing -c time.c
>> time.c:117:6: warning: implicit declaration of function 'clock_gettime' is
>>invalid in C99 [-Wimplicit-function-declaration]
>> if (clock_gettime(CLOCKSOURCE, ) == -1) {
>> ^
>> time.c:117:20: error: use of undeclared identifier 'CLOCK_REALTIME'
>> if (clock_gettime(CLOCKSOURCE, ) == -1) {
>>^
>> time.c:42:21: note: expanded from macro 'CLOCKSOURCE'
>> #define CLOCKSOURCE CLOCK_REALTIME
>> ^
>> time.c:151:20: error: use of undeclared identifier 'CLOCK_REALTIME'
>> if (clock_gettime(CLOCKSOURCE, ) == -1) {
>>^
>> time.c:42:21: note: expanded from macro 'CLOCKSOURCE'
>> #define CLOCKSOURCE CLOCK_REALTIME
>> ^
>> 1 warning and 2 errors generated.
>> make[3]: *** [time.o] Error 1
>> make[2]: *** [subdirs] Error 1
>> make[1]: *** [subdirs] Error 1
>> make: *** [subdirs] Error 1
>>
>> Searching has turned up nothing for me.
>>
>> --
>> Larry Stone
>> la...@stonejongleux.com
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Larry Stone
>> lston...@stonejongleux.com
>>
>>
>>
>>
>>
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>
___
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
Compile error Bind 9.16.1 on MacOS 10.14.6
I’ve been building Bind from source for a number of years on Macintoshes. Made
my first attempt at Bind 9.16.1 today. After navigating the new dependency for
libuv and getting a good configure, I tried make and errored at:
gcc -include /Users/larry/ServerAppsNoBackup/bind-9.16.1/config.h
-I/Users/larry/ServerAppsNoBackup/bind-9.16.1 -I../../.. -I./include
-I./../pthreads/include -I../include -I./../include -I./..
-I/usr/local/ssl/include -g -O2 -Qunused-arguments -pthread
-I/usr/local/include -fPIC -W -Wall -Wmissing-prototypes -Wcast-qual
-Wwrite-strings -Wformat -Wpointer-arith -Wno-missing-field-initializers
-fno-strict-aliasing -c time.c
time.c:117:6: warning: implicit declaration of function 'clock_gettime' is
invalid in C99 [-Wimplicit-function-declaration]
if (clock_gettime(CLOCKSOURCE, ) == -1) {
^
time.c:117:20: error: use of undeclared identifier 'CLOCK_REALTIME'
if (clock_gettime(CLOCKSOURCE, ) == -1) {
^
time.c:42:21: note: expanded from macro 'CLOCKSOURCE'
#define CLOCKSOURCE CLOCK_REALTIME
^
time.c:151:20: error: use of undeclared identifier 'CLOCK_REALTIME'
if (clock_gettime(CLOCKSOURCE, ) == -1) {
^
time.c:42:21: note: expanded from macro 'CLOCKSOURCE'
#define CLOCKSOURCE CLOCK_REALTIME
^
1 warning and 2 errors generated.
make[3]: *** [time.o] Error 1
make[2]: *** [subdirs] Error 1
make[1]: *** [subdirs] Error 1
make: *** [subdirs] Error 1
Searching has turned up nothing for me.
--
Larry Stone
la...@stonejongleux.com
--
Larry Stone
lston...@stonejongleux.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.12.4 python error building on MacOS
Thanks. A simple $ sudo python -m ensure pip —default-pip $ sudo pip install —upgrade-pip $ sudo pip install ply took care of it. -- Larry Stone lston...@stonejongleux.com > On Mar 1, 2019, at 2:41 PM, Mark Andrews wrote: > > We had a bug report that dnssec-checkds, dnssec-coverage and dnssec-keymgr > where not > being installed by default and yes, that is a bug. You can choose not to > install > them by specifying -—with-python=no to configure. > > The configure message is saying that you don’t have the “ply" python module > installed. > You need to install it. > > Mark > > >> On 2 Mar 2019, at 7:13 am, Larry Stone wrote: >> >> I’m trying to build the just released BIND 9.12.4 on a Macintosh running >> Mojave (10.14.3). Same results on one running High Sierra (10.13.6). >> >> Running configure, I get an error checking for python: >> checking for python... /usr/bin/python >> checking if /usr/bin/python is python2 version >= 2.7 or python3 version >= >> 3.2... yes >> checking Python module 'argparse'... yes >> checking Python module 'ply'... no >> checking for python3... no >> checking for python3.7... no >> checking for python3.6... no >> checking for python3.5... no >> checking for python3.4... no >> checking for python3.3... no >> checking for python3.2... no >> checking for python2... no >> checking for python2.7... /usr/bin/python2.7 >> checking if /usr/bin/python2.7 is python2 version >= 2.7 or python3 version >> >= 3.2... yes >> checking Python module 'argparse'... yes >> checking Python module 'ply'... no >> checking for Python support... no >> configure: error: Python required for dnssec-keymgr >> >> If I try the same thing with 9.12.3-P4, it configures OK. The relevant >> output is: >> checking for python... /usr/bin/python >> checking python2 version >= 2.7 or python3 version >= 3.2... found >> checking python module 'argparse'... found >> checking python module 'ply'... not found >> checking for python3... no >> checking for python3.5... no >> checking for python3.4... no >> checking for python3.3... no >> checking for python3.2... no >> checking for python2... no >> checking for python2.7... /usr/bin/python2.7 >> checking python2 version >= 2.7 or python3 version >= 3.2... found >> checking python module 'argparse'... found >> checking python module 'ply'... not found >> checking for python support... disabled >> >> /usr/bin/python -V returns Python 2.7.10. I don’t know why even for >> 9.12.3-P4 which configures OK it says python support … disabled. >> >> I’m not seeing anything in the Release Notes about a change in Python >> requirements. Python is the version distributed with MacOS by Apple. >> >> -- >> Larry Stone >> lston...@stonejongleux.com >> >> >> >> >> >> ___ >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >> unsubscribe from this list >> >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.12.4 python error building on MacOS
I’m trying to build the just released BIND 9.12.4 on a Macintosh running Mojave (10.14.3). Same results on one running High Sierra (10.13.6). Running configure, I get an error checking for python: checking for python... /usr/bin/python checking if /usr/bin/python is python2 version >= 2.7 or python3 version >= 3.2... yes checking Python module 'argparse'... yes checking Python module 'ply'... no checking for python3... no checking for python3.7... no checking for python3.6... no checking for python3.5... no checking for python3.4... no checking for python3.3... no checking for python3.2... no checking for python2... no checking for python2.7... /usr/bin/python2.7 checking if /usr/bin/python2.7 is python2 version >= 2.7 or python3 version >= 3.2... yes checking Python module 'argparse'... yes checking Python module 'ply'... no checking for Python support... no configure: error: Python required for dnssec-keymgr If I try the same thing with 9.12.3-P4, it configures OK. The relevant output is: checking for python... /usr/bin/python checking python2 version >= 2.7 or python3 version >= 3.2... found checking python module 'argparse'... found checking python module 'ply'... not found checking for python3... no checking for python3.5... no checking for python3.4... no checking for python3.3... no checking for python3.2... no checking for python2... no checking for python2.7... /usr/bin/python2.7 checking python2 version >= 2.7 or python3 version >= 3.2... found checking python module 'argparse'... found checking python module 'ply'... not found checking for python support... disabled /usr/bin/python -V returns Python 2.7.10. I don’t know why even for 9.12.3-P4 which configures OK it says python support … disabled. I’m not seeing anything in the Release Notes about a change in Python requirements. Python is the version distributed with MacOS by Apple. -- Larry Stone lston...@stonejongleux.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.11.x build failing on Mac OS X - gssapi errors
I’m also running OS X 10.12.5 so decided to see if I can replicate this. I normally use the 9.10 version (9.10.5-P1 builds fine (./configure and make) but I have not done make install yet) but decided to try to build 9.11.1-P1 to see what happens. In short, cannot replicate. I did both ./configure and ./configure —with-atf followed by make (completely deleted the directory and started over between the two) and both build fine. I saw some warnings scroll by (normal) but no errors. One difference in what I do vs. the OP is I noticed he does sudo make. I do the make as myself, then sudo for make install. I don’t think that should make a difference. -- Larry Stone lston...@stonejongleux.com > On Jun 15, 2017, at 1:44 AM, James Brown via bind-users > <bind-users@lists.isc.org> wrote: > > I couldn’t get 9.11 to compile for me on OS X 10.12.5. Same problem with > 9.11.1-P1. sudo make gives errors like this: > > In file included from /Downloads/bind-9.11.1-P1/lib/dns/include/dst/dst.h:24: > /Users/jlbrown/Downloads/bind-9.11.1-P1/lib/dns/include/dst/gssapi.h:30:10: > error: expected "FILENAME" or > #include ISC_PLATFORM_GSSAPIHEADER > ^ > /Downloads/bind-9.11.1-P1/lib/dns/include/dst/gssapi.h:52:10: error: unknown > type name 'gss_cred_id_t' >gss_cred_id_t *cred); >^ > /Downloads/bind-9.11.1-P1/lib/dns/include/dst/gssapi.h:71:24: error: unknown > type name 'gss_cred_id_t' > dst_gssapi_releasecred(gss_cred_id_t *cred); >^ > /Downloads/bind-9.11.1-P1/lib/dns/include/dst/gssapi.h:88:30: error: unknown > type name 'gss_ctx_id_t' >isc_buffer_t *outtoken, gss_ctx_id_t *gssctx, >^ > /Downloads/bind-9.11.1-P1/lib/dns/include/dst/gssapi.h:111:22: error: unknown > type name 'gss_cred_id_t' > dst_gssapi_acceptctx(gss_cred_id_t cred, > ^ > /Downloads/bind-9.11.1-P1/lib/dns/include/dst/gssapi.h:114:8: error: unknown > type name 'gss_ctx_id_t' > gss_ctx_id_t *context, dns_name_t *principal, > ^ > /Downloads/bind-9.11.1-P1/lib/dns/include/dst/gssapi.h:144:39: error: unknown > type name 'gss_ctx_id_t' > dst_gssapi_deletectx(isc_mem_t *mctx, gss_ctx_id_t *gssctx); > > I used: > > ./configure --with-atf > > And then sudo make. > > If I use: > > ./configure --with-atf —without-gssapi > > I get it failing with: > > Undefined symbols for architecture x86_64: > "_gss_accept_sec_context", referenced from: > _gss_accept_sec_context_spnego in libdns.a(spnego.o) > (maybe you meant: _gss_accept_sec_context_spnego) > "_gss_acquire_cred", referenced from: > _dst_gssapi_acquirecred in libdns.a(gssapictx.o) > "_gss_delete_sec_context", referenced from: > _dst_gssapi_deletectx in libdns.a(gssapictx.o) > "_gss_display_name", referenced from: > _log_cred in libdns.a(gssapictx.o) > _dst_gssapi_acceptctx in libdns.a(gssapictx.o) > "_gss_display_status", referenced from: > _gss_error_tostring in libdns.a(gssapictx.o) > "_gss_export_sec_context", referenced from: > _gssapi_dump in libdns.a(gssapi_link.o) > "_gss_get_mic", referenced from: > _gssapi_sign in libdns.a(gssapi_link.o) > "_gss_import_name", referenced from: > _dst_gssapi_acquirecred in libdns.a(gssapictx.o) > _dst_gssapi_initctx in libdns.a(gssapictx.o) > "_gss_import_sec_context", referenced from: > _gssapi_restore in libdns.a(gssapi_link.o) > "_gss_init_sec_context", referenced from: > _gss_init_sec_context_spnego in libdns.a(spnego.o) > (maybe you meant: _gss_init_sec_context_spnego) > "_gss_inquire_cred", referenced from: > _log_cred in libdns.a(gssapictx.o) > "_gss_release_buffer", referenced from: > _gssapi_sign in libdns.a(gssapi_link.o) > _gssapi_dump in libdns.a(gssapi_link.o) > _gss_error_tostring in libdns.a(gssapictx.o) > _log_cred in libdns.a(gssapictx.o) > _dst_gssapi_initctx in libdns.a(gssapictx.o) > _dst_gssapi_acceptctx in libdns.a(gssapictx.o) > _gss_accept_sec_context_spnego in libdns.a(spnego.o) > ... > "_gss_release_cred", referenced from: > _dst_gssapi_releasecred in libdns.a(gssapictx.o) > "_gss_release_name", referenced from: > _dst_gssapi_acquirecred in libdns.a(gssapictx.o) > _log_cred in libdns.a(gssapictx.o) > _dst_gssapi_initctx in libdns.a(gssapictx.o) > _dst_gssapi_acceptctx in libdns.a(gssapictx.o) > &quo
Re: Bind Queries log file format
> On Feb 7, 2017, at 11:07 PM, Mark Andrews <ma...@isc.org> wrote: > > > No, we have a field that has more information in it. Same field E -> > E(version) > > 08-Feb-2017 15:15:44.532 client @0x7fc1c803c600 127.0.0.1#57982/key external > (rock.dv.isc.org): view external: query: rock.dv.isc.org IN A -SE(0)DV > (127.0.0.1) > > Or with ECS > > 08-Feb-2017 15:56:27.109 client @0x7fc1c503e800 127.0.0.1#63454 (.): view > external: query: . IN SOA -E(0)DV (127.0.0.1) [ECS 127.0.0.0/8/0] > > Or from a stub resolver. > > 08-Feb-2017 16:02:22.971 client @0x7fc1c490dc00 127.0.0.1#61028 > (sprocket.isc.org): view secure: query: sprocket.isc.org IN A + (127.0.0.1) Fair enough, provided depending on how the format of the log record is defined (columns or by field delimiters), it’s still the same format and E(version) is something that will make sense (for however you would define sense here) to an older program expecting just E. But in my haste in my original posting, I picked up on E to E(version) change but missed that in going from 9.10.0 to 9.11.0, you inserted cookies between CD and local address. That should have gone on the end (perhaps that’s what this whole thing is about - I rarely look at BIND log files and when I do, it’s just me reading them, no parsing program involved). So restating what I originally posted, instead of: 9.10.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD, local address 9.11.0: client, qname, qclass, qtype, RD, signed, EDNS + version, TCP, DO, CD, cookies, local address 9.12.0: client, qname, qclass, qtype, RD, signed, EDNS + version, TCP, DO, CD, cookies, local address, ecs it should have been 9.10.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD, local address 9.11.0: client, qname, qclass, qtype, RD, signed, EDNS + version, TCP, DO, CD, local address, cookies 9.12.0: client, qname, qclass, qtype, RD, signed, EDNS + version, TCP, DO, CD, local address, cookies, ecs -- Larry Stone lston...@stonejongleux.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind Queries log file format
I’ve been around long enough to remember when upward compatability was something that was expected. A program built to work with the current version of data (e.g. data records, log records, whatever) or even a shared library was expected to be able to continue to work with all future versions without the need for changes or rebuilding/recompiling. For data, that meant new fields went on the end of the record so that anything expecting the old format still found everything where it always was and the new stuff was at the end of the record where the old programs never even looked. But sadly, this appears to be a lost art these days. Where I work, we have a data set that has 20 years of data in it. Over the years, the record length was extended but once a field was placed at a given point in the record, it never, ever moved so that programs written years ago that had no need for the new fields still ran just fine. And with hundreds if not thousands of programs around the company that read this data set, insuring that format changes did not break things was a very high priority. Occasionally, fields went away in which case that spot in the record was just left blank for all new records. For the BIND log records described below, what I describe appears to be what was done through 9.10.0. But then at 9.11.0, we have a field in the middle of the record being changed (EDNS changed to EDNS+version). What, IMHO, should have been done here was to put the version on the end (either going with a split filed - EDNS in one place and the version in another or by duplicating EDNS by having it without version where it was and then again with version on the end of the record) so that old programs parsing the log file still worked. So instead of: > 9.10.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD, local > address > 9.11.0: client, qname, qclass, qtype, RD, signed, EDNS + version, TCP, DO, > CD, cookies, local address > 9.12.0: client, qname, qclass, qtype, RD, signed, EDNS + version, TCP, DO, > CD, cookies, local address, ecs it should have been > 9.10.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD, local > address > 9.11.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD, cookies, > local address, EDNSversion > 9.12.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD, cookies, > local address, EDNSversion, ecs -- Larry Stone lston...@stonejongleux.com > On Feb 7, 2017, at 9:06 PM, Mark Andrews <ma...@isc.org> wrote: > > > In message > <DB6PR0501MB2309198D18749297D7EBAE41C0420@DB6PR0501MB2309.eurprd05.p > rod.outlook.com>, Paul Roberts writes: >> I have to say I agree with the approach of putting this extra info into a sep >> arate file. I appreciate this could cause additional problems (disk utilisati >> on, extra I/O's, log rolling etc.) but I would prefer to keep the query log f >> ormat as stable as possible. I am still mopping up the last big change when I >> SC added the FQDN reference at the start of each message and I'm getting a li >> ttle tired of dealing with customers and their broken regex's when log format >> s change because they've upgraded BIND. >> >> There are also wider implications - there are products out there that hard co >> de the regex and it can't be modified, so that then requires dealing with ven >> dors, submitting bug reports/enhancement requests, providing evidence, busine >> ss impact statements, also I have to perform root cause analysis for customer >> s why their SIEM is no longer capturing the logs, which can have serious regu >> latory implications and consequences (banks etc.), then there's testing every >> upgrade in the lab before we run in production etc., I have enough work on m >> y plate as it is! :-) >> >> Basically there's a whole world of pain out there that can be avoided if you >> just keep the log format the same. :-) >> >> Thanks, >> >> Paul > > Change happens. The DNS protocol has expanded enormously from the > original specification. To expect the summary log line to not > change with that change is just not realistic. We do try to keep > the format change to a .0 release. This one we missed. > > We currently log: > > client, qname, qclass, qtype, RD (+/-), was the request signed (S), > the EDNS with version, was it over TCP (T), was DO=1 set (D), was > CD=1 set (C), were DNS COOKIES in use and was it a valide server > cookie or just a client cookie (V, K). We log the interface it was > received on and if the ECS option. > > Not everyone wants all of these details but someone wants everyone > of these. > > 9.1.0: client, qname, qclass, qtype > 9.2.0: client, qname, qclass, qtype > 9.3.0: client,
Re: Non-responsive name servers when started during boot on OS X Mavericks 10.9
On Jan 21, 2014, at 11:38 PM, LuKreme krem...@kreme.com wrote: In the launchd plist do you have something like I finally got around to testing both of these. dict keyNetworkState/key true/ /dict Had no effect. or maybe keyinetdCompatibility/key dict keyWait/key true/ /dict Wouldn’t even start. Repeatedly (about 150 per second) logged: Jan 24 18:37:35 host.example.com launchproxy[518]: launch_msg(CheckIn): Operation not permitted Jan 24 18:37:35 host com.apple.launchd[1] (org.isc.named[518]): Exited with code: 1 to tell the system not to start bind until after the network is up? -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature ___ 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: Non-responsive name servers when started during boot on OS X Mavericks 10.9
On Jan 22, 2014, at 12:27 PM, LuKreme krem...@kreme.com wrote: Right, but Apple did this by having their compile of bind start listening on 127.0.0.1 and then prodding it once the network was up and the IP address was available. Since Apple doesn't take this extra step, you'd need to tell launchd to wait for the Network, or you'd have to duplicate Apple's solution (probably by sending need a SIGHUP when the network is live). Looking at the BIND code at opensource.apple.com. I can have found some (but probably not all) of the changes Apple makes. But I’m not a C programmer so trying to make the same changes to what ISC distributes is probably beyond me. Nor is it probably worth the effort. The startup delay script works and boot are few and far between. What’s another 30 seconds when you’re rebooting a SOHO server with a number of users you can count on one hand? -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature ___ 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: Non-responsive name servers when started during boot on OS X Mavericks 10.9
On Jan 21, 2014, at 5:32 AM, Carsten Strotmann c...@strotmann.de wrote: Hi Chris, Chris Buxton cli...@buxtonfamily.us writes: I’d bet that the package from Men Mice includes this script or an equivalent workaround. When I wrote the original script I wrote about above, I worked at Men Mice. Your script or the sleep timer is not in the package anymore, but maybe it should be. I did some testing on our MacOS X Systems, and we also did not receive issue reports from customers using the MacOS X installer packages. Thanks for reminding me (us). However I will look into the issue and put the sleep back in if needed (or find a better patch to inform BIND on changes of the network config). @Larry: let me know if your are using the Men Mice compiled BIND installer packages, and if the issue still appears. Carsten, I finally had a chance to play with the Men Mice port and it exhibited the same issue of not listening on the external address until given a SIGHUP. It’s definitely a startup timing issue and some systems may start up fast enough to not have the issue (for instance, my newer MBP with an SSD for its system disk seems to consistently come up clean without a delay script; OTOH, my iMac (primary server) and another MBP with a hard disk do not come up clean and need the delay). One other issue with Men Mice port is installs everything in Apple reserved directories. These days, /usr/ (except /usr/local/), /var, /etc, and /System/Library should be considered reserved to Apple. User installed files should be in the /usr/local/ equivalents (or /Library instead of /System/Library). Anything in the Apple reserved directories can be overwritten by OS X updates. Apple generally does not touch /usr/local or /System/Library. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature ___ 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: Non-responsive name servers when started during boot on OS X Mavericks 10.9
On Jan 21, 2014, at 11:38 PM, LuKreme krem...@kreme.com wrote: On 18 Jan 2014, at 06:52 , Larry Stone lston...@stonejongleux.com wrote: That is not the problem. In the launchd plist do you have something like dict keyNetworkState/key true/ /dict or maybe keyinetdCompatibility/key dict keyWait/key true/ /dict to tell the system not to start bind until after the network is up? No, but neither does Apple. My launched plist is the same as what Apple provided with OS X 10.8 as well as being the one at http://opensource.apple.com/source/bind9/bind9-45.100/org.isc.named.plist modified only for the slightly different file specs. Note that per the launchd.plist man page, NetworkState is an option to the KeepAlive key and does not stand alone in a plist. ?xml version=1.0 encoding=UTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd; plist version=1.0 dict keyDisabled/key true/ keyEnableTransactions/key true/ keyLabel/key stringorg.isc.named/string keyOnDemand/key false/ keyProgramArguments/key array string/usr/local/sbin/named/string string-f/string string-c/string string/usr/local/etc/named.conf/string /array keyServiceIPC/key false/ /dict /plist But another good area for experimentation when I have a chance (yesterday’s surprise announcement that Logmein is discontinuing their Free product effective immediately shuffled the priorities :-( ). -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature ___ 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: Non-responsive name servers when started during boot on OS X Mavericks 10.9
On Wed, 22 Jan 2014, LuKreme wrote: Right, but Apple did this by having their compile of bind start listening on 127.0.0.1 and then prodding it once the network was up and the IP address was available. Since Apple doesn't take this extra step, you'd need to tell launchd to wait for the Network, or you'd have to duplicate Apple's solution (probably by sending need a SIGHUP when the network is live). This discussion is going full circle (although part of it may have been a couple of private emails I was sent). I speculated that Apple was making undocumented patches to bind and someone said no, it's as distributed. But this is why I really like installing from source - too many packagers making undocumented changes that cause software to behave differently than the documentation says it till. But I will get to testing your ideas. In the meantime, with a startup delay script and an hourly monitoring job, I have a comfortable environment. -- Larry Stone lston...@stonejongleux.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Non-responsive name servers when started during boot on OS X Mavericks 10.9
On Jan 21, 2014, at 5:32 AM, Carsten Strotmann c...@strotmann.de wrote: Hi Chris, Chris Buxton cli...@buxtonfamily.us writes: I’d bet that the package from Men Mice includes this script or an equivalent workaround. When I wrote the original script I wrote about above, I worked at Men Mice. Your script or the sleep timer is not in the package anymore, but maybe it should be. I did some testing on our MacOS X Systems, and we also did not receive issue reports from customers using the MacOS X installer packages. Thanks for reminding me (us). However I will look into the issue and put the sleep back in if needed (or find a better patch to inform BIND on changes of the network config). @Larry: let me know if your are using the Men Mice compiled BIND installer packages, and if the issue still appears. Carsten, no I am not using the Men Mice compiled BIND (until three days ago, I had not even heard of Men Mice). I might be able to play with it in a test environment later in the week. Is there any documentation for it or is it just the installer package? -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature ___ 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: Non-responsive name servers when started during boot on OS X Mavericks 10.9
On Jan 20, 2014, at 1:22 PM, Chris Buxton cli...@buxtonfamily.us wrote: Problem: This morning, by happenstance, both were rebooted a few minutes apart and suddenly, nobody could access anything. Finally figured out that named on both was not responding (queries timed out). Killed named (which was immediately restarted by Apple’s launchd) and all was well. Rebooted the secondary to see if it was repeatable and same thing. Nothing of interest in the log - both the initial startup at boot time and restart log identically (and it does log the RFC 1918 empty zones warning so it gets that far). I’m guessing there’s some resource not available at boot time that’s causing named to hang but that really just a will guess. I remember fixing this problem way back when Apple first switched to launchd (10.4 or so). Basically, Apple patches (or used to patch) named to make it register with the system to be told when a network interface is added. Their patch allowed named to start up before the network is up, and then essentially get a SIGHUP or something like it every time a network interface comes up or goes down. The problem is that launchd starts named before the network is up. The solution is to have it wait a few seconds before starting. The way we did it back then was to have launchd start a script instead of starting named directly. The script would simply sleep 3 seconds (or something like that) before starting named. It would then stay open. Thanks Chris. As I mentioned in a follow-up, I did reach that conclusion after finding it was responsive on 127.0.0.1 but not on the machine’s external address. And I have worked around it in exactly the way you mention except I have the sleep at 30 seconds (I tried 15 and it was too short - but that machine is slow; OTOH, I tested on my new MBP with an SSD system disk and it boots so fast that named seems to come up OK. For my needs, the script delay as a work-around is “good enough”. I’d bet that the package from Men Mice includes this script or an equivalent workaround. When I wrote the original script I wrote about above, I worked at Men Mice. The problem I have with it is there’s no documentation I can find. If they have patched it, I’d like to know about. One reason I’ve moved away from Apple provided versions (besides them suddenly removing it) and am now going with all “built from source” for my server software is Apple’s tendency to make undocumented changes to open source software. It’s been a problem in the support environments of some other software I use (not that this issue is unique to Apple). I used a package inspector to look at the Men Mice package and there’s no launchd plist in there so it’s not clear to me how they get it started. But inspecting packages is new to me so there may be other things I’m not seeing. In any event, as I said, I have a “good enough” solution for my needs so anything further on this will be mostly of intellectual interest. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature ___ 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: Non-responsive name servers when started during boot on OS X Mavericks 10.9
That is not the problem. Named does start at boot but it is non-responsive (with further thought, perhaps it is for some reason not listening on port 53). When killed and restarted, it then works fine. I am not familiar with macshadows.com but those directions are incomplete and and assume the existence of files that may not exist. The first command listed, launchctl load -w /System/Library/LaunchDaemons/org.isc.named.plist, loads org.isc.named.plist and with the -w, marks it “enabled” and to be loaded and started at boot time. It does not create org.isc.named.plist. The second line merely appends that command to /etc/launchd.conf but that is unneeded as anything in /System/Library/LaunchDeamons and /Library/LaunchDeamons that has been marked “enabled” with a previous load -w will start at boot. By default, there is no /etc/launchd.conf (I do not have or need one). BTW, /System/Library/LaunchDaemons is reserved for Apple provided launch daemons. User provided ones belong in /Library/LaunchDaemons. When Apple was providing BIND in version prior to 10.9, /System/Library/LaunchDaemons was the proper place for org.isc.named.plist but now that it’s user provided, it belongs in /Library/LaunchDaemons/. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ On Jan 17, 2014, at 11:10 PM, Eduardo Bonsi beart...@pacbell.net wrote: Hello Larry, I had the same head-ache when I upgraded to 10.9. It seems that instead going forward we all took a step behind. I guess this type of free stuff does come with something attached to it. Anyways, when you upgraded to 10.9 the boot files were wipe clean from the /System/Library/LaunchDaemons/ Open the terminal and restore it by entering the comand! --- launchctl load -w /System/Library/LaunchDaemons/org.isc.named.plist echo launchctl start org.isc.named /etc/launchd.conf --- Then re-start BIND --- launchctl start org.isc.named --- There are several places talking about this stuff but you can verify here: Configure BIND to Launch at Startup http://www.macshadows.com/kb/index.php?title=How_To:_Enable_BIND_-_Mac_OS_X's_Built-in_DNS_Server I hope that helps! -- Eduardo Bonsi System Admin BEARTCOMMUNICATIONS beart...@pacbell.net From: Larry Stone lston...@stonejongleux.com To: bind-users@lists.isc.org Sent: Friday, January 17, 2014 6:45 PM Subject: Non-responsive name servers when started during boot on OS X Mavericks 10.9 Background: I have been using my Macintosh as a server running the client version of OS X (not OS X Server) for many years. Until 10.9 (Mavericks), Apple provided BIND and it worked just fine. My servers were internal only providing behind-NAT local addresses for the local network as well as caching for external names. All went well. With the release of 10.9, BIND was no longer provided (I’m currently on 10.9.1). I initially restored the version of named from 10.8 along with my configuration and zone files and all was well (at least as far as I could tell). I then switched to building from source and all was still well (I thought). The primary server was just upgraded to 9.8.6-P2 while the secondary (not a server except as a redundant name server) is still at 9.8.6-P1 (upgrade planned for this weekend). Problem: This morning, by happenstance, both were rebooted a few minutes apart and suddenly, nobody could access anything. Finally figured out that named on both was not responding (queries timed out). Killed named (which was immediately restarted by Apple’s launchd) and all was well. Rebooted the secondary to see if it was repeatable and same thing. Nothing of interest in the log - both the initial startup at boot time and restart log identically (and it does log the RFC 1918 empty zones warning so it gets that far). I’m guessing there’s some resource not available at boot time that’s causing named to hang but that really just a will guess. I know I’m not providing much information but there’s nothing else I can find so any help with just figuring out why it fails when started at boot time will be a help. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users
Non-responsive name servers when started during boot on OS X Mavericks 10.9
Background: I have been using my Macintosh as a server running the client version of OS X (not OS X Server) for many years. Until 10.9 (Mavericks), Apple provided BIND and it worked just fine. My servers were internal only providing behind-NAT local addresses for the local network as well as caching for external names. All went well. With the release of 10.9, BIND was no longer provided (I’m currently on 10.9.1). I initially restored the version of named from 10.8 along with my configuration and zone files and all was well (at least as far as I could tell). I then switched to building from source and all was still well (I thought). The primary server was just upgraded to 9.8.6-P2 while the secondary (not a server except as a redundant name server) is still at 9.8.6-P1 (upgrade planned for this weekend). Problem: This morning, by happenstance, both were rebooted a few minutes apart and suddenly, nobody could access anything. Finally figured out that named on both was not responding (queries timed out). Killed named (which was immediately restarted by Apple’s launchd) and all was well. Rebooted the secondary to see if it was repeatable and same thing. Nothing of interest in the log - both the initial startup at boot time and restart log identically (and it does log the RFC 1918 empty zones warning so it gets that far). I’m guessing there’s some resource not available at boot time that’s causing named to hang but that really just a will guess. I know I’m not providing much information but there’s nothing else I can find so any help with just figuring out why it fails when started at boot time will be a help. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ smime.p7s Description: S/MIME cryptographic signature ___ 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
