Re: can't see nameserver externally

[Larry]

Davenport, Steve M wrote:

Hello,
 
I noticed that one of our nameservers is no longer responding with the 
correct address externally. The server is  ns-2.hosp.utmck.edu and is 
listed as a server in the registration record for utmck.edu. The address 
should be 165.6.6.27 but a dig/nslookup from an external site returns 
165.6.144.1. We do not have 165.6.144.1 in any of the zone files, but 
this address is the external address of a broadband service manager in 
our network. Using dig/nslookup on the local network verifies that 
165.6.144.1 is not in the zone files or cache of our nameservers. The 
name and address of our ns-2 resolve correctly internally. Can someone 
please tell me how to identify and correct this problem.


Have you checked the IP registered for the NS?



ns-2.hosp.utmck.edu.172800  IN  A   165.6.144.1
utmck.edu.  172800  IN  NS  harley.mc.utmck.edu.
utmck.edu.  172800  IN  NS  ns-2.hosp.utmck.edu.
;; Received 123 bytes from 192.31.80.30#53(D.GTLD-SERVERS.NET) in 27 ms




dig -tA ns-2.hosp.utmck.edu +trace

; <<>> DiG 9.2.4 <<>> -tA ns-2.hosp.utmck.edu +trace
;; global options:  printcmd
.   444765  IN  NS  F.ROOT-SERVERS.NET.
.   444765  IN  NS  G.ROOT-SERVERS.NET.
.   444765  IN  NS  H.ROOT-SERVERS.NET.
.   444765  IN  NS  I.ROOT-SERVERS.NET.
.   444765  IN  NS  J.ROOT-SERVERS.NET.
.   444765  IN  NS  K.ROOT-SERVERS.NET.
.   444765  IN  NS  L.ROOT-SERVERS.NET.
.   444765  IN  NS  M.ROOT-SERVERS.NET.
.   444765  IN  NS  A.ROOT-SERVERS.NET.
.   444765  IN  NS  B.ROOT-SERVERS.NET.
.   444765  IN  NS  C.ROOT-SERVERS.NET.
.   444765  IN  NS  D.ROOT-SERVERS.NET.
.   444765  IN  NS  E.ROOT-SERVERS.NET.
;; Received 500 bytes from 67.19.0.10#53(67.19.0.10) in 1 ms

edu.172800  IN  NS  D.GTLD-SERVERS.NET.
edu.172800  IN  NS  L.GTLD-SERVERS.NET.
edu.172800  IN  NS  G.GTLD-SERVERS.NET.
edu.172800  IN  NS  F.GTLD-SERVERS.NET.
edu.172800  IN  NS  A.GTLD-SERVERS.NET.
edu.172800  IN  NS  C.GTLD-SERVERS.NET.
edu.172800  IN  NS  E.GTLD-SERVERS.NET.
;; Received 305 bytes from 192.5.5.241#53(F.ROOT-SERVERS.NET) in 48 ms

ns-2.hosp.utmck.edu.172800  IN  A   165.6.144.1
utmck.edu.  172800  IN  NS  harley.mc.utmck.edu.
utmck.edu.  172800  IN  NS  ns-2.hosp.utmck.edu.
;; Received 123 bytes from 192.31.80.30#53(D.GTLD-SERVERS.NET) in 27 ms
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: How to forward domain totally not using CNAME?

[Larry]

MontyRee wrote:
>  
> Hello, all.
>  
>  
> I would like to CNAME like below.
>  
> example.com.  IN CNAMEexample2.com.
>  
>  
> But I know that this is wrong. 
> then, is there any way or solution to solve this problem?
>  
>  
> I searched and found that below is a similar solution.
>  
>  
> * IN CNAMEexample2.com.
>  
> but in this case, only .example.com works well
> and example.com doesn't work well.
>  
>  
> Any comment?
>  
>  
> Thanks in advance.


use

example.com.  IN DNAMEexample2.com.


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: How See what is Cached?

[Larry]

Agarwal Vivek-RNGB36 wrote:

Hi All

Iam trying to run the same command on Red Hat Linux; but its not giving any output. 
How can I check the cache in the redhat linux


Regards
Vivek Aggarwal
+973-36583058 





It would help if you said which version of Bind you were using.



smime.p7s
Description: S/MIME Cryptographic Signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: loading zone: creating database: out of memory

[Larry]

万善义 wrote:
> CentOS release 5.4 (Final)  + BIND 9.6.1-P1
>  
> Intel(R) Xeon(R) CPU   E5506  @ 2.13GHz
> 8G Memory
>  
>  
> Load 500,000 domains, the loading process, the following error:
>  
> loading zone: creating database: out of memory
>  
> 2009-11-24
> 
> 万善义
> 
> 

Is there a question somewhere?

Also, whats with the bold HTML? this is E-Mail, not http






smime.p7s
Description: S/MIME Cryptographic Signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: new here

[Larry Brower]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 04/22/2012 10:05 PM, David Milholen wrote:
> listen-on {
> 9x.1xx.104.14;
> };

Perhaps add 127.0.0.1; into the listen on clause.



- -- 


Larry Brower, CCENT

Fedora Ambassador - North America
Fedora Quality Assurance
lbro...@fedoraproject.org
http://www.fedoraproject.org/
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJPlMp9AAoJEF1Xw4ZWTEoJMLgP/1yJ09F4QdPQqlq8yXl9MPDs
u8f7pwzgZxipsVGD3fiuV6FAhGh/D3AXMMkZIGqiXXBTb9WNBOnVi4pji+5pee2T
7bgEWBdBtS18jmvJTGi5Uu55BjhX8eSgLNKIRhUuWtJENL6cFl8QM14Qpzzu8eDz
oCAZmRgZ89qxqjQbwleB2ihiHvkdFbeC1AsKQg0IGxgVtrUofsBSVnRP1yVSx+de
dM92Jrhc+yY/A7TpiQsUmfOIljd3JNipfSmhFe/d+pe9a1umO1WQ7I4Fufg3AdIJ
jdlV3dvk0JuZegg4OM2jBmAMVtcJxXiLB4+QW3WGk/3prVYX1z3OawFIknszAnCD
xEB6AZA0dp0nMC3HBh+1RGpFkhc5oZdo6nhvu/BDuV5yI9lKJSAV4AzRd7MPFgEL
RTAeF5FIVPPJuvhgAeOHAsOxip2d5PLF18HvTIPaExx/EuRRGsXic36LJRyYkhUt
roatThoRBHsE6XgDc+CQJyC+Ac32pHBiJ6Y4lOIFYEbWTDjxbcD3Jszj3SaQbUCZ
jc+mzA8E9dLEv4kTtdbXPgnrWLBjeh24P/ZZBm26nvY2S5fZcrmnXsJBVuGB2FqL
di1wyz0xmqvilg3FwNNke9wt6lCRKvpycwUos3RiqadDGYCClMm3VySE4tdSWq/F
NgECeg/P6VrazDxYkHno
=zXKb
-END PGP 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: Convice Bind to listen on IP alias with a range of IPs.

[Larry Brower]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 04/30/2012 04:56 PM, Augie Schwer wrote:
> I must be doing something wrong, because what I want to do doesn't
> seem that difficult.
> 
> I have a range of IPs bound to a local interface:
> 
> lo:1  Link encap:Local Loopback
>   inet addr:10.0.0.1  Mask:255.255.255.224
> 
> And I want to convince Bind to listen on sub-set of the given range (
> 10.0.0.2 for example ), yet when I configure that IP:
> 
>   listen-on { 10.0.0.2; };
> 
> Bind won't listen on that interface:
> 
> "named[15035]: not listening on any interfaces"
> 

is 10.0.0.2 bound to the server?

can you show the ip address or ifconfig output ?




- -- 


Larry Brower, CCNA

Fedora Ambassador - North America
Fedora Quality Assurance
lbro...@fedoraproject.org
http://www.fedoraproject.org/
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJPnyJPAAoJEF1Xw4ZWTEoJzecP/j6745eQs5TWT8+9p4k7L92p
UF5pM65GSynCmh2KZk0VGLYuYCJNWGywsQU6S3CnsNAWE+a9TaL3I7ViKIrpRjId
0pp/4P4o8Jxi8/fkgG+wXnceOHsSklCKTV883ppKCwl1RJJfncNJQN1+p/bUhBgA
53rMNk0pzr6wAllS3LcqrbGoe3hBJj5hbI/snqw67zjvU4PsfgBi+SjYI0+j9paN
edv2VhmN3qQvpJyQW2lMEVwxOLNAa4coClRYaqiOCz35Tg+ZykBVMU5W2jaByS6e
qb2KX+Q+eOd6S6IQDT8C122yeHv9nik4Pl1LB6Om3hUEhoAr56BCSWbmPkIy72uC
LtQkqWhtqU4706Bzq2Yf5SFpAJQI63ef1Bypm2N91gRhggFBkCcSWnzDXig/cVh+
XGDcXGzSnRCrpHz1uiKNO6rSmDPmd/eugTMGHNa/VTbqepIwIUhu1lLP9AswHWSa
3C3oqncA3CJO6+STryYtyLMtSx6BMtMgaDBJoDCJ1TZ9zAa9nFQlF1hybhsMstEP
sgttF17hbgksoOXc0L7Lj1OMTvoClKwosfaEpzyfPJNwZhthG8a37SdNswf/PifF
dHlxUniVLOyg4uj6jplzkD2GLFd5ZMwg74fISORh6guOQjNext+Vs/pZt5IvGmie
Wi++mDbkUPhq6/9ZwGec
=G6Ta
-END PGP 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: Convice Bind to listen on IP alias with a range of IPs.

[Larry Brower]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 04/30/2012 06:14 PM, Augie Schwer wrote:
> I think you've all missed the netmask there, 10.0.0.2 is in that range.
> 
> augie@augnix:~$ sudo ifconfig lo:1 10.0.0.1 netmask 255.255.255.224
> 
> augie@augnix:~$ ifconfig lo:1
> lo:1  Link encap:Local Loopback
>   inet addr:10.0.0.1  Mask:255.255.255.224
> 

This is only showing the IP 10.0.0.1/27 which is a single IP on the box.
You dont get a range of IP's by using a specific mask on the interface.


> augie@augnix:~$ ping 10.0.0.2 -c 1
> PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
> 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.027 ms
> 
> --- 10.0.0.2 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> 

You have 10.0.0.2 bound to a system somewhere which is nice but has
nothing to do with lo:1

> Given all that, can anyone suggest a reason why Bind won't listen on
> that address?


Because you are doing it wrong.

You need to actually have the IP bound to an interface on the server for
it to work.



- -- 


Larry Brower, CCNA
Linux System Administrator II
HostGator.com LLC

lbro...@hostgator.com
Http://www.hostgator.com
Http://support.hostgator.com/

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJPn0vfAAoJEF1Xw4ZWTEoJsKoQAK6OfTyORlqJnRYTdKFIQJue
Jsh4ZgQlqGGNU7gqlqEbKWsJ7nn7rawWxZMM/XGoW7FBIjgZaO9fComu4kNS5iEi
oxal2B9ruKaIc2lG/ZoJzXkfpSmoEsXQ6DOUFlXwkyrPySdZ9qSLs61GVZL/OCUq
h42xlLQL8qF4pkrYUVwElclEs6vcRQY52DiPUuDz6hjtdOflTytpD9gkpXfPEgje
SHFM+Lgdi82fLfBwtJkqCkztQ17+XQR1P3Xg4XK4B1TNyilCZO4UKs+7NpBVLHA7
iLySYWQokz+ZLhRrELkDWekGbF8fvSOug3ObsdqRseLTdevqkyNYEPw70DHzR8a1
/HxFIyknxTFsY/37W4BuT02h8+hNGOJUN2VWEc3E78Cf2Qdip2oUrleLppy8+g1J
d7j/FH8KB7S2e/zJV/jMwT3DykUWzZEG5H/rVVxl3mwlp54+Od71pxh6WBHQU5I1
P14joF/9qKpO4ghwlDIbZ9OoYxAP78IQm6qbx1syty2HOHy2Rs0qlgflIvydjE1f
LSLJWezdmwPtgC/onD6X++JP3+vTW1TGC4agSx6oxasaJqjuZrWm9vJ9dmca2pR/
CPdDSMavRynySCHRKoGiO34ZgzGDAmu+UoU2H00NMJH7Z54eIzBAyHURPO+tJ3KD
LG/KR7ew2ayX36i5lcNk
=UzLF
-END PGP 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: Convice Bind to listen on IP alias with a range of IPs.

[Larry Brower]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 04/30/2012 07:13 PM, Augie Schwer wrote:
> Thanks for the reply, please see my previous e-mail about the address
> being perfectly pingable on that interface.
> 

Whats that have to do with anything? It being pingable only means
something is responding for it. This does NOT mean it is on THAT
specific server. If it is not on THAT server then bind cant use it.

This isn't rocket science :)


- -- 


Larry Brower, CCNA
Linux System Administrator II
HostGator.com LLC

lbro...@hostgator.com
Http://www.hostgator.com
Http://support.hostgator.com/

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJPn15TAAoJEF1Xw4ZWTEoJlK0P/0wCGKtzfFr7jCrxq2YQlZbj
2DBwCO9gjZWHnHr35DQ/iYz7U+gU9rzKvXMdDWNKsr8zXoqiyMgt0N1Yp+llHQdj
zgGOIlEuqIcL77hGBNQ7zlrutfiPaUuIG/vZe8mLX31M8yDOG2fa38cGtSNKILZL
aSejkv5u+4QfRBhWGqtWtcUwslWdBc3TLoxKoI2YidPALjtkGXsPF/qYoke80b+Y
0YPxZ/lyS85KovK9ZgG3dCXl35r0hyLTbHBeD9JTUw6g28CKPq8HX5nKdo1hTYQv
+Wdb5cIQGIovVF1QZcXkdGWnhIh9AkGXQ3J4RasCUPi6TuKTlWNhlQjYiYWAl5BB
WmvPGSm3gczEJS2VGkTeJbDMKSfmNzRruzObBbVBhUr4rp/xCuJITfltne5PEmaJ
3acBm1fHi1SGifueJeK9LdFPDW27Xog2+1FDbdJFrTGO1qjwGfrEyJ9FFtk9ve2U
FZWvyOdomoKapAtI4sxbKG54LTmgAazXflRa4CowEA8EhykX2qGgFhv3rKy3Y9Gf
hXnNlVJUIOif9kotAem50MsgTLmMpHkOOcb6ADNDMZ91hxRvJrZ/Eb7E4UtU/g+S
UDlb28WT5Cu8okrhqS1uiVjvl4dhnr0ZIz6AZMgMgKTOUw0vihvDgIZ6Ve6Ws+HB
PLdxKpjwi6pt6RvHk+al
=+qgi
-END PGP 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

Non-responsive name servers when started during boot on OS X Mavericks 10.9

[Larry Stone]

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

Re: Non-responsive name servers when started during boot on OS X Mavericks 10.9

[Larry Stone]

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  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 
> 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 unsub

Re: Non-responsive name servers when started during boot on OS X Mavericks 10.9

[Larry Stone]

Eduardo -

You’re not really reading what the problem is. When named is started as part of 
system boot, it is running but non-responsive. When started any time later, it 
works fine.

BIND version is latest and greatest 9.8.6 download from ISC just a few days ago 
- BIND 9.8.6-P2 (have not looked at 9.9 yet). It is not outdated. Secondary was 
updated to 9.8.6-P2 tray as part of testing.

Unfortunately, it sounds like you’re just throwing out how-to’s from various 
sources without any real understanding of what the problem is. 

Update: Further testing shows that when first launched, named is listening on 
127.0.0.1 but not the external address. Restarting it lets it listen on both. 
My guess is that launchd is starting it before the external TCP/IP address is 
set up. Unfortunately, launchd, as far as I know, does not let you establish 
dependencies. Interim solution is to have the launchd plist run a script that 
does a sleep 30 before starting named (15 seconds was too short). There might 
be a way to use a Listeners clause in the launchd list but that syntax is 
currently beyond me. I will search in Mac OS X forums for that.

-- 
Larry Stone
lston...@stonejongleux.com
http://www.stonejongleux.com/

On Jan 18, 2014, at 1:03 PM, Eduardo Bonsi  wrote:

> It is possible then that when you copied the BIND files back to 10.9, 
> something got broken along the way? I am suspecting that is your BIND package 
> itself! Forget about your actual BIND package, it is outdated!
> 
> 1. Go to support.menandmice.com
> 
> (http://support.menandmice.com/download/bind/macosx/10.9-Mavericks/)
> 
> and download the last package of Bind for Mavericks! Thanks to them for 
> keeping up in areas where Apple is dropping the ball. I believe yours is
> ISCBIND-9.9.4-x86_64-10.9.zip  25-Oct-2013 20:15  
>   18492934
> 
> In case you do not use Bind with the (RRL) Responsible Rate Limit. 
> 
> If you decided for instance to use BIND with RRL you have to download this 
> package,
> ISCBIND-9.9.4r-x86_64-10.9.zip 25-Oct-2013 20:15  
>   18641078
> ...and add these line at your named.conf file,
> 
> rate-limit {
>responses-per-second 5;
>log-only yes;
>};
> 
> Some more info about RRL can be found here,
> https://www.isc.org/blogs/bind-9-9-4-released/
> 
> 2. Make sure you have your rndc.key configuration setup accordingly. 
> nano /etc/rndc.key
> 
> Double check your name.conf file for the 
> dnssec-lookaside . trust-anchor dlv.isc.org.;
> 
> 3. Then,
> dscacheutil -flushcache
> 
> To re-start!
> 
> 
> 
> 
> 
>  
> --
> Eduardo Bonsi
> System/Network Admin
> BEARTCOMMUNICATIONS
> beart...@pacbell.net
> 
> From: Larry Stone 
> To: "bind-users@lists.isc.org"  
> Sent: Saturday, January 18, 2014 5:52 AM
> Subject: 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  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 /Sy

Re: Non-responsive name servers when started during boot on OS X Mavericks 10.9

[Larry Stone]

On Jan 20, 2014, at 1:22 PM, Chris Buxton  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

[Larry Stone]

On Jan 21, 2014, at 5:32 AM, Carsten Strotmann  wrote:

> Hi Chris,
> 
> Chris Buxton  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

[Larry Stone]

On Jan 21, 2014, at 11:38 PM, LuKreme  wrote:

> 
> On 18 Jan 2014, at 06:52 , Larry Stone  wrote:
> 
>> That is not the problem. 
> 
> In the launchd plist do you have something like
> 
> 
>  NetworkState
>  
> 
> 
> or maybe
> 
> inetdCompatibility
> 
>  Wait
>  
> 
> 
> 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.


http://www.apple.com/DTDs/PropertyList-1.0.dtd";>


Disabled

EnableTransactions

Label
org.isc.named
OnDemand

ProgramArguments

/usr/local/sbin/named
-f
-c
/usr/local/etc/named.conf

ServiceIPC




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

[Larry Stone]

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

[Larry Stone]

On Jan 21, 2014, at 11:38 PM, LuKreme  wrote:

> 
> In the launchd plist do you have something like
> 

I finally got around to testing both of these.

> 
>  NetworkState
>  
> 
> 

Had no effect.

> or maybe
> 
> inetdCompatibility
> 
>  Wait
>  
> 
> 

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

[Larry Stone]

On Jan 22, 2014, at 12:27 PM, 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).
> 

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

[Larry Stone]

On Jan 21, 2014, at 5:32 AM, Carsten Strotmann  wrote:

> Hi Chris,
> 
> Chris Buxton  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

Compile error Bind 9.16.1 on MacOS 10.14.6

[Larry Stone]

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, &ts) == -1) {
   ^
time.c:117:20: error: use of undeclared identifier 'CLOCK_REALTIME'
   if (clock_gettime(CLOCKSOURCE, &ts) == -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, &ts) == -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: Compile error Bind 9.16.1 on MacOS 10.14.6

[Larry Stone]

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, &ts) == -1) {
>>  ^
>> time.c:117:20: error: use of undeclared identifier 'CLOCK_REALTIME'
>>  if (clock_gettime(CLOCKSOURCE, &ts) == -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, &ts) == -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

Re: Compile error Bind 9.16.1 on MacOS 10.14.6

[Larry Stone]

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, &ts) == -1) {
>>>>^
>>>> time.c:117:20: error: use of undeclared identifier 'CLOCK_REALTIME'
>>>>if (clock_gettime(CLOCKSOURCE, &ts) == -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, &ts) == -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
>

Re: A And Cname-record

[Larry Stone]

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: BIND 9.16.13 and Mac OS X 10.13.6 - problems with ./configure

[Larry Stone]

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: BIND 9.16.13 and Mac OS X 10.13.6 - problems with ./configure

[Larry Stone]

> 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

dnssec: ds showing hidden 3+ days after key roll

[Larry Rosenman]

Greetings,
new poster.  I just converted over to DNSSEC-policy,  and rolled my 
KSK.  I see:

key: 269 (RSASHA256), KSK
  published:  yes - since Sun Feb  6 14:31:32 2022
  key signing:yes - since Sun Feb  6 14:31:32 2022

  No rollover scheduled
  - goal:   omnipresent
  - dnskey: omnipresent
  - ds: hidden
  - key rrsig:  omnipresent


ler in thebighonker in namedb🔒 on  master [!] as 🧙
❯

Is it normal to see the ds as hidden?  It IS published, and I told rndc 
that.


Any insight appreciated.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--
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: dnssec: ds showing hidden 3+ days after key roll

[Larry Rosenman]

-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: can we 
transition ZSK lerctr.org/RSASHA256/34851 type ZRRSIG state UNRETENTIVE 
to state HIDDEN?
<183>1 2022-02-09T02:18:28.588225-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: dnssec 
evaluation of ZSK lerctr.org/RSASHA256/34851 record ZRRSIG: 
rule1=(~false or false) rule2=(~true or true) rule3=(~true or true)
<183>1 2022-02-09T02:18:28.588244-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: time says no 
to ZSK lerctr.org/RSASHA256/34851 type ZRRSIG state UNRETENTIVE to state 
HIDDEN (wait 592212 seconds)
<183>1 2022-02-09T02:18:28.588256-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: examine KSK 
lerctr.org/RSASHA256/20014 type DNSKEY in state HIDDEN
<183>1 2022-02-09T02:18:28.588266-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: KSK 
lerctr.org/RSASHA256/20014 type DNSKEY in stable state HIDDEN
<183>1 2022-02-09T02:18:28.588276-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: examine KSK 
lerctr.org/RSASHA256/20014 type KRRSIG in state HIDDEN
<183>1 2022-02-09T02:18:28.588286-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: KSK 
lerctr.org/RSASHA256/20014 type KRRSIG in stable state HIDDEN
<183>1 2022-02-09T02:18:28.588296-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: examine KSK 
lerctr.org/RSASHA256/20014 type DS in state HIDDEN
<183>1 2022-02-09T02:18:28.588306-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: KSK 
lerctr.org/RSASHA256/20014 type DS in stable state HIDDEN
<183>1 2022-02-09T02:18:28.588317-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: examine ZSK 
lerctr.org/ECDSAP256SHA256/6539 type DNSKEY in state OMNIPRESENT
<183>1 2022-02-09T02:18:28.588328-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: ZSK 
lerctr.org/ECDSAP256SHA256/6539 type DNSKEY in stable state OMNIPRESENT
<183>1 2022-02-09T02:18:28.588338-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: examine ZSK 
lerctr.org/ECDSAP256SHA256/6539 type ZRRSIG in state OMNIPRESENT
<183>1 2022-02-09T02:18:28.588348-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: ZSK 
lerctr.org/ECDSAP256SHA256/6539 type ZRRSIG in stable state OMNIPRESENT
<183>1 2022-02-09T02:18:28.588359-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: examine KSK 
lerctr.org/RSASHA256/269 type DNSKEY in state OMNIPRESENT
<183>1 2022-02-09T02:18:28.588369-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: KSK 
lerctr.org/RSASHA256/269 type DNSKEY in stable state OMNIPRESENT
<183>1 2022-02-09T02:18:28.588379-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: examine KSK 
lerctr.org/RSASHA256/269 type KRRSIG in state OMNIPRESENT
<183>1 2022-02-09T02:18:28.588389-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: KSK 
lerctr.org/RSASHA256/269 type KRRSIG in stable state OMNIPRESENT
<183>1 2022-02-09T02:18:28.588399-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: examine KSK 
lerctr.org/RSASHA256/269 type DS in state HIDDEN
<183>1 2022-02-09T02:18:28.588410-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: can we 
transition KSK lerctr.org/RSASHA256/269 type DS state HIDDEN to state 
RUMOURED?
<183>1 2022-02-09T02:18:28.588432-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: dnssec 
evaluation of KSK lerctr.org/RSASHA256/269 record DS: rule1=(~false or 
true) rule2=(~true or true) rule3=(~true or false)
<183>1 2022-02-09T02:18:28.588453-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: dnssec says 
no to KSK lerctr.org/RSASHA256/269 type DS state HIDDEN to state 
RUMOURED


ler in thebighonker in ~ via ☕ v1.8.0 via 🐪 v5.32.1 via 💎 v2.7.5 as 🧙
❯

On 02/10/2022 6:20 am, Matthijs Mekking wrote:

Hi Larry,

There has been several bug fixes for dnssec-policy since its
introduction. What version of 9.17 are you running?

I can't tell what causes the ds to stay in the hidden state. The
timings in the state file should allow it to move to the next state.

If you were able to turn on logging, on each run the keymgr will tell
you the reason why it cannot move the D

BIND 9.18.0 and Mac OS X 10.15.7 - cannot build

[Larry Stone]

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.18.0 and Mac OS X 10.15.7 - cannot build

[Larry Stone]

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

Re: BIND 9.18.0 and Mac OS X 10.15.7 - cannot build

[Larry Stone]

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_CO

Re: BIND 9.18.0 and Mac OS X 10.15.7 - cannot build

[Larry Stone]

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

Why does DNSVIZ complain about the NS RRSET here?

[Larry Rosenman]

00IN RRSIG NSEC3 13 19 3600 20220429102734 20220415092810 3046 
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
M5iCnOTqQfxGbBzQMMp185MybaFn+TPM6/cvXftntBP2lxoCqBa+D0JF 
ukevEF45bwa/lM5b6MnxpmtGxo6G2A==

; resign=20220429102734
V19VIJ6AAN1D64QDIEF79283KDEIVANC.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
3600IN NSEC3 1 0 0 - VESHMAE8A0EHNCU2LUKO219Q45DC3AMN PTR RRSIG
V19VIJ6AAN1D64QDIEF79283KDEIVANC.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
3600IN RRSIG NSEC3 13 19 3600 20220425145843 20220411144736 3046 
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
Sp484ke6qCXwnIQkFcfKjT0/XH0hS/VXxUMtU2R3z45+LMHpk2x9RR43 
stiySqTONSgkcfKI4EPZcxUA7CFOYg==

; resign=20220425145843
VESHMAE8A0EHNCU2LUKO219Q45DC3AMN.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
3600IN NSEC3 1 0 0 - VN8PV32TE8HA3D86M3EKHIMUIT7CRSOD
VESHMAE8A0EHNCU2LUKO219Q45DC3AMN.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
3600IN RRSIG NSEC3 13 19 3600 20220429234033 20220415233042 3046 
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
bk0r3k3klZhxaoJ5wZJ2ZDITSmWhIArssryIv0vcvFnXcNgshzeyEoVP 
MOcYcib+b0Hs1pi3Nwf2IELGqgQRfw==

; resign=20220429234033
VN8PV32TE8HA3D86M3EKHIMUIT7CRSOD.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
3600IN NSEC3 1 0 0 - VQPETA4DEIURD31CGOS6P364LS8EMT6H
VN8PV32TE8HA3D86M3EKHIMUIT7CRSOD.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
3600IN RRSIG NSEC3 13 19 3600 20220429234033 20220415233042 3046 
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
WIaDu6Ry3pTZe7+3sUAwwIb1BgeQ6syrhoz3/WDnU918MPX7lbhemwTh 
EdiWq5oYsSZXFvPWd8XB7LYqyemVPA==

; resign=20220429234033
VQPETA4DEIURD31CGOS6P364LS8EMT6H.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
3600IN NSEC3 1 0 0 - 0ISU75L6B23R9E1ONBHID7HSRK6Q8QT6 PTR RRSIG
VQPETA4DEIURD31CGOS6P364LS8EMT6H.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
3600IN RRSIG NSEC3 13 19 3600 2022043121 20220415233042 3046 
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
eJpspM18ueeLh67CqrWrhAb32SamzaNdJMFUb21Owk+kpHS5C1qX4Bav 
u523WA+JqrVanEuewjGMDyk+UxgeTQ==

; resign=2022043121

and dig only shows my RRSet:
❯ dig 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa +dnssec +nocrypto ns 
@1.0.0.1

zsh: correct 'ns' to 'nws' [nyae]? n

; <<>> DiG 9.16.27 <<>> 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa +dnssec 
+nocrypto ns @1.0.0.1

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54238
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. IN NS

;; ANSWER SECTION:
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN NS 
ns1.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN NS 
ns2.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN NS 
ns3.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN NS 
ns4.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN NS 
ns5.dnsunlimited.com.

0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN NS ns-a.lerctr.org.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN NS ns-b.lerctr.org.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN NS ns-c.lerctr.org.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN RRSIG	NS 13 18 3600 
20220427104028 20220413100533 3046 
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. [omitted]


;; Query time: 676 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Sat Apr 16 09:52:06 CDT 2022
;; MSG SIZE  rcvd: 414


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--
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: Why does DNSVIZ complain about the NS RRSET here?

[Larry Rosenman]

Do you know what a windows DNS admin needs to do to fix that?


On 04/18/2022 5:12 pm, Mark Andrews wrote:

The parent servers are configured to allow recursion (ra) and rather
than returning referrals that are returning
answers provided it is cached.

Also it is pointless to use NSEC3 in the reverse trees as they contain
too much structure.

To find
4.b.3.2.b.1.e.f.f.f.5.b.3.e.a.7.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa.
3600 IN PTR thebighonker.lerctr.org you
just need to query for [0-9a-f].ip6.arpa which will elicit a non
NXDOMAIN for 2.ip6.arpa. Then you query for [0-9a-f].2.ip6.arpa, all
the way down to
[0-9a-f].b.3.2.b.1.e.f.f.f.5.b.3.e.a.7.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa.
which gives you a non NXDOMAIN response for
4.b.3.2.b.1.e.f.f.f.5.b.3.e.a.7.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa.


% dig @pdns05.thin-nology.com ns 
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa +norec


; <<>> DiG 9.17.22 <<>> @pdns05.thin-nology.com ns
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa +norec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13592
;; flags: qr ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. IN NS

;; ANSWER SECTION:
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns1.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns2.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-a.lerctr.org.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns4.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns3.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns5.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-b.lerctr.org.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-c.lerctr.org.

;; Query time: 225 msec
;; SERVER: 216.82.192.148#53(pdns05.thin-nology.com) (UDP)
;; WHEN: Tue Apr 19 07:53:04 AEST 2022
;; MSG SIZE  rcvd: 242

%

% dig @pdns06.thin-nology.com type1000
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa +norec +dnssec

; <<>> DiG 9.17.22 <<>> @pdns06.thin-nology.com type1000
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa +norec +dnssec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11871
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 10, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4000
;; QUESTION SECTION:
;0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. IN TYPE1000

;; AUTHORITY SECTION:
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns3.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-c.lerctr.org.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-b.lerctr.org.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-a.lerctr.org.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns2.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns1.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns4.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns5.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN DS 63984 13 2
F9B8E3F0A1E15E38C32E71BA1D7150B7FB68CC8C06943B065C75C985 0732B48E
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN RRSIG DS 13 18 3600
20220423141314 20220416131314 1535 0.b.d.c.f.2.0.6.2.ip6.arpa.
2Bn8Qtoac1rIpL6IPvUP8EFewC0XLlxidGM6lIT8q12wmSUj3o3jxSxY
xQMsK+j/b9nuMPlir+3m+mR7g5nvVQ==

;; Query time: 217 msec
;; SERVER: 216.82.192.149#53(pdns06.thin-nology.com) (UDP)
;; WHEN: Tue Apr 19 07:55:29 AEST 2022
;; MSG SIZE  rcvd: 452

%



[snip]
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--
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: Reading secondary PTR files

[Larry Rosenman]

this is what I use with 9.18.1
named-compilezone -f raw -F text -o - 
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa 
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa.signed


On 04/20/2022 8:42 am, King, Harold Clyde (Hal) via bind-users wrote:

I  need to read the reverse zone in txt and I'm not sure how to decode 
the file with named-compilezone. Does anyone know the part I'm missing?
named-compilezone -f raw -F text -o 
/etc/named/secondary/9.249.192.in-addr.arpa.db 9.249.192 
/etc/named/secondary/9.249.192.in-addr.arpa.db


--

Hal King  - h...@utk.edu
Systems Administrator
Office of Information Technology
Shared Services

The University of Tennessee
103c5 Kingston Pike Building
2309 Kingston Pk. Knoxville, TN 37996
Phone: 974-1599


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106-- 
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: DNSSEC

[Larry Rosenman]

On 04/25/2022 8:31 am, The Doctor via bind-users wrote:

Any easy repices to get your domains DNSSEC compilant?
--
Member - Liberal International This is doctor@@nl2k.ab.ca Ici 
doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware 
AntiChrist rising!
Look at Psalms 14 and 53 on Atheism 
https://www.empire.kred/ROOTNK?t=94a1f39b

God will not fix the vessel which insists it isn't broken. -unknown
Beware https://mindspring.com


I'm just using the dnssec-policy stuff with 9.18, and manually add the 
DS records to my registrar
(Google in my case), and ARIN for my IPv4 block, and my provider for the 
delegated IPv6 block.


dnssec-policy "ler2" {
   keys {
   ksk lifetime unlimited algorithm 13;
   zsk lifetime 90d algorithm 13;
   };
   // Key timings
   dnskey-ttl 3600;
   publish-safety 1h;
   retire-safety 1h;
   purge-keys P90D;
   // Signature timings
   signatures-refresh 5d;
   signatures-validity 14d;
   signatures-validity-dnskey 14d;
   // Zone parameters
   max-zone-ttl 86400;
   zone-propagation-delay 300;
   // Parent parameters
   parent-ds-ttl 3600;
   parent-propagation-delay 300;
   nsec3param iterations 0 salt-length 0;
};

If I can help, let me know.



--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--
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

DNSSEC: Why aren't the old keys going hidden?

[Larry Rosenman]

I have 2 domains where I switched from Alg 8 to Alg 13, but the old keys 
don't seem to be going away.


Attached are the state files, and the rndc dnssec -status outputs.

Ideas?

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
dnssec-policy: ler2
current time:  Sun May  1 15:49:25 2022

key: 22146 (RSASHA256), ZSK
  published:  yes - since Sun Apr 10 13:59:22 2022
  zone signing:   yes - since Sun Apr 10 13:59:22 2022

  Rollover is due since Mon Apr 25 09:30:37 2022
  - goal:   hidden
  - dnskey: omnipresent
  - zone rrsig: omnipresent

key: 29251 (ECDSAP256SHA256), KSK
  published:  yes - since Sat Apr 16 21:41:31 2022
  key signing:yes - since Sat Apr 16 21:41:31 2022

  No rollover scheduled
  - goal:   omnipresent
  - dnskey: omnipresent
  - ds: omnipresent
  - key rrsig:  omnipresent

key: 17471 (RSASHA256), KSK
  published:  yes - since Sun Apr 10 13:59:22 2022
  key signing:yes - since Sun Apr 10 13:59:22 2022

  Rollover is due since Mon Apr 25 11:35:57 2022
  - goal:   hidden
  - dnskey: omnipresent
  - ds: unretentive
  - key rrsig:  omnipresent

key: 17274 (ECDSAP256SHA256), ZSK
  published:  yes - since Sat Apr 16 21:41:31 2022
  zone signing:   yes - since Sat Apr 16 21:41:31 2022

  Next rollover scheduled on Fri Jul 15 19:36:31 2022
  - goal:   omnipresent
  - dnskey: omnipresent
  - zone rrsig: omnipresent

dnssec-policy: ler2
current time:  Sun May  1 15:48:59 2022

key: 43159 (ECDSAP256SHA256), KSK
  published:  yes - since Sat Apr 16 21:41:31 2022
  key signing:yes - since Sat Apr 16 21:41:31 2022

  Rollover is due since Mon Apr 25 13:41:36 2022
  - goal:   hidden
  - dnskey: omnipresent
  - ds: unretentive
  - key rrsig:  omnipresent

key: 12796 (RSASHA256), KSK
  published:  yes - since Sun Apr 10 13:59:22 2022
  key signing:yes - since Sun Apr 10 13:59:22 2022

  Rollover is due since Mon Apr 25 11:36:50 2022
  - goal:   hidden
  - dnskey: omnipresent
  - ds: unretentive
  - key rrsig:  omnipresent

key: 39581 (ECDSAP256SHA256), KSK
  published:  yes - since Mon Apr 25 09:31:36 2022
  key signing:yes - since Mon Apr 25 09:31:36 2022

  No rollover scheduled
  - goal:   omnipresent
  - dnskey: omnipresent
  - ds: rumoured
  - key rrsig:  omnipresent

key: 5844 (RSASHA256), ZSK
  published:  yes - since Sun Apr 10 13:59:22 2022
  zone signing:   yes - since Sun Apr 10 13:59:22 2022

  Rollover is due since Wed Apr 27 10:54:16 2022
  - goal:   hidden
  - dnskey: omnipresent
  - zone rrsig: omnipresent

key: 3879 (ECDSAP256SHA256), ZSK
  published:  yes - since Sat Apr 16 21:41:31 2022
  zone signing:   yes - since Sat Apr 16 21:41:31 2022

  Next rollover scheduled on Fri Jul 15 19:36:31 2022
  - goal:   omnipresent
  - dnskey: omnipresent
  - zone rrsig: omnipresent



bind-keys-issue.tar.gz
Description: application/gzip
-- 
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: DNSSEC: Why aren't the old keys going hidden?

[Larry Rosenman]

On 05/01/2022 8:53 pm, Mark Andrews wrote:

Why should you want them to go away while you still have DS records
referencing them?

You also have a CDS record referencing a DNSKEY that dnssec-policy
doesn’t seem to know about.

sienawx.us. 2892IN  CDS 49366 8 2
60E3D64328B3D8929838FD1F2AB03CD5C8C72E3185C667B059E00157 D95F8CED

The DS records need to be removed before the DNSKEYs referencing them
go. Also does your registrar support CDS/CDNSKEY or do you need to
manually update the DS records?  Based on
https://support.google.com/domains/answer/6387342?hl=en&ref_topic=9018335
I’d say no


[SNIP]

Thanks, Mark.  I've cleaned up the DS records in Google, and fixed the 
sienawx.us
CDS issue (it was added by bind at some point, but wasn't in my unsigned 
zone,
so I stopped bind, removed the signed version of the zone, and upped the 
SOA
serial in the unsigned version to higher than what was in the signed 
version,

and restarted bind).

I also didn't realize I needed to do a rndc dnssec -checkds -key  
withdrawn .


I did find a manpage bug for the rndc man page for 9.18.2:
 dnssec (-status | -rollover -key id [-alg algorithm] [-when time] |
   -checkds [-key id [-alg algorithm]] [-when time] published | 
withdraw))

   zone [class [view]]

s/withdraw/withdrawn/

withdraw garners a syntax error :(

Thanks for the inbound clue-by-four.


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--
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

Missing n in man page for rndc(8)?

[Larry Rosenman]

I did find a manpage bug for the rndc man page for 9.18.2:
 dnssec (-status | -rollover -key id [-alg algorithm] [-when time] |
   -checkds [-key id [-alg algorithm]] [-when time] published | 
withdraw))

   zone [class [view]]

s/withdraw/withdrawn/

withdraw garners a syntax error :(

Where should I report this?  Or is here sufficient?

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--
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

[Larry Stone]

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: 9.18 behavior change for mDNS queries with dig

[Larry Stone]

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

Re: 9.18 behavior change for mDNS queries with dig

[Larry Stone]

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

[Larry Stone]

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

[Larry Stone]

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: why queries rejected?

[Larry Brower]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 01/18/2011 12:26 AM, p...@mail.nsbeta.info wrote:
> 
> Hi,
> I saw this piece from named.stats:
> [XXX.com]
>  812922 auth queries rejected
> 116 recursive queries rejected
>   4 transfer requests rejected
>  80 update requests rejected
>  922732 queries resulted in successful answer
>  947383 queries resulted in authoritative answer
>   23633 queries resulted in nxrrset
>1018 queries resulted in NXDOMAIN
>  77 requested transfers completed
>  38 updates completed
> 
> The first line shows there is 812922 auth queries rejected.
> Where there are so many queries which were rejected by bind?
> Thanks.


You haven't provided enough information for us to know. Have you
bothered checking logs?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCgAGBQJNNTjHAAoJEBgaXYoZ++87rFwIAMEFjeVs3Ic90n/hwkW/g95e
oWbHZ4blyXhMEM2IpnklDN6t5jc2QckisyGoVKbpQ4eJ0vZMRH3+JlQfTexMu90B
aZk5OAkk5mBkLPv7UaKGi7/l1J98QdkJwg2be/JYzOIQvHQgb1RaRY2VUw5gKKJS
JcpS05NIeCnXoFSVegFkZOVHLic0TbhDVcGweRG5AYaHl8xdAwNPbgkwmqd97O/4
a/cQWSrXr6fyRyUEKeAanr4IxP/fU884mpbweeH0ZfnhYf5SQeEvfoOje35nepaC
YTaqHWuP97WcS8KojUa7eWoSAI2GKAWEwsBA22en8mvJ6xCPiBhO2xDyCZC+veU=
=lkIs
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Help to solve ROOT DNS query

[Larry Brower]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Your questions seems more geared towards a list that deals with Microsoft

Perhaps try the NT System Admin list or the AD list:

http://www.sunbeltsoftware.com/communities/



On 03/30/2011 02:34 AM, babu dheen wrote:
> Hi,
>  
>  We are using Microsoft AD server as DNS server for our company and we
> have configured FORWARDER to ISP DNS server for external domain queries.
> What we noticed that our internal DNS server is able to use FORWARDERS
> all time but firewall logs shows that internal AD servers is contacting
> root DNS servers parallelly.
>  
>  Please help us to resove this problem.
> 
> 
> 
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

- -- 


Larry Brower
Level II Linux Systems Administrator
HostGator.com LLC

lbro...@hostgator.com

Http://www.hostgator.com
Http://support.hostgator.com/

Fedora Ambassador - North America
lbro...@fedoraproject.org
http://fedoraproject.org/

PGP/GPG Key: 0xAE838321
Key fingerprint = 4F4D 41D7 12D5 DD3F 5A20  1398 7503 FCEC AE83 8321



?So much of what we call management consists in making it difficult for
people to work?
   -- Peter F. Drucker
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCgAGBQJNkuC8AAoJEBgaXYoZ++87wRoIAJdmIZugQJig+X/VbrPTJ3X8
cW116ev02J6OtQlxPOLX/zNyMu1I+rST/MlvdhXO53x+9+kYEoXWfFi14phe5Cnt
jvw0/7o2ZAB4TEf2fhdBfeRLvooD1YwPkdFg0Cdkh5ZyaQ2fnnXnWSw5TRaVE42T
ORhLpeuVaewYhZcyo2SUsNrUsoWVOZTJGTvRF1LZeJGznQ8ds63S5/GKhBc6fqkh
2UE5qoollN0ekrrUJx/CcU6sR4BLxTzoNK61uCNJH39xc+pB6QSj0ArfJ9kwDkDH
d5KgGNtG+Eni+p9Qx9fO+pPWGBE8JmM//MeUrBzgCW49qFXkPbsNtmxb6WEdgWA=
=3fSA
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: udp vs tcp query

[Larry Brower]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/22/2011 10:24 PM, Benny Pedersen wrote:
> can i control this pr zone when bind is dns client ?
> 
Why would you want to? Just fix the problem.

> remote server is rbldnsd with is not supporting tcp, how to solve this ?

Use a server that is sane and supports tcp?
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJOo4tYAAoJEF1Xw4ZWTEoJzBcP/1J5fxBZ8gzgLlTsAbFPILbn
vfCTFnRJ8DX1WDHg1UMFp5Z3P/KisfyXUaGxN/+PhZoCh8elAzc6TY8Kw1Hqv9fJ
rvyevVjfbmk0jOmroCE9uX6ztlgIgn8r7MoHEbYXWmN1MrElUMvVU1ZwY6lbLg9M
Egmh+07ps9U/KFjme6/LRsbBytGX5TuvNTENW/Q+Xt+mrmqZ4cI5G3kHwZH/UqRf
05pWI7mdp7XJT3Wp6jfjpXrIJJ//46MrUFevIhDdfWWVJILmrQL+87RFnfk71p2R
1YSsQpwQRKic4J+6ptq1OJD9+idj/Kw7PxO2OBIb7giu+x3nmM0biv0uW129OEc7
v6nemGK6RJtrgKRZop7XYGrxFX5wPJk5wSbuuz3zy20Wuu40y896SfKwUvYNPD0i
pSVFXNIkUXqhoVGd13e1bH0EJF0SFkN8dqO3HF8XI1NrIbBmu53uuCmwi7/vO2VD
a8ck6+qnC1nlk1yZV4A1OJv6HO8j1p/Jvktd4d1czBXEuAq2o1TZ3DENLBmRhyS6
yBSpSGozoZNP43t0LatrVqiKGAdhcGf4D1HHByiHFGX0iOxjQoOKf8+d1J53ae5P
fncIxEhmvXQK+MczYVEXumSKnj7p7EpJB0nVDc1wQHeVpGko1MOO+eC7YH4g0dcx
s0PUPxrMCYunnLKEMwTh
=iHaT
-END PGP 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: How can someone know Sub-Domains?

[Larry Brower]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 12/24/2011 05:48 PM, Michelle Konzack wrote:
> Hello *,
> 
> I have installed inside my corporated domain a subdomain for a  customer
> and now this subdomain is under attack, exactly,  the  Domains  with  37
> Courier-Servers and 140 Web-Servers are DoS'ed.  This mean,  someone  is
> trying to bring down the whole network using >200k  IPs.  I use a  CISCO
> 12008 which work nicely with its filters, but not always.   My Dual 1 GE
> connection is nearly fucked!
> 
> And yes, I have a big problem with "extortion" since arround 2 weeks and
> I am not willing to pay.
> 
> Thanks, Greetings and nice Day/Evening
> Michelle Konzack
> 

Why would you give them a subdomain?
How do you know they weren't being targeted prior to coming to you?
Why haven't you nulled them yet?
Why do you think this belongs on this list?



- -- 


Larry Brower, CCENT
Linux System Administrator II
HostGator.com LLC

lbro...@hostgator.com
Http://www.hostgator.com
Http://support.hostgator.com/

Fedora Ambassador - North America
Fedora Quality Assurance

lbro...@fedoraproject.org
http://www.fedoraproject.org/
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJO9oI9AAoJEF1Xw4ZWTEoJJq8QAIpMWiaLUsZnhDJ5ccZxnlJ5
L8rDF9W0jE2E95lk3yqXmCza2AsZCLxXxAwfud8/cjLjxPF4xzPoLZSyN5RtSVT8
X6xiNpYD9Geqn2xrQsyY94cGgTkz+LfndCpuTuCiTLAwh3Pn4jkhfnu8RIPcqIXg
2uFLtguRfzHirXb+NUaxGI3b8V7mJGnHCdVAsxvZtUoN7QCHIP1hIyMYfZqvXc4H
GHp9K9jGjYIU/uIe8gXxSifXGtRzTIhWIIXRQvJo1SQ/kWzx3acnw0kC2H69EL9D
dH198amEqk1aLs+3DefK2uskaEr1f/8v+Ps1F6UsZSkcdNGlX2Nwp0plBoL8J84s
h80PVcprAMhiWyvyNjMNhjHw5Cm4oaomZ8myqK2qFwge4mMASCX3T/ntvr6MrKQz
Yfd7WcfMDOI4cHT7OMoVnTLrZ7aslYN9WEsaFqE6tZXWu49a9+GWzObyuTA+23Lm
WBScdcLawir34a0T/d+K+1zWq9es7YqEn6l8U89tqmb5weMAyXAMVYxKU+k36dTu
AADE4JuAmFoYrSLabBNb9I3txNfEeLNMTqQGeBctn9fr2kGjL1OswcAxqijzZakF
xiOcrzYmJnpeSN9VNcJ7DQF1Y98wUjIxO3FXFwXqYgaNlOfDvVUB5lkr6/9/R6Td
Jqr8/u9+FQLshN44Gqak
=ui1u
-END PGP 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: GeoIP like RBLDNS

[Larry Brower]

What about using bind-dlz and use a mysql database for the records?

Michelle Konzack  wrote:

>Hello Bind9 Geeks/Nerds and whoever,
>
>I have the need for a GeoIP Database but the one from Maxmind peoduce  a
>Disk-IO as the hell.  Now my Idea is to use my bind9 to archive my goal.
>
>In general, I need ONLY the contry code for a  given  IP  but  I  a  not
>disinclined to put more infos in the database.
>
>[michelle.konz...@michelle1:~] host 188.66.4.62.geoip.tamay-dogan.net
>188.66.4.62.geoip.tamay-dogan.net is an alias for de.geoip.tamay-dogan.net.
>de.geoip.tamay-dogan.net has address 127.0.0.49
>
>OK, this is working, but loading a ZONE of several 100 MBytes (I am  not
>even finished with the german part) hit the limits,  even if my  Server,
>a Quad-Xeon, has 16 GBytes of memory...
>
>Any ideas howt to do this better?
>
>Thanks, Greetings and nice Day/Evening
>Michelle Konzack
>Systemadministrator
>24V Electronic Engineer
>Tamay Dogan Network
>Debian GNU/Linux Consultant
>
>-- 
>Linux-User #280138 with the Linux Counter, http://counter.li.org/
># Debian GNU/Linux Consultant #
> Michelle Konzack
>   Apt. 917
>   50, rue de Soultz
>Jabber linux4miche...@jabber.ccc.de   67100 Strasbourg/France
>IRC #Debian (irc.icq.com) Tel. DE: +49 177 9351947
>ICQ #328449886Tel. FR: +33  6  61925193
>___
>bind-users mailing list
>bind-users@lists.isc.org
>https://lists.isc.org/mailman/listinfo/bind-users___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS Appliance

[Larry Fahnoe]

Another thumbs-up for Infoblox.  We've been using their appliance for a few
years now and have been pleased with both the product and the support.  We
use it as a false root and manage both private and public name/address space
with it; several hundred zones, many hundreds of networks world-wide.  I
like the integrated database and API.  If you want an appliance to manage
DNS & DHCP that provides a unified view of the two worlds, Infoblox is worth
considering.

--Larry

-- 
Larry Fahnoe, Fahnoe Technology Consulting, fah...@fahnoetech.com
952/925-0744  Minneapolis, Minnesota   www.FahnoeTech.com
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Odd issue with some domain queries

[Larry Ludwig]

0  IN  NS  ns2.webanize.com.
;; Received 106 bytes from 192.54.112.30#53(H.GTLD-SERVERS.NET) in 101  
ms


dig: couldn't get address for 'ns1.webanize.com': failure

[r...@ns1 etc]# nslookup
> rejuvenatetraining.com
Server: 192.168.11.3
Address:192.168.11.3#53

** server can't find rejuvenatetraining.com: SERVFAIL
> exit

[r...@ns1 etc]# dig +trace rejuvenatetraining.com

; <<>> DiG 9.2.4 <<>> +trace rejuvenatetraining.com
;; global options:  printcmd
.   516892  IN  NS  j.root-servers.net.
.   516892  IN  NS  k.root-servers.net.
.   516892  IN  NS  l.root-servers.net.
.   516892  IN  NS  m.root-servers.net.
.   516892  IN  NS  a.root-servers.net.
.   516892  IN  NS  b.root-servers.net.
.   516892  IN  NS  c.root-servers.net.
.   516892  IN  NS  d.root-servers.net.
.   516892  IN  NS  e.root-servers.net.
.   516892  IN  NS  f.root-servers.net.
.   516892  IN  NS  g.root-servers.net.
.   516892  IN  NS  h.root-servers.net.
.   516892  IN  NS  i.root-servers.net.
;; Received 316 bytes from 192.168.11.3#53(192.168.11.3) in 25 ms

com.172800  IN  NS  B.GTLD-SERVERS.NET.
com.172800  IN  NS  C.GTLD-SERVERS.NET.
com.172800  IN  NS  K.GTLD-SERVERS.NET.
com.172800  IN  NS  H.GTLD-SERVERS.NET.
com.172800  IN  NS  M.GTLD-SERVERS.NET.
com.172800  IN  NS  F.GTLD-SERVERS.NET.
com.172800  IN  NS  L.GTLD-SERVERS.NET.
com.172800  IN  NS  J.GTLD-SERVERS.NET.
com.172800  IN  NS  I.GTLD-SERVERS.NET.
com.172800  IN  NS  D.GTLD-SERVERS.NET.
com.172800  IN  NS  E.GTLD-SERVERS.NET.
com.172800  IN  NS  G.GTLD-SERVERS.NET.
com.172800  IN  NS  A.GTLD-SERVERS.NET.
;; Received 512 bytes from 192.58.128.30#53(j.root-servers.net) in 103  
ms


rejuvenatetraining.com. 172800  IN  NS  ns1.qualdns.net.
rejuvenatetraining.com. 172800  IN  NS  ns2.qualdns.net.
;; Received 119 bytes from 192.33.14.30#53(B.GTLD-SERVERS.NET) in 249 ms

rejuvenatetraining.com. 14400   IN  A   174.132.225.20
rejuvenatetraining.com. 86400   IN  NS  ns1.qualdns.net.
rejuvenatetraining.com. 86400   IN  NS  ns2.qualdns.net.
;; Received 135 bytes from 174.132.225.18#53(ns1.qualdns.net) in 128 ms

Any ideas on what could be the issue?

Thanks in advance for your help.

-L

--
Larry Ludwig





___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Installing 9.7?

[Larry Brower]

Daniel Morgan wrote:

This may seem like a retarded question. Following advice to update I've
downloaded the 9.7 source and built it as per the readme:



Was there a question somewhere?
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Installing 9.7?

[Larry Brower]

Daniel Morgan wrote:

Apologies - my mailer half sent the post

Following advice on a duplicate query issue, I've downloaded and built
9.7 from source as per the readme:

"To build, just
./configure
make"

This completed just fine - but what I can't find is any details on how
to physically install it after building. I'm used to things like 'make
install', but I don't want to blindly run random commands that may cause
carnage.

I note that it's created plenty of files - some for the Win platform(?)
and I'm confused as to what I have to put where. I'm running a Debian
based system and I appear to have the most recent packaged version
already - hence the source option.

I can see an install-sh script but that gives me:
./install-sh
install:no input file specified

Is there an install DOC that I can't find?




running make install will install it.


optionally: You may want to look at the configure options as you might 
be wanting to explicitly set some of them.




___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: synchronization between maste and slave no working

[Larry Brower]

Yunfeng Xu wrote:

Hi, all

I tried to add one A record on the master, but the slave did not get the 
new record.


my slave settting is :

zone "mydomain.com.cn " IN {
type slave;
file "mydomain.com.cn.zone";
masters {10.69.3.1;};
};

10.69.3.1 is my master ip. bind version is bind-9.3.6-4.P1.el5_4.2.

I guess I may lack some settings. Can anyone give me some advise?

Many thanks
hywl51



What is shown in the server's logs?

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Defining custom root zone by subnet.

[Larry Brower]

Nadir Aliyev wrote:

Hi friends,

 

Its possible in bind define fake root zone by subnet? (in this case just 
for zone1)


 


Sounds like you need to use views. Why would you want to do this 
though? It is silly.

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

ip6tables with raw table(no conntrack) drop fragmented packet

[Larry Larson]

Greetings,

I've followed instructions in this BIND Knowledge base article and
installed ip6tables on my DNS server, using raw table with no conntrack for
DNS:
https://kb.isc.org/article/AA-01183/0/Linux-connection-tracking-and-DNS.html

But for IPv6 it drops fragmented packets, for example this query fails once
the ip6table is on:
dig +dnssec  isc.org any  @2001:500:60::30

Everything works great for IPv4 with similar rules, can someone help shed
some light on what might be wrong:

# Firewall configuration written by system-config-firewall
*raw
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -p udp -m udp --dport 53 -j NOTRACK
-A PREROUTING -p udp -m udp --sport 53 -j NOTRACK
-A OUTPUT -p udp -m udp --dport 53 -j NOTRACK
-A OUTPUT -p udp -m udp --sport 53 -j NOTRACK
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED,UNTRACKED -j ACCEPT
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
#tcp dns
-A INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport 53 -j ACCEPT
-A INPUT -m conntrack --ctstate NEW -m tcp -p tcp --sport 53 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp6-adm-prohibited
-A FORWARD -j REJECT --reject-with icmp6-adm-prohibited
COMMIT

Thanks in advance!!
Larry
___
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: ip6tables with raw table(no conntrack) drop fragmented packet

[Larry Larson]

This is for recursive, and our recursive got 10X more queries than our
authoritative ones, and we had to disable conntrack on our DNS servers last
summer by using raw table and everything works for IPv4 including
fragmentation, we just noticed fragment fails for IPv6 when using raw
table, query not trigger fragment works fine, like this one:
dig @2001:500:60::30 isc.org

I've added the trace to the ip6table, and here is the pcap:
15:51:48.746691 IP6 (hlim 64, next-header UDP (17) payload length: 44)
2001:0468:2:183::20.45955 > 2001:500:60::30.53: [udp sum ok] 59884+ [1au]
ANY? isc.org. ar: . OPT UDPsize=4096 OK (36)
15:51:48.846080 IP6 (hlim 52, next-header Fragment (44) payload length:
1240) 2001:500:60::30 > 2001:0468:2:183::20: frag (0xefa32c05:0|1232) 53 >
45955: 59884*- q: ANY? isc.org. 27/0/16 isc.org. RRSIG, isc.org. SPF,
isc.org. RRSIG, isc.org. RRSIG, isc.org. DNSKEY, isc.org. DNSKEY, isc.org.
RRSIG[|domain]
15:51:48.846101 IP6 (hlim 52, next-header Fragment (44) payload length:
1240) 2001:500:60::30 > 2001:0468:2:183::20: frag (0xefa32c05:1232|1232)
15:51:48.846122 IP6 (hlim 52, next-header Fragment (44) payload length:
1240) 2001:500:60::30 > 2001:0468:2:183::20: frag (0xefa32c05:2464|1232)
15:51:48.846126 IP6 (hlim 52, next-header Fragment (44) payload length:
318) 2001:500:60::30 > 2001:0468:2:183::20: frag (0xefa32c05:3696|310)

Here is the dmesg:
TRACE: raw:OUTPUT:rule:3 IN= OUT=eth0
SRC=2001:0468:0002:0183::::0020
DST=2001:0500:0060:::::0030 LEN=84 TC=0 HOPLIMIT=64
FLOWLBL=0 PROTO=UDP SPT=38537 DPT=53 LEN=44 UID=0 GID=0
TRACE: raw:OUTPUT:policy:5 IN= OUT=eth0
SRC=2001:0468:0002:0183::::0020
DST=2001:0500:0060:::::0030 LEN=84 TC=0 HOPLIMIT=64
FLOWLBL=0 PROTO=UDP SPT=38537 DPT=53 LEN=44 UID=0 GID=0
TRACE: filter:OUTPUT:policy:1 IN= OUT=eth0
SRC=2001:0468:0002:0183::::0020
DST=2001:0500:0060:::::0030 LEN=84 TC=0 HOPLIMIT=64
FLOWLBL=0 PROTO=UDP SPT=38537 DPT=53 LEN=44 UID=0 GID=0
TRACE: raw:PREROUTING:policy:5 IN=eth0 OUT=
MAC=00:50:56:a9:44:68:00:23:9c:f5:67:f0:86:dd
SRC=2001:0500:0060:::::0030
DST=2001:0468:0002:0183::::0020
LEN=1280 TC=0 HOPLIMIT=52 FLOWLBL=0 OPT ( FRAG:0 INCOMPLETE ID:90c4bbe8 )
PROTO=UDP SPT=53 DPT=38537 LEN=4006
TRACE: filter:INPUT:rule:1 IN=eth0 OUT=
MAC=00:50:56:a9:44:68:00:23:9c:f5:67:f0:86:dd
SRC=2001:0500:0060:::::0030
DST=2001:0468:0002:0183::::0020
LEN=1280 TC=0 HOPLIMIT=52 FLOWLBL=0 OPT ( FRAG:0 INCOMPLETE ID:90c4bbe8 )
PROTO=UDP SPT=53 DPT=38537 LEN=4006
TRACE: raw:PREROUTING:policy:5 IN=eth0 OUT=
MAC=00:50:56:a9:44:68:00:23:9c:f5:67:f0:86:dd
SRC=2001:0500:0060:::::0030
DST=2001:0468:0002:0183::::0020
LEN=1280 TC=0 HOPLIMIT=52 FLOWLBL=0 OPT ( FRAG:1232 INCOMPLETE ID:90c4bbe8
) PROTO=UDP
TRACE: raw:PREROUTING:policy:5 IN=eth0 OUT=
MAC=00:50:56:a9:44:68:00:23:9c:f5:67:f0:86:dd
SRC=2001:0500:0060:::::0030
DST=2001:0468:0002:0183::::0020
LEN=1280 TC=0 HOPLIMIT=52 FLOWLBL=0 OPT ( FRAG:2464 INCOMPLETE ID:90c4bbe8
) PROTO=UDP
TRACE: raw:PREROUTING:policy:5 IN=eth0 OUT=
MAC=00:50:56:a9:44:68:00:23:9c:f5:67:f0:86:dd
SRC=2001:0500:0060:::::0030
DST=2001:0468:0002:0183::::0020
LEN=358 TC=0 HOPLIMIT=52 FLOWLBL=0 OPT ( FRAG:3696 ID:90c4bbe8 ) PROTO=UDP
TRACE: raw:OUTPUT:rule:3 IN= OUT=eth0
SRC=2001:0468:0002:0183::::0020
DST=2001:0500:0060:::::0030 LEN=84 TC=0 HOPLIMIT=64
FLOWLBL=0 PROTO=UDP SPT=38537 DPT=53 LEN=44 UID=0 GID=0


Thanks!

Larry

On Sat, Oct 1, 2016 at 2:21 PM, /dev/rob0  wrote:

> On Fri, Sep 30, 2016 at 11:55:18PM -0400, Larry Larson wrote:
> > I've followed instructions in this BIND Knowledge base article and
> > installed ip6tables on my DNS server, using raw table with no
> > conntrack for DNS:
> > https://kb.isc.org/article/AA-01183/0/Linux-connection-
> tracking-and-DNS.html
>
> This is mostly for authoritative servers which must be open to
> queries from anywhere.  Perhaps this is not a real issue, as it
> sounds like you might be setting up a recursive server?  Of course,
> it CAN be a problem for recursive-only servers too; it just depends
> how many users and concurrent queries you need to support.  If your
> userbase can flood your conntrack table, you need this.
>
> > But for IPv6 it drops fragmented packets, for example this query
> > fails once the ip6table is on:
> > dig +dnssec  isc.org any  @2001:500:60::30
>
> Can you show us how you found out that it was affecting fragments?
> Is this query falling back to TCP?  Do you have a pcap?
>
> > Everything works great for IPv4 with similar rules, can someone
> > help shed some light on what might be wrong:
> >
> > # Firewall configuration written by system-config-firewall
>
> A minor issue, the NOTRACK target

Re: Bind Queries log file format

[Larry Stone]

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  wrote:
> 
> 
> In message 
>  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, qname, qclass, qtype, RD, signed, EDNS
> 9.4.0: client, qname

Re: Bind Queries log file format

[Larry Stone]

> On Feb 7, 2017, at 11:07 PM, Mark Andrews  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 9.11.x build failing on Mac OS X - gssapi errors

[Larry Stone]

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 
>  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 libd

BIND 9.12.4 python error building on MacOS

[Larry Stone]

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.12.4 python error building on MacOS

[Larry Stone]

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

Re: dnssec: ds showing hidden 3+ days after key roll

[Larry Rosenman via bind-users]

On 02/10/2022 10:10 am, Matthijs Mekking wrote:

Hi,

There are several things wrong here. The gist of it is that there is
no valid ZSK and since the zone is not properly signed, BIND does not
want to publish the DS record (even if outside BIND you already
published the DS).

You can tell that BIND does not agree because it did not publish a CDS
record in your zone.

I also noticed two different algorithms. I hadn't noticed it before
but your policy says:

keys {
ksk lifetime unlimited algorithm 8 2048 ;
zsk lifetime 30d algorithm 13;
};

This is a garbage policy because you specify different algorithms for
the ksk and the zsk. This can never result in a validly signed zone.

Change the algorithm of the keys so that they match.

Perhaps we can add a named-checkconf check for this.


Best regards,

Matthijs


[snip]

Thanks!   Is that little nuance documented?  (The need for KSK and ZSK 
to be aligned on type of key)


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--
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

daemon warning

[Stewart, Larry C Sr CTR DISA JITC (US)]

I just finished compiling BIND 9.10.0-P2 on my Solaris 10 x86 platform. I am 
replacing BIND 9.6-ESV-R7-P4 which I have been running in a chroot environment 
I have configured the Solaris service admin to run /nithr/sbin/named -t /dns -u 
dnsuser when I start the dns server now since I have upgraded to 9.10.0-P2 I 
get a daemon notice  that it is unable to set the effective uid to 0: Not Owner 
logged in my /var/adm/messages that I never received before. I assume this is 
all about permissions but which permissions specifically I don't know. The 
Daemon does start running so not sure if this is something to chase down or not.

Larry Stewart, CISSP, CCNA
Contractor - ManTech
Network Engineer
Office: 520-538-4227
DSN: 879-4227
Cell phone: 520-227-8251
larry.c.stewart@mail.mil




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: daemon warning

[Stewart, Larry C Sr CTR DISA JITC (US)]

Correct, so is there some negative impact I can expect or is it just a log 
entry I can ignore?

Larry Stewart, CISSP, CCNA
Contractor - ManTech
Network Engineer
Office: 520-538-4227
DSN: 879-4227
Cell phone: 520-227-8251
larry.c.stewart@mail.mil

-Original Message-
From: Tony Finch [mailto:fa...@hermes.cam.ac.uk] On Behalf Of Tony Finch
Sent: Tuesday, July 01, 2014 4:26 AM
To: Stewart, Larry C Sr CTR DISA JITC (US)
Cc: bind-users@lists.isc.org
Subject: Re: daemon warning

Stewart, Larry C Sr CTR DISA JITC (US)  wrote:

> I have configured the Solaris service admin to run
>   /nithr/sbin/named -t /dns -u dnsuser
> when I start the dns server now since I have upgraded to 9.10.0-P2 I get
> a daemon notice that it is unable to set the effective uid to 0: Not
> Owner logged in my /var/adm/messages that I never received before.

I think this warning happens either when named tries to write its pid file
or its session key file, which are the only times that I can find when it
would try to set its euid to 0. (When writing those files named
temporarily drops privileges, calling seteuid(0) to raise them again, and
it permanently drops privileges a bit later.)

So my guess is you are not starting named as root?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Humber: Northwest backing southwest 3 or 4. Slight, becoming moderate for a
time in northeast. Mainly fair. Good.


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: daemon warning

[Stewart, Larry C Sr CTR DISA JITC (US)]

So I logged in as the user that I normally start named with and I get the 
following error:

Named: chroot(): Not owner

Larry Stewart, CISSP, CCNA
Contractor - ManTech
Network Engineer
Office: 520-538-4227
DSN: 879-4227
Cell phone: 520-227-8251
larry.c.stewart@mail.mil


-Original Message-
From: Tony Finch [mailto:fa...@hermes.cam.ac.uk] On Behalf Of Tony Finch
Sent: Tuesday, July 01, 2014 7:43 AM
To: Stewart, Larry C Sr CTR DISA JITC (US)
Cc: bind-users@lists.isc.org
Subject: RE: daemon warning

Stewart, Larry C Sr CTR DISA JITC (US)  wrote:

> Correct, so is there some negative impact I can expect or is it just a
> log entry I can ignore?

If you aren't getting any "Could not open..." warnings as well then you
are probably OK.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Dover, Wight, Portland, Plymouth: East or northeast 4 or 5, occasionally 6 at
first. Slight or moderate. Showers. Moderate or good.


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: daemon warning

[Stewart, Larry C Sr CTR DISA JITC (US)]

Ok so that was not a good troubleshooting technique, was trying to determine 
what did not have the correct permissions and thus causing the warning. I guess 
I will go ahead and run it the way I have been for the last 5 years, unless I 
find it is causing me problems.

Larry Stewart, CISSP, CCNA
Contractor - ManTech
Network Engineer
Office: 520-538-4227
DSN: 879-4227
Cell phone: 520-227-8251
larry.c.stewart@mail.mil


-Original Message-
From: Tony Finch [mailto:fa...@hermes.cam.ac.uk] On Behalf Of Tony Finch
Sent: Tuesday, July 01, 2014 8:05 AM
To: Stewart, Larry C Sr CTR DISA JITC (US)
Cc: bind-users@lists.isc.org
Subject: RE: daemon warning

Stewart, Larry C Sr CTR DISA JITC (US)  wrote:

> So I logged in as the user that I normally start named with and I get the 
> following error:
>
> Named: chroot(): Not owner

You need to start named as root for it to be able to chroot. (Unless
Solaris has some cunning fine-grained privilege feature I don't know
about.)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Shannon: Northeast 4 or 5, becoming variable 3, then southwest 5 to 7 later.
Slight or moderate, becoming rough later in north. Rain later. Good,
occasionally poor later.


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

Crypto failure Issues

[Stewart, Larry C Sr CTR DISA JITC (US)]

I am having issues with bind failing to start due to a crypto failure when I 
compile with the --with-openssl option when I have openssl version 1.0.2d or 
1.0.2c

Is anyone aware of any compatibility issues between bind and openssl version 
1.0.2? I have no issues when I use openssl version 0.9.8zf.

My system is a Solaris 10 x86 OS

Larry Stewart, CISSP
Contractor - ManTech
Network Engineer
Office: 520-538-4227
DSN: 879-4227
Cell phone: 520-227-8251
larry.c.stewart@mail.mil



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: Crypto failure Issues

[Stewart, Larry C Sr CTR DISA JITC (US)]

All

It occurred to me that you may need more info to assist me the logs show the 
following:

Jul 23 15:55:11 nit-dns2 named[20169]: [ID 873579 daemon.notice] starting BIND 
9.10.2-P2 -t /nithr -u nithr -d 2 -f
Jul 23 15:55:11 nit-dns2 named[20169]: [ID 873579 daemon.notice] built with 
'--prefix=/' '--with-openssl=/usr/local/ssl' '--enable-threads' 
'CC=/usr/sfw/bin/gcc'
Jul 23 15:55:11 nit-dns2 named[20169]: [ID 873579 daemon.notice] 

Jul 23 15:55:11 nit-dns2 named[20169]: [ID 873579 daemon.notice] BIND 9 is 
maintained by Internet Systems Consortium,
Jul 23 15:55:11 nit-dns2 named[20169]: [ID 873579 daemon.notice] Inc. (ISC), a 
non-profit 501(c)(3) public-benefit
Jul 23 15:55:11 nit-dns2 named[20169]: [ID 873579 daemon.notice] corporation.  
Support and training for BIND 9 are
Jul 23 15:55:11 nit-dns2 named[20169]: [ID 873579 daemon.notice] available at 
https://www.isc.org/support
Jul 23 15:55:11 nit-dns2 named[20169]: [ID 873579 daemon.notice] 

Jul 23 15:55:11 nit-dns2 named[20169]: [ID 873579 daemon.warning] ENGINE_by_id 
failed (crypto failure)
Jul 23 15:55:11 nit-dns2 named[20169]: [ID 873579 daemon.crit] initializing 
DST: crypto failure
Jul 23 15:55:11 nit-dns2 named[20169]: [ID 873579 daemon.crit] exiting (due to 
fatal error)


As you can see I am running named in a chroot jail. I compile it the same as 
when I am using the older version of openssl. Looking on line this issue seems 
to have raised its head with the release of openssl 1.0.0, but I have yet to 
discover a solution on line. 

Larry Stewart, CISSP
Contractor - ManTech
Network Engineer
Office: 520-538-4227
DSN: 879-4227
Cell phone: 520-227-8251
larry.c.stewart@mail.mil


-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Stewart, Larry C Sr CTR 
DISA JITC (US)
Sent: Friday, July 24, 2015 9:22 AM
To: bind-users@lists.isc.org
Subject: Crypto failure Issues

I am having issues with bind failing to start due to a crypto failure when I 
compile with the --with-openssl option when I have openssl version 1.0.2d or 
1.0.2c

Is anyone aware of any compatibility issues between bind and openssl version 
1.0.2? I have no issues when I use openssl version 0.9.8zf.

My system is a Solaris 10 x86 OS

Larry Stewart, CISSP
Contractor - ManTech
Network Engineer
Office: 520-538-4227
DSN: 879-4227
Cell phone: 520-227-8251
larry.c.stewart@mail.mil



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: Crypto failure Issues

[Stewart, Larry C Sr CTR DISA JITC (US)]

I am using a prebuilt binary will give compiling it myself a try and see what 
that yields.

Larry Stewart, CISSP
Contractor - ManTech
Network Engineer
Office: 520-538-4227
DSN: 879-4227
Cell phone: 520-227-8251
larry.c.stewart@mail.mil

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Ted Mittelstaedt
Sent: Friday, July 24, 2015 12:28 PM
To: bind-users@lists.isc.org
Subject: Re: Crypto failure Issues

Did you compile both openssl and bind or are you using a prebuilt binary?

There are (apparently) problems with OpenSSL 1.0.2 on the 32 bit Solaris
10 platform.  This was discussed on the openssl-users mailing list
a few months ago.  The "fix" was building with an openssl 1.0.1
version on that platform.  I would try that myself.

Ted

On 7/24/2015 10:31 AM, Stewart, Larry C Sr CTR DISA JITC (US) wrote:
> All
>
> It occurred to me that you may need more info to assist me the logs show the 
> following:
>
> Jul 23 15:55:11 nit-dns2 named[20169]: [ID 873579 daemon.notice] starting 
> BIND 9.10.2-P2 -t /nithr -u nithr -d 2 -f
> Jul 23 15:55:11 nit-dns2 named[20169]: [ID 873579 daemon.notice] built with 
> '--prefix=/' '--with-openssl=/usr/local/ssl' '--enable-threads' 
> 'CC=/usr/sfw/bin/gcc'
> Jul 23 15:55:11 nit-dns2 named[20169]: [ID 873579 daemon.notice] 
> 
> Jul 23 15:55:11 nit-dns2 named[20169]: [ID 873579 daemon.notice] BIND 9 is 
> maintained by Internet Systems Consortium,
> Jul 23 15:55:11 nit-dns2 named[20169]: [ID 873579 daemon.notice] Inc. (ISC), 
> a non-profit 501(c)(3) public-benefit
> Jul 23 15:55:11 nit-dns2 named[20169]: [ID 873579 daemon.notice] corporation. 
>  Support and training for BIND 9 are
> Jul 23 15:55:11 nit-dns2 named[20169]: [ID 873579 daemon.notice] available at 
> https://www.isc.org/support
> Jul 23 15:55:11 nit-dns2 named[20169]: [ID 873579 daemon.notice] 
> 
> Jul 23 15:55:11 nit-dns2 named[20169]: [ID 873579 daemon.warning] 
> ENGINE_by_id failed (crypto failure)
> Jul 23 15:55:11 nit-dns2 named[20169]: [ID 873579 daemon.crit] initializing 
> DST: crypto failure
> Jul 23 15:55:11 nit-dns2 named[20169]: [ID 873579 daemon.crit] exiting (due 
> to fatal error)
>
>
> As you can see I am running named in a chroot jail. I compile it the same as 
> when I am using the older version of openssl. Looking on line this issue 
> seems to have raised its head with the release of openssl 1.0.0, but I have 
> yet to discover a solution on line.
>
> Larry Stewart, CISSP
> Contractor - ManTech
> Network Engineer
> Office: 520-538-4227
> DSN: 879-4227
> Cell phone: 520-227-8251
> larry.c.stewart@mail.mil
>
>
> -Original Message-
> From: bind-users-boun...@lists.isc.org 
> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Stewart, Larry C Sr 
> CTR DISA JITC (US)
> Sent: Friday, July 24, 2015 9:22 AM
> To: bind-users@lists.isc.org
> Subject: Crypto failure Issues
>
> I am having issues with bind failing to start due to a crypto failure when I 
> compile with the --with-openssl option when I have openssl version 1.0.2d or 
> 1.0.2c
>
> Is anyone aware of any compatibility issues between bind and openssl version 
> 1.0.2? I have no issues when I use openssl version 0.9.8zf.
>
> My system is a Solaris 10 x86 OS
>
> Larry Stewart, CISSP
> Contractor - ManTech
> Network Engineer
> Office: 520-538-4227
> DSN: 879-4227
> Cell phone: 520-227-8251
> larry.c.stewart@mail.mil
>
>
>
>
> ___
> 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


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: Crypto failure Issues

[Stewart, Larry C Sr CTR DISA JITC (US)]

Thank you that was the trick. What impact does that have on crypto operations 
used by BIND?

Larry Stewart, CISSP
Contractor - ManTech
Network Engineer
Office: 520-538-4227
DSN: 879-4227
Cell phone: 520-227-8251
larry.c.stewart@mail.mil


-Original Message-
From: Tony Finch [mailto:fa...@hermes.cam.ac.uk] On Behalf Of Tony Finch
Sent: Monday, July 27, 2015 8:27 AM
To: Stewart, Larry C Sr CTR DISA JITC (US)
Cc: bind-users@lists.isc.org
Subject: Re: Crypto failure Issues

Stewart, Larry C Sr CTR DISA JITC (US)  wrote:

> I am having issues with bind failing to start due to a crypto failure
> when I compile with the --with-openssl option when I have openssl
> version 1.0.2d or 1.0.2c
>
> Is anyone aware of any compatibility issues between bind and openssl
> version 1.0.2? I have no issues when I use openssl version 0.9.8zf.

This sounds like the GOST problem. Try building BIND with
./configure --without-gost or copy the OpenSSL GOST engine shared object
into your chroot.

e.g. https://lists.isc.org/pipermail/bind-users/2014-June/093450.html
http://gnats.netbsd.org/48658

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Tyne, Dogger, Fisher: Northeast 5 or 6 backing north 4 or 5, but cyclonic at
first in Dogger. Moderate. Rain or showers. Moderate or good.


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: Crypto failure Issues

[Stewart, Larry C Sr CTR DISA JITC (US)]

Thanks 

Larry Stewart, CISSP
Contractor - ManTech
Network Engineer
Office: 520-538-4227
DSN: 879-4227
Cell phone: 520-227-8251
larry.c.stewart@mail.mil


-Original Message-
From: Tony Finch [mailto:fa...@hermes.cam.ac.uk] On Behalf Of Tony Finch
Sent: Monday, July 27, 2015 1:58 PM
To: Stewart, Larry C Sr CTR DISA JITC (US)
Cc: bind-users@lists.isc.org
Subject: RE: Crypto failure Issues

Stewart, Larry C Sr CTR DISA JITC (US)  wrote:

> Thank you that was the trick. What impact does that have on crypto
> operations used by BIND?

GOST is the Russian equivalent of NIST. They publish cryptography
standards, amongst other things. There are RFCs describing how to
use GOST crypto with TLS, DNSSEC, etc.

You might need working GOST crypto if you are working closely with
Russian government agencies. In other circumstances you can probably
ignore it.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Dogger, Fisher, German Bight, Humber: Cyclonic 5 or 6, occasionally 7 in
German Bight, becoming north or northwest 4 or 5. Slight or moderate. Rain or
showers. Good, occasionally poor.


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

Auto zone signing

[Stewart, Larry C Sr CTR DISA JITC (US)]

I recently set up DNSSEC using some older tutorials and today found one for 
auto zone signing. My question, are there any gottchas in converting over from 
manual to auto?


Larry Stewart, CISSP
Contractor - ManTech
Network Engineer
Office: 520-538-4227
DSN: 879-4227
Cell phone: 520-227-8251
larry.c.stewart@mail.mil


 


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

Openssl issue

[Stewart, Larry C Sr CTR DISA JT (USA)]

I am running Solaris 10 and I downloaded bind 9.12.3 today and compiled it 
using the enable threads option, the prefix=/ option and the --without-gost 
option just as I have in the past when compiling 9.10. The compilation seems to 
go well but when I run named with -t /nithr -u nithr named fails to start and I 
get daemon.crit openssl_link.c:296: fatal error:and Openssl pseudorandom number 
generator cannot be initialized (see the 'PRNG not seeded message in the 
Openssl FAQ). Then exiting (due to fatal error in library).

My chrooted directory does contain /dev/random

Does anyone have any suggestions on how to overcome this issue?

Larry Stewart, CISSP
Contractor - Jacobs Technology
Network Engineer
Office: 520-538-4227
DSN: 879-4227
Cell phone: 520-227-8251
larry.c.stewart@mail.mil




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: Openssl issue

[Stewart, Larry C Sr CTR DISA JT (USA)]

Please disregard apparently Openssl does not see the /dev/random in my chroot 
directory as a valid random provider. So its off to google and oracle to see 
what it will take to make a valid /dev/random available from within the jail. 

Larry Stewart, CISSP
Contractor - Jacobs Technology
Network Engineer
Office: 520-538-4227
DSN: 879-4227
Cell phone: 520-227-8251
larry.c.stewart@mail.mil


-Original Message-
From: Stewart, Larry C Sr CTR DISA JT (USA) 
Sent: Thursday, November 8, 2018 11:12 AM
To: bind-users 
Subject: Openssl issue

I am running Solaris 10 and I downloaded bind 9.12.3 today and compiled it 
using the enable threads option, the prefix=/ option and the --without-gost 
option just as I have in the past when compiling 9.10. The compilation seems to 
go well but when I run named with -t /nithr -u nithr named fails to start and I 
get daemon.crit openssl_link.c:296: fatal error:and Openssl pseudorandom number 
generator cannot be initialized (see the 'PRNG not seeded message in the 
Openssl FAQ). Then exiting (due to fatal error in library).

My chrooted directory does contain /dev/random

Does anyone have any suggestions on how to overcome this issue?

Larry Stewart, CISSP
Contractor - Jacobs Technology
Network Engineer
Office: 520-538-4227
DSN: 879-4227
Cell phone: 520-227-8251
larry.c.stewart@mail.mil




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