Re: 'inline-signing' might go away and be replaced by dnssec-policy ?

[PGNet Dev]

there are separate cases to consider.

the docs

  
https://bind9.readthedocs.io/en/latest/reference.html#dnssec-policy-block-definition-and-usage

state

The dnssec-policy statement requires dynamic DNS to be set up, or 
inline-signing to be enabled.

If inline-signing is enabled, this means that a signed version of the 
zone is maintained separately and is written out to a different file on disk 
(the zone’s filename plus a .signed extension).

If the zone is dynamic because it is configured with an update-policy 
or allow-update, the DNSSEC records are written to the filename set in the 
original zone’s file, unless inline-signing is explicitly set.

 Original Message 
From: Jan-Piet Mens via bind-users [mailto:bind-users@lists.isc.org]
Sent: Wednesday, October 26, 2022 at 3:41 PM EDT
To: bind-users@lists.isc.org
Subject: 'inline-signing' might go away and be replaced by dnssec-policy ?


Retried my named.conf with BIND 9.19.7-dev (Development Release)  
which reports:

 26-Oct-2022 21:31:42.021 /private/tmp/b/named.conf:11: 'inline-signing 
yes;' must also be configured explicitly for zones using dnssec-policy without 
a configured 'allow-update' or 'update-policy'. See 
https://kb.isc.org/docs/dnssec-policy-requires-dynamic-dns-or-inline-signing

If I add an allow-update{} or inline-signing{} stanza, the server starts and
neither combination overwrites the primary zone file.

 -JP


--
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: new dnssec zone OK, error "zone_rekey:dns_zone_getdnsseckeys failed: not found" only in local bind logs ?

[PGNet Dev]

hi,


If there are currently no keys that we have to check the DS for, then you may 
still see this log line.


all my zones have now toggled rumoured -> omnipresent.  i took no explicit 
manual action other than letting an arbitrarily long-ish time pass.
it just happened ... eventually.

re: your comment "we have to check the DS for", what exec _forces_ a (re)check 
of keys' DS ?

i'd understood

  rndc dnssec -checkds published ${zone}

to do exactly that.  i.e., check 'NOW'.
and, since the DS were clearly published and available @ my each/all of my 
parental-agents{}, that the state toggle would happen, similarly, 'NOW'. or at 
least NOW-ish.

is that incorrect?
--
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: 'inline-signing' might go away and be replaced by dnssec-policy ?

[PGNet Dev]

the 'inline-signing yes;' is needed IN ADDITION to 'dnssec-policy' in order to
_not_ overwrite original zone files/data on signing.


I cannot confirm that (9.17.22):


sry, fat thumbed copying my reply into email :-/

should have been wrapped in niceties, including "hmm, I can here with 9.18.8 
..."

--
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: 'inline-signing' might go away and be replaced by dnssec-policy ?

[PGNet Dev]

ls -1 keys/dnssec/example.com/
(empty)

ls -1 namedb/primary/example.com*
namedb/primary/example.com.zone<== ORIGINAL, unsigned zone file

cat etc/named.conf
...
zone "example.com" IN {
type master; file "namedb/primary/example.com.zone";
dnssec-policy "test";
key-directory "keys/dnssec/example.com";
update-policy {
grant local-ddns zonesub any;
grant test-key zonesub txt;
};
};
...

rndc reload

ls -al keys/dnssec/example.com/
keys/dnssec/example.com/Kexample.com.+013+22094.key
keys/dnssec/example.com/Kexample.com.+013+22094.private
keys/dnssec/example.com/Kexample.com.+013+22094.state
keys/dnssec/example.com/Kexample.com.+013+51905.key
keys/dnssec/example.com/Kexample.com.+013+51905.private
keys/dnssec/example.com/Kexample.com.+013+51905.state

ls -1 namedb/primary/example.com*
namedb/primary/example.com.zone<== OVERWRITTEN, *signed* zone 
file
namedb/primary/example.com.zone.jnl


--
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: 'inline-signing' might go away and be replaced by dnssec-policy ?

[PGNet Dev]

There are two ways of DNSSEC maintenance in BIND. One is the inline-signing 
approach, that preserves the original zone file. The other is to apply the 
changes directly to the zone (and zone file) and requires the zone to allow 
dynamic updates.
Since the latest release dnssec-policy requires either inline-signing to be set 
to yes, or allow dynamic updates.

I am thinking of adding inline-signing to dnssec-policy, do you think that 
would that be useful?



Yes, from my point of view, that would surely be useful. I would very much 
welcome a configuration option within the dnssec-policy-statement, to globally 
enable inline-signing for all dnssec-signed zones.


If that's an option to preserve the unsigned zone files that will remain & 
retain that capability, then agreed -- a 'global' option within dnssec-policy, with 
option to override per-zone, would be useful in simplifying config.

bottom line:  i'd prefer to retain my flatfile/text unsigned/original zone 
data, and have bind create/push separate, signed data.
--
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: queries for just a few domains fail (NXDOMAIN) for a bind 9.18 non-forwarding config ; forwarding does fix it. problem with 'my' config, or 'their' DNS ?

[PGNet Dev]

AWS are aware of the issue and are just taking a long time to address it.


noted.

pretty sure there's not a %*^$* thing i can do about THAT!


NXDOMAIN for ENTs can also be result of not adding delegating NS records
to the parent zone when both parent and child zones are served by the same
server.  QNAME minimisation exposes lots of errors as it make queries that
aren’t seen without it.  The best way to do QNAME minimisation is to make
NS queries as then you can cache non-existence of the NS RRset at intermediate
nodes but then you run up against toy DNS servers / firewalls that only handle
A and  lookups.



atm, i'll read that as "use 'relaxed'".  at least until i become aware of my 
next self-inflicted damage ;-)

thx o/

--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: A beginner's guide to DNSSEC with BIND 9

[PGNet Dev]

so I'm interested to hear if this will still be supported or what the roadmap 
is for deprecating the ability to hand-edit these files for DNSSEC-enabled 
zones.


+1.  what "he" (Richard) said!  here, or in my 'other thread' ...

will be helpful to know.

--
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: queries for just a few domains fail (NXDOMAIN) for a bind 9.18 non-forwarding config ; forwarding does fix it. problem with 'my' config, or 'their' DNS ?

[PGNet Dev]

QNAME minimisation is a good idea.  It comes in two flavours, relaxed
and strict.  Relaxed tries to cope with some breakages like NXDOMAIN
being returned from ENTs.  Strict doesn’t.


switch to 'relaxed' does, in fact, 'solve' the issue. insofar as, it appears, i 
no longer require the forward-zome workarounds.

that said, do i understand correctly that the Amazon et al responses are, in 
fact, 'breakages'?
and, if so, that i have probly zero-chance of getting them to fix themselves in 
the next century or so?
i.e., is 'relaxed' recommended for the real-world?
--
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: queries for just a few domains fail (NXDOMAIN) for a bind 9.18 non-forwarding config ; forwarding does fix it. problem with 'my' config, or 'their' DNS ?

[PGNet Dev]

hi,


AWS are returning NXDOMAIN instead of NOERROR for empty non terminals. Do you 
have strict
qname minimisation turned on?


yup, i do

...
qname-minimization strict;
...

only because my i understood my reads of

BIND to Add QNAME Minimization
 https://www.isc.org/blogs/bind-to-add-qname-minimization/

&

QNAME Minimization and Your Privacy
 https://www.isc.org/blogs/qname-minimization-and-privacy/

to suggest that it's a GoodIdea(tm).


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

queries for just a few domains fail (NXDOMAIN) for a bind 9.18 non-forwarding config ; forwarding does fix it. problem with 'my' config, or 'their' DNS ?

[PGNet Dev]

i run bind 9.18.8

i use root hints; forwarding is, by default, disabled in config

with this config, i notice that although lookups for (e.g.) *.dock.io are 
available in public NS caches, e.g.

dig A elb-default.us-east-1.aws.dckr.io @1.1.1.1

; <<>> DiG 9.18.8 <<>> A elb-default.us-east-1.aws.dckr.io 
@1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43732
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, 
ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;elb-default.us-east-1.aws.dckr.io. IN  A

;; ANSWER SECTION:
elb-default.us-east-1.aws.dckr.io. 11 IN CNAME  
prodextdefgreen-vggjfqmkkc-41e4710ed557329b.elb.us-east-1.amazonaws.com.

prodextdefgreen-vggjfqmkkc-41e4710ed557329b.elb.us-east-1.amazonaws.com. 11 IN 
A 52.3.144.121

prodextdefgreen-vggjfqmkkc-41e4710ed557329b.elb.us-east-1.amazonaws.com. 11 IN 
A 54.165.156.197

prodextdefgreen-vggjfqmkkc-41e4710ed557329b.elb.us-east-1.amazonaws.com. 11 IN 
A 44.196.175.70

;; Query time: 12 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Tue Oct 25 18:59:05 EDT 2022
;; MSG SIZE  rcvd: 195

if I query at my local NS, i get NXDOMAIN response,

dig A elb-default.us-east-1.aws.dckr.io @10.53.53.53

; <<>> DiG 9.18.8 <<>> A elb-default.us-east-1.aws.dckr.io 
@10.53.53.53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23192
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, 
ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: a1d6686d7992af17010063586abe7c0a67d1ca4adf27 
(good)
;; QUESTION SECTION:
;elb-default.us-east-1.aws.dckr.io. IN  A

;; Query time: 10 msec
;; SERVER: 10.53.53.53#53(10.53.53.53) (UDP)
;; WHEN: Tue Oct 25 19:01:18 EDT 2022
;; MSG SIZE  rcvd: 90


easy to workaround; if i simply forward for that zone,

zone "dckr.io" IN {
type forward; forward only; forwarders 
{1.1.1.1;2606:4700:4700::;1.0.0.1;2606:4700:4700::1001;};
};

& reload, then, local query works fine

dig A elb-default.us-east-1.aws.dckr.io @10.53.53.53

; <<>> DiG 9.18.8 <<>> A elb-default.us-east-1.aws.dckr.io 
@10.53.53.53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29726
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, 
ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 7616190797188ad9010063586afb58e880c12f1fb8ec 
(good)
;; QUESTION SECTION:
;elb-default.us-east-1.aws.dckr.io. IN  A

;; ANSWER SECTION:
elb-default.us-east-1.aws.dckr.io. 60 IN CNAME  
prodextdefgreen-vggjfqmkkc-41e4710ed557329b.elb.us-east-1.amazonaws.com.

prodextdefgreen-vggjfqmkkc-41e4710ed557329b.elb.us-east-1.amazonaws.com. 60 IN 
A 44.196.175.70

prodextdefgreen-vggjfqmkkc-41e4710ed557329b.elb.us-east-1.amazonaws.com. 60 IN 
A 52.3.144.121

prodextdefgreen-vggjfqmkkc-41e4710ed557329b.elb.us-east-1.amazonaws.com. 60 IN 
A 54.165.156.197

;; Query time: 175 msec
;; SERVER: 10.53.53.53#53(10.53.53.53) (UDP)
;; WHEN: Tue Oct 25 19:02:19 EDT 2022
;; MSG SIZE  rcvd: 223

the vast majority of queries to my local server are answered correctly.

but, for three domains (so far ...) -- dock.io, netflix.com & moz.works -- i'm 
having to implement these per-zone forwarding workarounds.

is there an issue here that i can fix/cure in my not-forwarding-by-default 
config, so that these (and others out there too, i suppose ...) queries respond 
correctly ?
if it's pebkac, dunno where to look, yet.

or is it actually a problem on for these domains' DNS, and not much i can do 
about it ... other than workaround, or just default to forwarders ?
--
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

'inline-signing' might go away and be replaced by dnssec-policy ?

[PGNet Dev]

i've read this comment


'inline-signing' might go away and be replaced by dnssec-policy


now a few times, in posts and in docs

currently, WITH 'dnssec-policy' signing enabled & in-use, i've

zone "example.com" IN {
type master; file "namedb/primary/example.com.zone";
dnssec-policy "test";
inline-signing yes;
...

the 'inline-signing yes;' is needed IN ADDITION to 'dnssec-policy' in order to 
_not_ overwrite original zone files/data on signing.  e.g., with the config 
above

cd namedb/primary/
ls -1 *example*
example.com.zone  < THIS is the original, unsigned 
zone data
example.com.zone.jbk
example.com.zone.jnl
example.com.zone.signed   < THIS is the signing-generated 
zone data, which gets propagated
example.com.zone.signed.jnl

without it, the original "example.com.zone" is overwritten with signed data.

is there already config in, or planned for, 'dnssec-policy' that preserves that 
separate-file functionality, preserving the original?
--
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: after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?

[PGNet Dev]

The good news it is not stuck.


What indicator flags that it IS 'stuck'?  Is it explicitly logged?


BIND is waiting to make sure the new DS is also known to the validators. The 
time being evaluated here is the DS TTL, plus parent-propagation-delay, plus 
retire-safety. All these three values are configurable within dnssec-policy.


my current config has

parent-ds-ttl  PT1H;
parent-propagation-delay   PT1H;
retire-safety  PT1H;

@ parental-agents, the DS is cached; ttl appears spec'd other than my set ttl. 
e.g., @ cloudflare, it's 1 day ...

in any case, all of my domains still returned "DSState: rumoured" at < 4 days.
since then, about 1/4 of the domains have flipped from "rumoured" -> 
"omnipresent", with no manual intervention; the rest are still unchanged.

again, i've noticed no actual operational problems -- e.g., queries failing, 
etc -- other than these delays.

seems, tho, i've still got a likely misconfig somewhere in here.



--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?

[PGNet Dev]

I exec

 rndc dnssec -checkds -key 63917 published example.com IN external


with dnssec loglevel -> debug, on exec, in logs

  2022-10-21T16:55:22.690603-04:00 ns named[36683]: 21-Oct-2022 16:55:22.689 
dnssec: debug 1: keymgr: examine KSK example.com/ECDSAP256SHA256/63917 type DS 
in state RUMOURED
  2022-10-21T16:55:22.690608-04:00 ns named[36683]: 21-Oct-2022 16:55:22.689 
dnssec: debug 1: keymgr: can we transition KSK 
example.com/ECDSAP256SHA256/63917 type DS state RUMOURED to state OMNIPRESENT?
  2022-10-21T16:55:22.690615-04:00 ns named[36683]: 21-Oct-2022 16:55:22.689 
dnssec: debug 1: keymgr: dnssec evaluation of KSK 
example.com/ECDSAP256SHA256/63917 record DS: rule1=(~true or true) rule2=(~true 
or true) rule3=(~false or false)
  2022-10-21T16:55:22.690622-04:00 ns named[36683]: 21-Oct-2022 16:55:22.689 
dnssec: debug 1: keymgr: time says no to KSK example.com/ECDSAP256SHA256/63917 
type DS state RUMOURED to state OMNIPRESENT (wait 93600 seconds)

which certainly looks like a 'no'

reason is "time says no", after "dnssec evaluation".

which time is being evaluated here?
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?

[PGNet Dev]

with bind 9.18, config'd for dnssec-policy automated signing, I've a dnssec 
signed zone,

rndc dnssec -status example.com IN external
dnssec-policy: test
current time:  Fri Oct 21 16:14:06 2022

key: 47219 (ECDSAP256SHA256), ZSK
  published:  yes - since Fri Oct 21 15:22:27 2022
  zone signing:   yes - since Fri Oct 21 17:27:27 2022

  Next rollover scheduled on Thu Jan 19 14:22:27 2023
  - goal:   omnipresent
  - dnskey: rumoured
  - zone rrsig: rumoured

key: 63917 (ECDSAP256SHA256), KSK
  published:  yes - since Sat Oct 15 15:52:05 2022
  key signing:yes - since Sat Oct 15 15:52:05 2022

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

key: 43175 (ECDSAP256SHA256), ZSK
  published:  no
  zone signing:   no

  Key has been removed from the zone
  - goal:   hidden
  - dnskey: unretentive
  - zone rrsig: unretentive


note for the KSK, it's ds state,

  - ds: rumoured

I've verified externally that thhe zone's DS RECORD has been pushed to 
registrar->parent, it's fully propagated, and is passing all the 
external/online checks.

reading @ https://kb.isc.org/docs/dnssec-key-and-signing-policy

"Note: If you see the DSState stuck in rumoured after the migration, you 
need to run rndc dnssec -checkds published example.com to tell BIND that the DS is 
already published in the parent zone"

I exec

rndc dnssec -checkds -key 63917 published example.com IN external
KSK 63917: Marked DS as published since 21-Oct-2022 16:19:36.000

rndc reload
server reload successful

and check again,

rndc dnssec -status example.com IN external
...
key: 63917 (ECDSAP256SHA256), KSK
  published:  yes - since Sat Oct 15 15:52:05 2022
  key signing:yes - since Sat Oct 15 15:52:05 2022

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

grep DSState  Kexample.com.+013+63917.state
!!  DSState: rumoured

ds state is still just "rumoured".

What additional steps are needed to update that DSState correctly?
--
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: procedure for re-signing zones on nsec3param change, when using dnssec-policy full automation?

[PGNet Dev]

On 19. 10. 22 19:48, Mark Andrews wrote:

Just reload the server.


+1


with the does the DS record need to be touched? i.e., will the changed to 
nsec3param change the zone's KSK?


Let me add that no, DS record is not affected at all by NSEC or NSEC3.


dnssec-policy management is doing a nice job of making this easy! even if not 
always clear to me in the docs

after the config edit, and reload,

dig example.com nsec3param
...
;; ANSWER SECTION:
exmaple.com.  5   IN  NSEC3PARAM 1 0 0 -
...

and, NO upstream DS RECORD update, all my functional checks seem, so far, to be 
passing.

thx!


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

procedure for re-signing zones on nsec3param change, when using dnssec-policy full automation?

[PGNet Dev]

running

bind 9.18.7

i've enabled dnssec-policy signing

current KSK & ZSK keys had been generated with

dnssec-policy "prod01" {
...
nsec3param iterations 5 optout no salt-length 8;
...
}

noting

Change default for nsec3param to iterations 0 salt-length 0
 https://gitlab.isc.org/isc-projects/bind9/-/issues/2956

Guidance for NSEC3 Parameter Settings
 https://datatracker.ietf.org/doc/rfc9276/

i'm changing that to,

-   nsec3param iterations 5 optout no salt-length 8;
+   nsec3param iterations 0 optout no salt-length 0;

the rfc notes,

"Changing a zone's salt value requires the construction of a complete
 new NSEC3 chain.  This is true both when re-signing the entire zone
 at once and when incrementally signing it in the background where the
 new salt is only activated once every name in the chain has been
 completed."

since dnssec management it 'fully automated' using dnssec-policy, in addition 
to the 'nsec3param' change in named.conf, and a a server reload/restart,  

what's the correct procedure for force re-signing all nsec3 signed zones 'now'?

is changing one of the timing values in the -policy sufficient? and bind9 will 
automate the rest?
or, is a manual intervention with 'dnssec-signzone' required?

in either case, iiuc, re-signing will re-generate zone data with updated RRSIGs 
for published records.
the DS record for each zone, extracted from its KSK, was manually pushed to 
registrar, and subsequently to the zone's approrpiate parent.

with the does the DS record need to be touched? i.e., will the changed to 
nsec3param change the zone's KSK?
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: secure/tls access for statistics-channels ?

[PGNet Dev]

can stats channel be config'd for (only) secure access?
does it use the 'tls' config, or other?


Not at the moment.


ok


Please note the statistics channel must not be exposed to any unauthorized 
access, so the most safe way is to expose it only on localhost anyway - and 
then TLS is just overhead.


yup

exposed in bind conf only on localhost+port,
config'd stunnel as frontend TLS terminator, with TLS cert authentication 
required,
added own-CA self-signed cert,
and works well enough

thx

--
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: new dnssec zone OK, error "zone_rekey:dns_zone_getdnsseckeys failed: not found" only in local bind logs ?

[PGNet Dev]

is there a way to determine what data is being attempted to write to which 
file/location on disk?
or, generally, any more detail about what "error occurred" ?


It will be attempting to write into the key-directory for the zone as defined 
by named.conf. It will be creating a new file and then renaming that to replace 
one of the exisiting files associated with that key, the .private or .state (I 
haven’t looked to see which) with updated content.


hm. thx.

the "key-directory for the zone as defined by named.conf" is correctly permed, 
and where bind9 successfully created/wrote the initial KSK/ZSK files.

hm.  i've got something else going on.  smells like pebkac.

time to try a clean install ...
--
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: new dnssec zone OK, error "zone_rekey:dns_zone_getdnsseckeys failed: not found" only in local bind logs ?

[PGNet Dev]

In addition to what Matthijs said, please make sure that all path components
in /data/chroot/named/keys/dnssec/example.com/  need to 
have correct permissions,
this is easy to get wrong. I've burnt on this too many times.

Easiest way how to test is switching to the user that named runs under and try
changing to the directory and checking if you can access the files.


i've double-checked my perms; if that's the cause, i've missed it :_/

testing without dnssec-policy autosiging, just manually signing,

for an active/healthy, dnssec-signed zone

rndc dnssec -status example.com IN external
dnssec-policy: pgnd
current time:  Sun Oct 16 20:44:05 2022

key: 10729 (ECDSAP256SHA256), ZSK
  published:  yes - since Sat Oct 15 15:52:05 2022
  zone signing:   yes - since Sat Oct 15 15:52:05 2022

  Next rollover scheduled on Sun Oct 30 13:47:05 2022
  - goal:   omnipresent
  - dnskey: omnipresent
  - zone rrsig: rumoured

key: 57122 (ECDSAP256SHA256), KSK
  published:  yes - since Sat Oct 15 15:52:05 2022
  key signing:yes - since Sat Oct 15 15:52:05 2022

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

trying a manual rollover

rndc dnssec -rollover -key 10729 example.com IN external
Error executing rollover command: error occurred writing key to 
disk

where, even with debug logging, all that i see on exec is

2022-10-16T20:56:49.979144-04:00 ns named[2036]: 16-Oct-2022 
20:56:49.977 general: info: received control channel command 'dnssec -rollover 
-key 10729 example.com IN external'

is there a way to determine what data is being attempted to write to which 
file/location on disk?
or, generally, any more detail about what "error occurred" ?


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

secure/tls access for statistics-channels ?

[PGNet Dev]

on

named -v
BIND 9.18.7 (Stable Release) 

i've setup statistics,

statistics-channels {
inet 10.53.53.53 port 5353 allow {
sec_trusted;
};
inet 127.0.0.1 port 5353 allow {
127.0.0.1;
::1;
};
};

nav to

http://10.53.53.53:5353

works as expected; collected stats are correctly displayed

i'm cleaning up my TLS usage, in general

reading here,


https://bind9.readthedocs.io/en/latest/reference.html?highlight=statistics-channels#statistics-channels-block-grammar

https://bind9.readthedocs.io/en/latest/reference.html?highlight=statistics-channels#statistics-channels-block-definition-and-usage

i see no mention of tls support; only http:// links are ref'd in docs.

i _do_ already have a

tls server-tls {...}

in use by my DoT listeners

can stats channel be config'd for (only) secure access?
does it use the 'tls' config, or other?
--
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: new dnssec zone OK, error "zone_rekey:dns_zone_getdnsseckeys failed: not found" only in local bind logs ?

[PGNet Dev]

Which parental-agent to use is up to you. Something you trust.


for the moment, let's say 1.1.1.1


But if you don't have parental-agents set up, the list of keys to check will be empty. 
Hence the "not found" result.


i added

zone "example.com" IN {
type master; file "/namedb/master/example.com.zone";
dnssec-policy "pgnd";
key-directory "/keys/dnssec/example.com";
++  parental-agents { 1.1.1.1; };
update-policy { grant pgnd-external-rndc-key zonesub txt; };
};

but, on restart, still see

dnssec: error: zone example.com/IN/external: 
zone_rekey:dns_zone_getdnsseckeys failed: not found

something additional needed?

--
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: new dnssec zone OK, error "zone_rekey:dns_zone_getdnsseckeys failed: not found" only in local bind logs ?

[PGNet Dev]

This is a log level bug. This log happens when BIND want to check the parental-agents if 
the DS has been published. But if you don't have parental-agents set up, the list of keys 
to check will be empty. Hence the "not found" result.

Thanks for reporting, this will be fixed in the next release, it should be a 
debug log level.


+1 o/

i'd completely missed 'parental-agents' :-/

sounds like i likely *should* have it setup in any case; esp if using 
dnssec-policy key rollovers (i am)

reading


https://bind9.readthedocs.io/en/latest/chapter5.html?highlight=parental-agents#key-rollover

i get the part it plays

unclear though which specific server one should use; in the example txt,

"Here one server, 192.0.2.1, is configured for BIND to send DS queries to, 
to check the DS RRset for dnssec-example during key rollovers. This needs to be a trusted 
server, because BIND does not validate the response."

atm, my registrar/TLD don't support CDS/CDNSKEY (for .com, in this case)

so my DS RECORD gets manually entered @ registrar's web portal.

then, record propagates to roots, which -- eventually -- return RRSIG/RRSET 
data on queries.

for rollover mgmt, what server should be set as parental-agent?
my registrar's?
a root?
something 'big', like cloudflare/1.1.1.1 ?
other?
--
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: new dnssec zone OK, error "zone_rekey:dns_zone_getdnsseckeys failed: not found" only in local bind logs ?

[PGNet Dev]

hi


Think ownership, permission and things like SELinux, AppArmore depending on 
your OS.


on this box, no SELinux or AppArmor

in my named.conf

directory "/namedb/production";

and for my domain's dnssec

key-directory "/keys/dnssec/example.com";

pathnames are relative to chroot.

here, chroot is @ "/data/chroot/named",

ps aux | grep named
named14285  0.0  0.2 526388 67360 ?Ssl  08:47   
0:00 /usr/sbin/named -f -t /data/chroot/named -n 2 -S 1024 -u named -c 
/etc/named.conf

checking,

ls -al \
 /data/chroot/named/namedb/production \
 /data/chroot/named/keys/dnssec/example.com/

access looks ok (?)

/data/chroot/named/keys/dnssec/example.com/:
total 32K
drwxr-xr-x 2 named named 4.0K Oct 12 18:09 ./
drwxr-xr-x 5 named named 4.0K Oct 14 00:22 ../
-rw-r- 1 named named  405 Oct 13 19:14 
Kexample.com.+013+17296.key
-rw-r- 1 named named  215 Oct 13 19:14 
Kexample.com.+013+17296.private
-rw-r- 1 named named  572 Oct 13 19:14 
Kexample.com.+013+17296.state
-rw-r- 1 named named  455 Oct 13 19:14 
Kexample.com.+013+62137.key
-rw-r- 1 named named  235 Oct 13 19:14 
Kexample.com.+013+62137.private
-rw-r- 1 named named  556 Oct 13 19:14 
Kexample.com.+013+62137.state

/data/chroot/named/namedb/production:
total 16K
drwxrwxr-x 2 named named 4.0K Oct 14 08:47 ./
drwxr-xr-x 5 named named 4.0K Oct 14 08:47 ../
-rw--- 1 named named 8.0K Oct 14 08:47 external.nzd
-rw-r- 1 named named0 Oct 14 08:47 managed-keys.bind
--
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

new dnssec zone OK, error "zone_rekey:dns_zone_getdnsseckeys failed: not found" only in local bind logs ?

[PGNet Dev]

i run,

named -v
BIND 9.18.7 (Stable Release) 


i've setup dnssec-policy operation for a number of domain.

keys are all generated, KSK-derived DS Records are pushed to registrar->root, 
and all DNSSEC-analyzer tools online report all's good.

i can see no functional problems. so far. that i'm aware of.

but, in bind logs, locally, I see the following "zone_rekey:dns_zone_getdnsseckeys 
failed: not found" error,

2022-10-14T08:47:23.569556-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.568 dnssec: info: zone example.com/IN/external: generated salt: 
82CSA124A1645B0D
2022-10-14T08:47:23.711869-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.710 dnssec: info: zone example.com/IN/external: reconfiguring zone keys
??  2022-10-14T08:47:23.712653-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: error: zone example.com/IN/external: 
zone_rekey:dns_zone_getdnsseckeys failed: not found
2022-10-14T08:47:23.712663-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: keyring: 
example.com/ECDSAP256SHA256/62137 (policy pgnd)
2022-10-14T08:47:23.712666-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: keyring: 
example.com/ECDSAP256SHA256/17296 (policy pgnd)
2022-10-14T08:47:23.712671-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: DNSKEY example.com/ECDSAP256SHA256/17296 
(KSK) matches policy pgnd
2022-10-14T08:47:23.712674-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: DNSKEY example.com/ECDSAP256SHA256/17296 
(KSK) is active in policy pgnd
2022-10-14T08:47:23.712677-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: DNSKEY example.com/ECDSAP256SHA256/62137 
(ZSK) matches policy pgnd
2022-10-14T08:47:23.712680-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: DNSKEY example.com/ECDSAP256SHA256/62137 
(ZSK) is active in policy pgnd
2022-10-14T08:47:23.712683-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: new successor needed for DNSKEY 
example.com/ECDSAP256SHA256/62137 (ZSK) (policy pgnd) in 2445436 seconds
2022-10-14T08:47:23.712686-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: examine ZSK 
example.com/ECDSAP256SHA256/62137 type DNSKEY in state OMNIPRESENT
2022-10-14T08:47:23.712688-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: ZSK example.com/ECDSAP256SHA256/62137 
type DNSKEY in stable state OMNIPRESENT
2022-10-14T08:47:23.712690-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: examine ZSK 
example.com/ECDSAP256SHA256/62137 type ZRRSIG in state OMNIPRESENT
2022-10-14T08:47:23.712693-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: ZSK example.com/ECDSAP256SHA256/62137 
type ZRRSIG in stable state OMNIPRESENT
2022-10-14T08:47:23.712695-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: examine KSK 
example.com/ECDSAP256SHA256/17296 type DNSKEY in state OMNIPRESENT
2022-10-14T08:47:23.712697-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: KSK example.com/ECDSAP256SHA256/17296 
type DNSKEY in stable state OMNIPRESENT
2022-10-14T08:47:23.712699-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: examine KSK 
example.com/ECDSAP256SHA256/17296 type KRRSIG in state OMNIPRESENT
2022-10-14T08:47:23.712702-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: KSK example.com/ECDSAP256SHA256/17296 
type KRRSIG in stable state OMNIPRESENT
2022-10-14T08:47:23.712704-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: examine KSK 
example.com/ECDSAP256SHA256/17296 type DS in state RUMOURED
2022-10-14T08:47:23.712706-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: can we transition KSK 
example.com/ECDSAP256SHA256/17296 type DS state RUMOURED to state OMNIPRESENT?
2022-10-14T08:47:23.712712-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: dnssec evaluation of KSK 
example.com/ECDSAP256SHA256/17296 record DS: rule1=(~true or true) rule2=(~true 
or true) rule3=(~true or true)

for each/every dnssec-enabled domain

where, in my current named.conf,

dnssec-policy "pgnd" {
keys {
ksk key-directorylifetime unlimitedalgorithm 13;
zsk key-directorylifetime P30D algorithm 13;
};
dnskey-ttl 3600;
publish-safety 1h;
retire-safety  1h;
signatures-refresh P5D;
signatures-validityP2W;
signatures-validity-dnskey P2W;
max-zone-ttl   86400;

Re: Intermittent v9.18 build fails on Fedora COPR buildsys, always in `netmgr_test` ?

[PGNet Dev]

The netmgr unit tests are not meant to run fully in the CI as some of it are 
time sensitive.


a COPR dev managed to provide the FAIL'd test log from a manual COPR build,

cat 
./var/lib/mock/fedora-36-x86_64-1661812240.003689/root/builddir/build/BUILD/bind-9.18.5/build/tests/isc/netmgr_test.log
[==] Running 83 test(s).
[ RUN  ] mock_listenudp_uv_udp_open
[   OK ] mock_listenudp_uv_udp_open
[ RUN  ] mock_listenudp_uv_udp_bind
[   OK ] mock_listenudp_uv_udp_bind
[ RUN  ] mock_listenudp_uv_udp_recv_start
[   OK ] mock_listenudp_uv_udp_recv_start
[ RUN  ] mock_udpconnect_uv_udp_open
[   OK ] mock_udpconnect_uv_udp_open
[ RUN  ] mock_udpconnect_uv_udp_bind
[   OK ] mock_udpconnect_uv_udp_bind
[ RUN  ] mock_udpconnect_uv_udp_connect
[   OK ] mock_udpconnect_uv_udp_connect
[ RUN  ] mock_udpconnect_uv_recv_buffer_size
[   OK ] mock_udpconnect_uv_recv_buffer_size
[ RUN  ] mock_udpconnect_uv_send_buffer_size
[   OK ] mock_udpconnect_uv_send_buffer_size
[ RUN  ] udp_noop
[   OK ] udp_noop
[ RUN  ] udp_noresponse
[   OK ] udp_noresponse
[ RUN  ] udp_timeout_recovery
[   OK ] udp_timeout_recovery
[ RUN  ] udp_recv_one
[   OK ] udp_recv_one
[ RUN  ] udp_recv_two
[   OK ] udp_recv_two
[ RUN  ] udp_recv_send
[   OK ] udp_recv_send
[ RUN  ] udp_recv_half_send
[   OK ] udp_recv_half_send
[ RUN  ] udp_half_recv_send
[   OK ] udp_half_recv_send
[ RUN  ] udp_half_recv_half_send
[   OK ] udp_half_recv_half_send
[ RUN  ] tcp_noop
[   OK ] tcp_noop
[ RUN  ] tcp_noresponse
[   OK ] tcp_noresponse
[ RUN  ] tcp_timeout_recovery
[   OK ] tcp_timeout_recovery
[ RUN  ] tcp_recv_one
[   OK ] tcp_recv_one
[ RUN  ] tcp_recv_two
[   OK ] tcp_recv_two
[ RUN  ] tcp_recv_send
[   OK ] tcp_recv_send
[ RUN  ] tcp_recv_half_send
[   OK ] tcp_recv_half_send
[ RUN  ] tcp_half_recv_send
[   OK ] tcp_half_recv_send
[ RUN  ] tcp_half_recv_half_send
[   OK ] tcp_half_recv_half_send
[ RUN  ] tcp_recv_send_sendback
[   OK ] tcp_recv_send_sendback
[ RUN  ] tcp_recv_half_send_sendback
[   OK ] tcp_recv_half_send_sendback
[ RUN  ] tcp_half_recv_send_sendback
[   OK ] tcp_half_recv_send_sendback
[ RUN  ] tcp_half_recv_half_send_sendback
[   OK ] tcp_half_recv_half_send_sendback
[ RUN  ] tcp_recv_one_quota
[   OK ] tcp_recv_one_quota
[ RUN  ] tcp_recv_two_quota
[   OK ] tcp_recv_two_quota
[ RUN  ] tcp_recv_send_quota
[   OK ] tcp_recv_send_quota
[ RUN  ] tcp_recv_half_send_quota
[   OK ] tcp_recv_half_send_quota
[ RUN  ] tcp_half_recv_send_quota
[   OK ] tcp_half_recv_send_quota
[ RUN  ] tcp_half_recv_half_send_quota
[   OK ] tcp_half_recv_half_send_quota
[ RUN  ] tcp_recv_send_quota_sendback
[   OK ] tcp_recv_send_quota_sendback
[ RUN  ] tcp_recv_half_send_quota_sendback
[   OK ] tcp_recv_half_send_quota_sendback
[ RUN  ] tcp_half_recv_send_quota_sendback
[   OK ] tcp_half_recv_send_quota_sendback
[ RUN  ] tcp_half_recv_half_send_quota_sendback
[   OK ] tcp_half_recv_half_send_quota_sendback
[ RUN  ] tcpdns_recv_one
[   OK ] tcpdns_recv_one
[ RUN  ] tcpdns_recv_two
[   OK ] tcpdns_recv_two
[ RUN  ] tcpdns_noop
[   OK ] tcpdns_noop
[ RUN  ] tcpdns_noresponse
[   OK ] tcpdns_noresponse
[ RUN  ] tcpdns_timeout_recovery
[   OK ] tcpdns_timeout_recovery
 

Re: Intermittent v9.18 build fails on Fedora COPR buildsys, always in `netmgr_test` ?

[PGNet Dev]

You might want to set the CI=true environment variable to reduce the set of the 
netmgr unit tests to just the more reliable subset.


thx, trying that now @ COPR


with

export CI=true

in .spec @


https://src.fedoraproject.org/fork/pgfed/rpms/bind/blob/rawhide/f/bind.spec#_357

similarly random.intermittent FAILs,

 3x OK, 0x FAIL  
https://copr.fedorainfracloud.org/coprs/pgfed/bind-FORK/build/4784746/
 1x OK, 2x FAIL  
https://copr.fedorainfracloud.org/coprs/pgfed/bind-FORK/build/4784745/
 0x OK, 3x FAIL  
https://copr.fedorainfracloud.org/coprs/pgfed/bind-FORK/build/4784744/
 1x OK, 2x FAIL  
https://copr.fedorainfracloud.org/coprs/pgfed/bind-FORK/build/4784743/

either the export is incorrectly def'd/placed, or insufficient

--
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: Intermittent v9.18 build fails on Fedora COPR buildsys, always in `netmgr_test` ?

[PGNet Dev]

The netmgr unit tests are not meant to run fully in the CI as some of it are 
time sensitive.

You might want to set the CI=true environment variable to reduce the set of the 
netmgr unit tests to just the more reliable subset.


thx, trying that now @ COPR

in the case that it does the trick, should that be dealt with in general in the 
.spec itself, perhaps detecting build env?  or preferably in the specific 
buildsys' env, set, e.g., by rpm macros ... ?

and, will that CI=true export likely still be the case for the upcoming 
per-transport separate tests,

 
https://github.com/isc-projects/bind9/commit/37a1be5acc32244cec03cedc1bd46bc4aa0fbc18

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

Intermittent v9.18 build fails on Fedora COPR buildsys, always in `netmgr_test` ?

[PGNet Dev]

I'm building bind9 (v9.18.5, atm) on Fedora's COPR infrastructure.

Building for Fedora 36, 37 & Rawhide, the builds FAIL randomly/intermittently 
here

For example, with no changes to any source/spec, simply triggering rebuilds, 
over a period of just a few hours,


 Time   F36   F37   Rawhide  build URL
        ---  --
 2022-08-29 15:58 EDT   OKFAIL  OK   
https://copr.fedorainfracloud.org/coprs/pgfed/bind/build/4784469/

 2022-08-29 14:23 EDT   FAIL  OKOK   
https://copr.fedorainfracloud.org/coprs/pgfed/bind/build/4784210/

 2022-08-29 11:49 EDT   OKOKOK   
https://copr.fedorainfracloud.org/coprs/pgfed/bind/build/4776394/

I'm trying to get a handle on cause ...

Local builds on my own infrastructure are always successful; the issue's only 
on COPR.

The FAILs are always in `netmgr_test` unittests ...

looking at netmgr test source, my as-yet-unfounded suspicion is that these 
timeouts

  
https://github.com/isc-projects/bind9/blob/v9_18_5/tests/isc/netmgr_test.c#L116

are intermittently hitting limits -- only in COPR/online.  perhaps for specific 
transport?

I also note that -- in main, upstream, 3 days ago -- netmgr tests are being 
split up, into separate per-transport tests,

  
https://github.com/isc-projects/bind9/commit/37a1be5acc32244cec03cedc1bd46bc4aa0fbc18

I'm not clear what specific problem is being solved by that split, but imagine 
that it might well have an effect on builds @ COPR.

I've not been able to get detailed test FAIL logs from COPR builds (local 
builds do not FAIL).  currently, @ #fedora-buildsys, did manage to get a 
reproducer of the build FAIL; I'm hoping I might get access to those FAIL logs 
via a manual COPR build.


Anyone here seen similar issues with netmgr, or maybe have a clue?

Fwiw, I've initially filed at RH BZ already:

  https://bugzilla.redhat.com/show_bug.cgi?id=2122010

; no response there yet.
--
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: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

[PGNet Dev]

@jpmens was kind enough to share the original basis for the simple perl script 
referenced above,
which to recollection was 'mainly an example taken from the Net::DNS 
documentation.'

Logging of CDS/CDNSKEY generation for workflow 
https://gitlab.isc.org/isc-projects/bind9/-/issues/1748

#!/usr/bin/perl -w

use strict;
use Net::DNS::Nameserver;
 
sub notification {

my ($qname, $qclass, $qtype, $peer, $packet) = @_;

# We are being notified (NOTIFY) for domain $qname.

print "WOW. Got NOTIFY for $qname!\n";

# Submit this notification to your monitoring system. In
# the case of Nagios, you could update a database table
# from which it later reads the result, or you can
# implement a passive notification, etc.

return ('NOERROR', [], [], [],
   { aa => 1, opcode => 'NS_NOTIFY_OP'});
}

sub handler {
my ($qname, $qclass, $qtype, $peer) = @_;
my (@ans, @auth, @add);

return ('SERVFAIL', \@ans, \@auth, \@add);
}
 
my $ns = Net::DNS::Nameserver->new(

LocalAddr=> '127.0.0.2',
LocalPort=> 53,
ReplyHandler => \,  # Unused, but needs defining
NotifyHandler => \,
Verbose  => 0,
Debug=> 0,
) || die("Can't create nameserver object: $!");

$ns->main_loop;



He also mentioned

Logging of CDS/CDNSKEY generation for workflow
 https://gitlab.isc.org/isc-projects/bind9/-/issues/1748

which requests:

Would it be possible to log CDS/CDNSKEY generation in such a way as that a 
"simple" workflow can be implemented in order to create tooling which reacts on 
the log and performs a dynamic update on a parent zone.
Whenever a CDS/CDNSKEY is published in a child zone, BIND could create 
a log record indicating for which zone this has occurred.

and appears to have been implemented (?), but not committed/released.
___
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: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

[PGNet Dev]

On 6/16/21 7:04 AM, Tony Finch wrote:

Maaybe. Bare NOTIFY can say which zone's keys have changed, but not
what the state transition is, so it isn't what I would consider to be a
complete solution.


Pulling the thread a bit more, Jan-Piet Mens @

 "Alert, backup, whatever on DNS NOTIFY with nsnotifyd"
  https://jpmens.net/2015/06/16/alert-on-dns-notify/

appears to refer to that same challenge,

 "This is a very welcome alternative to doing it in Perl, as I did when I wanted
  to be notified of new and changed KSK in a zone."

  -->

   "Being notified of new and changed KSK in a zone"

https://jpmens.net/2015/03/05/being-notified-of-new-an-changed-ksk-in-the-zone/

& implements a "key-listen.pl" script that listens for & reacts to KSK changes.
From just reading (don't see the source code?), it's triggered by the NOTIFY 
from NSD and subsequently polls for DNSSKEY RRSet ...

I don't yet know if what specific state transition info is carried in that 
_NOTIFY_, or it it's sufficient.
___
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: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

[PGNet Dev]

On 6/15/21 4:40 PM, Tony Finch wrote:

How should named say that a key has changed? It's a multithreaded program
so it can't fork (not without a single-threaded helper process) so maybe
it should fire off a message to a socket that the script machinery can
listen to. (Maybe abuse NOTIFY for the purpose?) The feedback loop can be
closed using an rndc command.


With a NOTIFY, something like _your_ old listener

 nsnotifyd: handle DNS NOTIFY messages by running a command
  https://dotat.at/prog/nsnotifyd/
  https://github.com/fanf2/nsnotifyd

gets interesting.

Don't know yet how dusty that is, or relevant to current bind 9.16+, etc. --
-- but the general 'respond immediately to a NOTIFY' sounds quite useful.

___
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: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

[PGNet Dev]

On 6/10/21 8:38 AM, Tony Finch wrote:

PGNet Dev  wrote:


Has anyone here on-list figured out how to hook bind's internal signing
process to *trigger* and external script to exec those API pushes?


I have not, and I also want to be able to do this, and I also want
scripting hooks for whenever any keys change so that I can stash them
somewhere safer.




Tony.


fyi, @

 automation of DS Record submit to registrar/parent, integrated with 'new' 
kasp/dnssec-policy support in bind
  https://gitlab.isc.org/isc-projects/bind9/-/issues/1890

the current feedback is " ... we think the best way is that the user scripts this by 
them self ... "

and follows with " ... it is more likely that the CDS/CDNSKEY polling will be more 
common than pushing DS updates. A couple of TLDs have implemented this already and it 
looks like there is some movement on this topic in the Registrar world."

Of course inaction by TLDs & Registrars has been years-long ...

___
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: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

[PGNet Dev]

On 6/10/21 1:55 PM, Tony Finch wrote:

PGNet Dev  wrote:


fyi, perhaps keep an eye on this:

   https://gitlab.isc.org/isc-projects/bind9/-/wikis/BIND-9-PKCS11


hmm, maybe, but it's my Spock eye with a single arched eyebrow


hehe.

well, I _did_ just suggest "keep an eye on it", not "wait for it" or "hold your 
breath" ! ;-)


___
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: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

[PGNet Dev]

On 6/10/21 8:38 AM, Tony Finch wrote:

I have not, and I also want to be able to do this, and I also want
scripting hooks for whenever any keys change so that I can stash them
somewhere safer.


fyi, perhaps keep an eye on this:

  https://gitlab.isc.org/isc-projects/bind9/-/wikis/BIND-9-PKCS11

seems like a point solution to the more generic problem, but does touch on 
softhsm integration.


proper process hooks should enable the option to stash where you want to -- fs, 
git, softhsm, hashicorp vault, h/w hsm, etc etc.

___
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

hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

[PGNet Dev]

DNSSEC signing using Bind 9.16.x's internal/automated key mgmt correctly 
generates PublishCDS, DSChange, DSState data for the KSK .state.


Subsequent published data correctly contains CDS/CDNSKEY data.

Most registrars are still incapable of polling for updates, and require, at 
best, API push of DS Records for promotion to TLD parent.


("We're looking into it ..." and "You should expect it by the end of year ..." 
seems to be the most common, years-long excuses ... er ... promises I've gotten).


About a year ago, I'd submitted

	"automation of DS Record submit to registrar/parent, integrated with 'new' 
kasp/dnssec-policy support in bind"

 https://gitlab.isc.org/isc-projects/bind9/-/issues/1890

So far, no visible progress.

Before bind's current, integrated approach, I'd done some sloppy scripting with 
opendnssec, and it ended up being a fragile mess.


I can certainly can set up kludgy, async polling scripts &/or cronjobs to do the 
same with bind; It seems so 1990s :-/ Just looking for something more integrated.



Short of the registrars getting a clue anytime soon, or moving to .CZ/.CH where 
CDS/CDNSKEY polling seems uniquely doable ...


Has anyone here on-list figured out how to hook bind's internal signing process 
to *trigger* and external script to exec those API pushes?


Also, input/comment from devs here, &/or @ #1890 would be appreciated.
___
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: RHEL, Centos, Fedora rpm 9.16.6

[PGNet Dev]

On 8/20/20 11:45 AM, Carl Byington via bind-users wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> https://www.five-ten-sg.com/mapper/bind contains links to the source
> rpms, and build instructions.

How/why are these^ generally different than the isc-maintained pkgs at

https://copr.fedorainfracloud.org/coprs/isc/bind/

?

I do understand atm the 'official' pkgs don't yet include the 9.16.6 build ... 
which, of course, is a _primary_ difference.

Are they otherwise unrelated?

___
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: New BIND releases ... 9.16.4: build, 'fatal error: lmdb.h: No such file or directory'

[PGNet Dev]

> but whether lmdb inclusion/usage now _functions_ correctly with that^ 
> cleanup, i have yet to verify.
> checking now ...

iiuc @

https://bind9.readthedocs.io/en/latest/manpages.html
"The configuration is saved in a file called viewname.nzf (or, if 
named(8) is compiled with liblmdb, an LMDB database file called viewname.nzd)."


the 'nzd2nzf'

system/nzd2nzf/prereq.sh
if [ -z "$NZD" ]; then
echo_i "This test requires LMDB support (--with-lmdb)"
exit 255
fi

tests that lmdb function -- 1st to create, then convert, the .nzd.  complete?  
dunno ...

in any case, with that^ workaround, lmdb test looks ok

sh run.sh nzd2nzf
S:nzd2nzf:2020-06-18T22:10:47-0700
T:nzd2nzf:1:A
A:nzd2nzf:System test nzd2nzf
I:nzd2nzf:PORTRANGE:5300 - 5399
I:nzd2nzf:starting servers
I:nzd2nzf:querying for non-existing zone data (1)
I:nzd2nzf:adding a new zone into default NZD using rndc addzone 
(2)
I:nzd2nzf:querying for existing zone data (3)
I:nzd2nzf:stopping ns1
I:nzd2nzf:dumping _default.nzd to _default.nzf (4)
I:nzd2nzf:checking that _default.nzf contains the expected 
content (5)
I:nzd2nzf:deleting _default.nzd database
I:nzd2nzf:starting ns1 which should migrate the .nzf to .nzd
I:nzd2nzf:querying for zone data from migrated zone config (6)
I:nzd2nzf:exit status: 0
I:nzd2nzf:stopping servers
R:nzd2nzf:PASS
E:nzd2nzf:2020-06-18T22:10:54-0700

___
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: New BIND releases ... 9.16.4: build, 'fatal error: lmdb.h: No such file or directory'

[PGNet Dev]

this

configure.ac
AC_MSG_CHECKING(for lmdb library)
AC_ARG_WITH(lmdb,
AS_HELP_STRING([--with-lmdb[=PATH]],
   [build with LMDB library [yes|no|path]]),
use_lmdb="$withval", use_lmdb="auto")

have_lmdb=""
case "$use_lmdb" in
no)
LMDB_LIBS=""
;;
auto|yes)
for d in /usr /usr/local /opt/local
do
if test -f "${d}/include/lmdb.h"
then
if test ${d} != /usr
then
LMDB_CFLAGS="-I ${d}/include"
!!  LMDB_LIBS="-L${d}/lib"
fi
have_lmdb="yes"
fi
done
;;
*)
if test -f "${use_lmdb}/include/lmdb.h"
then
LMDB_CFLAGS="-I${use_lmdb}/include"
!!  LMDB_LIBS="-L${use_lmdb}/lib"
have_lmdb="yes"
else
AC_MSG_ERROR([$use_lmdb/include/lmdb.h not found.])
fi
;;
esac


is naive. it ignores commonplace multiarch support.



with =path enabled on config, generated Makefile is just wrong

egrep "^LMDB" Makefile
LMDB_CFLAGS = -I/usr/local/lmdb/include
LMDB_LIBS = -L/usr/local/lmdb/lib none required



bind advertises

./configure --help | grep -i LMDB
--with-lmdb=PATHbuild with LMDB library [yes|no|path]

it simply fails to work as advertised.

> you can use and adjust the .pc file from any Linux distribution package

of course you can.

it's here

pkg-config --libs --cflags lmdb
-I/usr/local/lmdb/include -L/usr/local/lmdb/lib64 -llmdb

> LMDB support in BIND 9 comes with pkg-config support too

there's NO such option advertised by bind configure, as

LMDB_CFLAGS
  C compiler flags for LMDB, overriding pkg-config
LMDB_LIBS
  linker flags for LMDB, overriding pkg-config

it's simply not used by this bind build

grep PKG_CHECK `grep -rln PKG_CHECK .` | grep -i lmdb
(empty)

& no mention at all of it in source

grep -i lmdb `grep -rlni lmdb .` | grep -i pkg
(empty)

this

--with-openssl=/usr/local/openssl

works.
this,

--with-lmdb=/usr/local/lmdb

does not.

That has _nothing_ to do with 'LMDB upstream'


>  Did you came to get help or to argue?

neither.

> It’s really not our fault the LMDB upstream decided to make it hard to use 
> the library.

::facepalm::


this

tree /usr/local/lmdb
/usr/local/lmdb
...
├── include
│   └── lmdb.h
...
├── lib64
│   ├── liblmdb.a
│   └── liblmdb.so
...

is about as simple as it gets.

fix it, remove it, or leave it as is -- your product, your choice.

good luck.
___
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: New BIND releases ... 9.16.4: build, 'fatal error: lmdb.h: No such file or directory'

[PGNet Dev]

On 6/18/20 6:34 AM, Matt Pallissard wrote:
> I'd imagine you want CPPFLAGS here.  or you can export C_INCLUDE_PATH
...
> Edit:
 `s/CPPFLAGS/CFLAGS`


specifically adding '-I/usr/local/lmdb/include' to $CFLAGS makes the build 
unhappy, here.

but, yep! ... there _is_ hoop-jumping that appears to workaround the WONTFIX 
silliness^^ ...

with lmdb installed as

tree /usr/local/lmdb
/usr/local/lmdb
├── bin
│   ├── mdb_copy
│   ├── mdb_drop
│   ├── mdb_dump
│   ├── mdb_load
│   └── mdb_stat
├── include
│   └── lmdb.h
├── lib
├── lib64
│   ├── liblmdb.a
│   └── liblmdb.so
├── man
└── share
└── man
└── man1
├── mdb_copy.1
├── mdb_drop.1
├── mdb_dump.1
├── mdb_load.1
└── mdb_stat.1

setting @ bind configure

--with-lmdb=/usr/local/lmdb

to avoid

checking for lmdb library... configure: error: include/lmdb.h not found.

and to ensure the feature is (at least) _reported_ as enabled

...

===
Configuration summary:

---
Optional features enabled:
...
LMDB database to store configuration for 'addzone' zones 
(--with-lmdb)
...

---
Features disabled or unavailable on this platform:
...

then just this

CPPFLAGS= ... -I/usr/local/lmdb/include ...

LDFLAGS=... -L/usr/local/lmdb/lib64 -llmdb ...

is sufficient add'n to general flags

still to make add'l adjustments.
namely, to just completely circumvent the src code mess that results in,

LMDB_CFLAGS = -I/usr/local/lmdb/include
LMDB_LIBS = -L/usr/local/lmdb/lib none required

and build breakage, applying to clean source,

patch << 'EOF'
--- configure.ac.ORIG   2020-06-10 14:01:43.0 -0700
+++ configure.ac2020-06-18 09:45:42.142523855 -0700
@@ -1274,6 +1274,8 @@
 else
AC_MSG_RESULT(no)
 fi
+LMDB_CFLAGS="-I/usr/local/lmdb/include"
+LMDB_LIBS="-L/usr/local/lmdb/lib64 -llmdb"
 AC_SUBST([LMDB_CFLAGS])
 AC_SUBST([LMDB_LIBS])
EOF

then, of course,

./autogen.sh

now, after config, correctly

s|^LMDB_CFLAGS =.*|LMDB_CFLAGS = -I/usr/local/lmdb/include|g
s|^LMDB_LIBS =.*|LMDB_LIBS = -L/usr/local/lmdb/lib64 -llmdb|g

on subsequent build, there's no longer any 'fatal error',

In file included from server.c:131:
/usr/local/src/bind-9.16.4/lib/dns/include/dns/lmdb.h:12:10: fatal 
error: lmdb.h: No such file or directory
   12 | #include 
  |  ^~~~
compilation terminated.

and, on install, named runs/functions

named -v
BIND 9.16.4 (Stable Release) 

lmdb lib is linked,

ldd `which named` | grep lmdb
liblmdb.so => /usr/local/lmdb/lib64/liblmdb.so 
(0x7fedf088b000)

but whether lmdb inclusion/usage now _functions_ correctly with that^ cleanup, 
i have yet to verify.
checking now ...

___
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: New BIND releases ... 9.16.4: build, 'fatal error: lmdb.h: No such file or directory'

[PGNet Dev]

On 6/17/20 9:48 PM, Ondřej Surý wrote:
> Virtually everybody except upstream has modified LMDB to follow a normal 
> directory layout and BIND expect that.
> You should just move the header files and library to /usr/local/include and 
> /usr/local/lib respectively.

That's just a silly statement.

1st, /usr/local/lib is NOT a 'normal directory' layout for a number of distros 
-- /usr/local/lib64 is.  That assumption in bind's code is just wrong.

Software should link against the libs, and include the headers, you TELL it to 
-- not what it arbitrarily 'expects'.

Finally, if that's BIND's 'expectation', why does bind even have a =path config 
option for it?

What's the basis for arbitrary choice of bind using pkg-config for some pkgs, 
providing well-functioning _CFLAGS/_LDFLAGS/_LIBS overrides for others -- but 
in the case of lmdb, neither -- just an 'expectation'?
___
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: New BIND releases ... 9.16.4: build, 'fatal error: lmdb.h: No such file or directory'

[PGNet Dev]

On 6/17/20 7:20 PM, PGNet Dev wrote:
> to 9.16.4, with my usual build config, including
> 
>   --with-lmdb=/usr/local/lmdb \
> 
> where,
> 
>   tree /usr/local/lmdb
>   /usr/local/lmdb
>   ├── bin
>   │   ├── mdb_copy
>   │   ├── mdb_drop
>   │   ├── mdb_dump
>   │   ├── mdb_load
>   │   └── mdb_stat
>   ├── include
> !!│   └── lmdb.h
>   ├── lib
>   ├── lib64
>   │   ├── liblmdb.a
>   │   └── liblmdb.so
>   ├── man
>   └── share
>   └── man
>   └── man1
>   ├── mdb_copy.1
>   ├── mdb_drop.1
>   ├── mdb_dump.1
>   ├── mdb_load.1
>   └── mdb_stat.1
> 

I notice, now, after configure,


egrep "^LMDB" Makefile
  LMDB_CFLAGS = -I/usr/local/lmdb/include
  LMDB_LIBS = -L/usr/local/lmdb/lib none required


which certainly isn't correct.

checking further ...
___
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: New BIND releases ... 9.16.4: build, 'fatal error: lmdb.h: No such file or directory'

[PGNet Dev]

On 6/17/20 12:11 PM, Michael McNally wrote:
>9.16.4  - 
> https://downloads.isc.org/isc/bind9/9.16.4/RELEASE-NOTES-bind-9.16.4.html

on

lsb_release -rd
Description:openSUSE Leap 15.1
Release:15.1

with

gcc --version
gcc (SUSE Linux) 10.1.1 20200515 [revision 
b0461f44076c26ced5526e48d4620b8ea026cfd6]

upgrading from 9.16.3

named -v
BIND 9.16.3 (Stable Release) 

to 9.16.4, with my usual build config, including

--with-lmdb=/usr/local/lmdb \

where,

tree /usr/local/lmdb
/usr/local/lmdb
├── bin
│   ├── mdb_copy
│   ├── mdb_drop
│   ├── mdb_dump
│   ├── mdb_load
│   └── mdb_stat
├── include
!!  │   └── lmdb.h
├── lib
├── lib64
│   ├── liblmdb.a
│   └── liblmdb.so
├── man
└── share
└── man
└── man1
├── mdb_copy.1
├── mdb_drop.1
├── mdb_dump.1
├── mdb_load.1
└── mdb_stat.1


build now fails @ "fatal error: lmdb.h: No such file or directory"

...
libtool: compile:  /usr/bin/gcc-10 -include 
/usr/local/src/bind-9.16.4/config.h -I/usr/local/src/bind-9.16.4 -I../.. 
-I./include -I./unix/include -I. -I/usr/local/src/bind-9.16.4/lib/ns/include 
-I../../lib/ns/include -I/usr/local/src/bind-9.16.4/lib/dns/include 
-I../../lib/dns/include -I/usr/local/openssl11/include 
-I/usr/local/src/bind-9.16.4/lib/bind9/include -I../../lib/bind9/include 
-I/usr/local/src/bind-9.16.4/lib/isccfg/include -I../../lib/isccfg/include 
-I/usr/local/src/bind-9.16.4/lib/isccc/include -I../../lib/isccc/include 
-I/usr/local/src/bind-9.16.4/lib/isc/include -I../../lib/isc 
-I../../lib/isc/include -I../../lib/isc/unix/include 
-I../../lib/isc/pthreads/include -I/usr/local/openssl11/include 
-I/usr/include/json-c -I/usr/include/libxml2 -I/usr/local/include -O3 -Wall 
-fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables 
-fmessage-length=0 -grecord-gcc-switches -march=native -mtune=native -fPIC 
-DPIC -D_GNU_SOURCE -fno-strict-aliasing -Wall -pthread -fPIC -W -Wall 
-Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith 
-Wno-missing-field-initializers -fno-strict-aliasing -DPRODUCT=\"BIND\" 
-DVERSION=\"9.16.4\" -c ./server.c  -fPIC -DPIC -o .libs/server.o
In file included from ./server.c:131:
/usr/local/src/bind-9.16.4/lib/dns/include/dns/lmdb.h:12:10: fatal 
error: lmdb.h: No such file or directory
   12 | #include 
  |  ^~~~
compilation terminated.
make[2]: *** [Makefile:569: server.lo] Error 1
make[2]: Leaving directory '/usr/local/src/bind-9.16.4/bin/named'
make[1]: *** [Makefile:81: subdirs] Error 1
make[1]: Leaving directory '/usr/local/src/bind-9.16.4/bin'
make: *** [Makefile:86: subdirs] Error 1


but checking,

ls -al /usr/local/lmdb/include/lmdb.h
-rw-r--r-- 1 root root 75K Jun 15 18:18 
/usr/local/lmdb/include/lmdb.h

and

echo $LDFLAGS
-L/usr/local/openssl11/lib64 
-Wl,-rpath,/usr/local/openssl11/lib64 -lssl -lcrypto -L/usr/local/lmdb/lib64 
-Wl,-rpath,/usr/local/lmdb/lib64 -L/usr/local/lib64 -Wl,-rpath,/usr/local/lib64

echo $CPPFLAGS
-I/usr/local/include -I/usr/local/openssl11/include 
-I/usr/local/lmdb/include -I/usr/include


fwiw, drop back to 9.16.3 is still an OK build


___
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: automating DS Record submit to parent with 'new' kasp/dnssec-policy support in bind?

[PGNet Dev]

On 5/27/20 11:56 AM, Ondřej Surý wrote:
> Please submit a feature request to our GitLab instance.
https://gitlab.isc.org/isc-projects/bind9/-/issues/1890




___
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: automating DS Record submit to parent with 'new' kasp/dnssec-policy support in bind?

[PGNet Dev]

On 5/26/20 4:50 PM, Mark Andrews wrote:
> This is where we need to get the registrars to follow standards.  They are 
> written
> so everyone doesn’t have to cobble together ad-hoc solutions.  Hourly scans 
> of all
> the DNSSEC delegations by the registrars would do.
> 
> push solutions

sounds reasonable. at very least, better than nothing.

in the absence of a standards-based solution, any options for hooks in bind to 
external scripts, even if ad-hoc?

e.g., "if when change in DS Record in local bind, then fire this external 
script which will manage the DS submit/withdraw via API to registrar"

a completely de-coupled solution, independent of bind itself, is doable -- but 
again, ad-hoc, and seems a step backwards given the nice progress with 
dnssec-policy/kasp simplifications in recent versions.

if that's all there is, know of any existing, proven ad-hoc solutions?
___
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

automating DS Record submit to parent with 'new' kasp/dnssec-policy support in bind?

[PGNet Dev]

i'm migrating/implementing the new `dnssec-policy` usage & KASP workflow in my 
bind 9.16.3.

the new policy does a nice job of streamlining the signing/key mgmt.

after key generation/rotation, the 'last step' is submitting new/changed DS 
Records to the relevant registrar

i'd like to automate the process of submitting generated DS Records to the 
registrar/parent using a capable registrar's DNSSEC API.

as i understand, there is neither any mechanism in Bind for automating the DS 
Record submit, nor is there
an external hook mechanism to external scripts that can handle the task.

offline, it's been suggested to me that with the current version of bind, a 
'best' approach would be to write a simple script that checks for the existence 
of the CDS/CDNSKEY RRset in each signed zone.

then, when a new record is added, trigger a submission of the DS to the parent. 
and, similarly, when a record is removed, trigger a withdrawal of the DS.

rather than re-inventing the wheel ... i'm guessing i'm not the only one who'd 
like to automate this.



has anyone here done this effectively already, with a script/solution that can 
be shared?

are there any plans in place, or existing dev discussion, to address this 
within bind itself?
___
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: Cannot build on macOS 10.15 (Catalina)

[PGNet Dev]

On 4/28/20 12:21 PM, Ondřej Surý wrote:
> On Linux, just put the path to /etc/ld.so.conf.d/local.conf and that should
> do the trick. I don’t know how to configure the dynamic linker on macOS.

runtime dynamic linked paths, subject to ENV var changes, are, imo, simply a 
bad idea/recommendation. particularly for servers where you want the bins 
linked with the libs you want/specify, and never anything else.

fyi,

  https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

 "...
  LD_LIBRARY_PATH is handy for development and testing, but shouldn't be 
modified by an installation process for normal use by normal users;
  ..."

and,

  http://xahlee.info/UnixResource_dir/_/ldpath.html


fwiw, rpath'ing with bind, usually in LDFLAGS to avoid sometimes/historically 
flaky collisions with the lib path assumptions in autofoo & pkg-config config , 
has worked fine here for quite awhile; e.g., for openssl, lmdb, geoip & libuv.

$0.02 & ymmv.
___
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 v9.16.2 build, inconsistent GeoIP2 configuration options usage ?

[PGNet Dev]

On 4/15/20 2:46 PM, PGNet Dev wrote:
> On 4/15/20 1:50 PM, Ondřej Surý wrote:
>> you are right this is a bit confusing, but you need to specify both:
>>
>> --enable-geoip (as the feature independent of used libraries)
>> --with-maxmindsb (where to find the libraries)
> 
> thx
> 
> i'd also suggest

and, of course ... 'maxminddb' consistently everywhere. my typing's atrocious!




___
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 v9.16.2 build, inconsistent GeoIP2 configuration options usage ?

[PGNet Dev]

On 4/15/20 1:50 PM, Ondřej Surý wrote:
> you are right this is a bit confusing, but you need to specify both:
> 
> --enable-geoip (as the feature independent of used libraries)
> --with-maxmindsb (where to find the libraries)

thx

i'd also suggest 

-   --with-maxmiddb

+   --with-libmaxmiddb


to match

  pkg-config --list-all | grep max
libmaxminddb   libmaxminddb - C library for the MaxMind DB 
file format



this

  --with-maxmindsb

suggests to enter the location of the DBs (as spec'd with 'geoip-directory' in 
named.conf)

doing so will pass config with no error, but then FAIL in 'make' step.

shouldn't config _check_ for a valid lib in any path spec'd in 

  --with-maxmindsb=/path/to/

?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

bind v9.16.2 build, inconsistent GeoIP2 configuration options usage ?

[PGNet Dev]

cosmetic config error

building 9.16.2, config options include

  --disable-geoip support GeoIP2 geolocation ACLs if available
  [default=yes]

(this^^ is confusing usage; do you DISABLE-geoip in order TO 'support GeoIP2 
geolocation ACLs if available' ?
 shouldn't that be "--enable-geoip" [default=yes]?)



  ...
  --with-geoip2   deprecated, use --with-maxminddb
  --with-maxminddb=PATH   Build with MaxMind GeoIP2 support (auto|yes|no|path)
  [default=auto]

since I have installed GeoIP2*, 

pkg-config --cflags --libs libmaxminddb
-I/usr/local/include -L/usr/local/lib64 -lmaxminddb

ls -al /usr/local/{include,lib64}/*maxmind*
-rw-r--r-- 1 root root  507 Mar 18 18:27 
/usr/local/include/maxminddb_config.h
-rw-r--r-- 1 root root 8.4K Mar 18 18:27 
/usr/local/include/maxminddb.h
-rwxr-xr-x 1 root root  943 Mar 18 18:27 
/usr/local/lib64/libmaxminddb.la*
lrwxrwxrwx 1 root root   21 Mar 18 18:27 
/usr/local/lib64/libmaxminddb.so -> libmaxminddb.so.0.0.7*
lrwxrwxrwx 1 root root   21 Mar 18 18:27 
/usr/local/lib64/libmaxminddb.so.0 -> libmaxminddb.so.0.0.7*
-rwxr-xr-x 1 root root 122K Mar 18 18:27 
/usr/local/lib64/libmaxminddb.so.0.0.7*

ls -al /var/lib/GeoIP2/
total 71M
drwxr-xr-x  2 named root 4.0K Apr  2 03:15 ./
drwxr-xr-x 85 root  root 4.0K Apr 12 19:11 ../
-rw-rw-r--  1 named root 6.4M Apr 15 12:09 GeoLite2-ASN.mmdb
-rw-rw-r--  1 named root  61M Apr 15 12:09 GeoLite2-City.mmdb
-rw-rw-r--  1 named root 3.7M Apr 15 12:09 GeoLite2-Country.mmdb

and *DO* want to "support GeoIP2 geoloc ACLs", building here with

--disable-geoip=yes \
--with-maxminddb=/var/lib/GeoIP2 \

FAILs with

configure: error: invalid feature name: geoip=yes

switching to

-   --disable-geoip=yes \
+   --disable-geoip \
--with-maxminddb=/var/lib/GeoIP2 \

configure completes, reporting 'old' GeoIP support is correctly DISabled
but there's NO mention of GeoIP2/Lite support, i.e., *maxminddb

Optional features enabled:
Mutex lock type: adaptive
IPv6 support (--enable-ipv6)
Python tools (--with-python)
XML statistics (--with-libxml2)
JSON statistics (--with-json-c): -I/usr/include/json-c -ljson-c
HTTP zlib compression (--with-zlib)
LMDB database to store configuration for 'addzone' zones 
(--with-lmdb)
IDN support (--with-libidn2)
Print backtrace on crash (--enable-backtrace)
Use symbol table for backtrace, named only (--enable-symtable)
Use GNU libtool (--with-libtool)
DNSSEC validation active by default (--enable-auto-validation)
Dynamically loadable zone (DLZ) drivers:
None

---
Features disabled or unavailable on this platform:
...
GeoIP2 access control (--enable-geoip)
...

after subsequent

make depend
make
make install

named -v
BIND 9.16.2 (Stable Release) 

checking, the maxmind lib *is* linked

ldd `which named`
libmaxminddb.so.0 => /usr/lib64/libmaxminddb.so.0 
(0x7f94618d8000)


so, *is* available GeoIP2 support with available DBs enabled, and this is just 
a _reporting_ error?
or is it not correctly/completely enabled ... ?

what is the correct, complete config specification for using installed GeoIP2 
support?
___
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 v9.16.0 dlz_filesystem_dynamic module build FAILs ?

[PGNet Dev]

On 2/19/20 7:41 PM, Mark Andrews wrote:
> clang-format reordered the includes alphabetically and “dir.h” depends
> on “dlz_minimal.h” for the typedef.
> 
> The following should address this.
> 
> diff --git a/contrib/dlz/modules/filesystem/dir.h 
> b/contrib/dlz/modules/filesystem/dir.h
> index e93dd5931c..558950863b 100644
> --- a/contrib/dlz/modules/filesystem/dir.h
> +++ b/contrib/dlz/modules/filesystem/dir.h
> @@ -16,6 +16,8 @@
>   
>   #include 
>   
> +#include "dlz_minimal.h"
> +
>   #include 
>   
>   #define DIR_NAMEMAX 256


confirmed here

with src patch, module builds

cd ../filesystem
make V=1
ldd dlz_filesystem_dynamic.so
linux-vdso.so.1 (0x7ffd99f34000)
libc.so.6 => /lib64/libc.so.6 (0x7fbb2713e000)
/lib64/ld-linux-x86-64.so.2 (0x564e6ae95000)

and bind's up & running

named -v
BIND 9.16.0 (Stable Release) 

thx!
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

bind v9.16.0 dlz_filesystem_dynamic module build FAILs ?

[PGNet Dev]

building 9.16.0, as usual, on linux/64,



config + make of core are OK



of my two usual module builds,



'dlz_bdbhpt_dynamic' is OK



cd contrib/dlz/modules/

cd  ./bdbhpt

make V=1

ldd dlz_bdbhpt_dynamic.so

linux-vdso.so.1 (0x7fffa312c000)

libdb-4.8.so => /usr/lib64/libdb-4.8.so (0x7f50edc43000)

libc.so.6 => /lib64/libc.so.6 (0x7f50ed89b000)

libpthread.so.0 => /lib64/libpthread.so.0 (0x7f50ed67d000)

/lib64/ld-linux-x86-64.so.2 (0x56482796b000)



but, currently, dlz_filesystem_dynamic FAILs



cd ../filesystem

make V=1



/usr/bin/gcc-9 -fPIC -g -I../include -c dir.c

In file included from dir.c:17:

dir.h:38:1: error: unknown type name ‘isc_result_t’

   38 | isc_result_t

  | ^~~~

dir.h:41:1: error: unknown type name ‘isc_result_t’

   41 | isc_result_t

  | ^~~~

dir.h:44:1: error: unknown type name ‘isc_result_t’

   44 | isc_result_t

  | ^~~~

dir.c:39:1: error: conflicting types for ‘dir_open’

   39 | dir_open(dir_t *dir, const char *dirname)

  | ^~~~

In file included from dir.c:17:

dir.h:39:1: note: previous declaration of ‘dir_open’ was here

   39 | dir_open(dir_t *dir, const char *dirname);

  | ^~~~

dir.c:91:1: error: conflicting types for ‘dir_read’

   91 | dir_read(dir_t *dir)

  | ^~~~

In file included from dir.c:17:

dir.h:42:1: note: previous declaration of ‘dir_read’ was here

   42 | dir_read(dir_t *dir);

  | ^~~~

dir.c:122:1: error: conflicting types for ‘dir_reset’

  122 | dir_reset(dir_t *dir)

  | ^

In file included from dir.c:17:

dir.h:45:1: note: previous declaration of ‘dir_reset’ was here

   45 | dir_reset(dir_t *dir);

  | ^

make: *** [Makefile:9: dir.o] Error 1



9.14.11's module builds are both, still OK

I've not found relevant mention in CHANGES, and nothing, yet, in bugs etc.

Known issue? fix/workaround available?


___
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: frequent client query errors: "rpz_rewrite_name: mismatched summary data" ?

[PGNet Dev]

ping, anyone?

On 2/1/18 10:22 AM, PGNet Dev wrote:

I recently updated to

named -v
BIND 9.12.0 

compiled locally with

...
--enable-rpz-nsip
--enable-rpz-nsdname
--enable-querytrace
...

Now, in logs I'm seeing many of these errors, for numerous domain queries,

...
Feb  1 09:58:51 dns001 named[37642]: 01-Feb-2018 09:58:51.316 client: 
error: query client=0x7fed700dccf0 thread=0x7fed75bbd700 
(api.stacksocial.com/A): rpz_rewrite_name: mismatched summary data; continuing
...

Per this thread

Latest BIND: Error "rpz_rewrite_name: mismatched summary data; 
continuing"
 https://lists.isc.org/pipermail/bind-users/2016-September/097550.html

suggested to 'avoid' the error by

(1) Don't use regular BIND 9.9 for RPZ. For using RPZ, please use 9.10 
and higher

and

(2) ... if you want to just not see this log message, just recompile 
after removing the offending CTRACE statement from bin/named/query.c. In fact, 
this code is normally enabled when configured with --enable-querytrace ...

which doesn't address the problem, beyond "not seeing" the errors.

What are these errors actually DUE to, and how are they to be fixed?



___
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

frequent client query errors: "rpz_rewrite_name: mismatched summary data" ?

[PGNet Dev]

I recently updated to

named -v
BIND 9.12.0 

compiled locally with

... 
--enable-rpz-nsip
--enable-rpz-nsdname
--enable-querytrace
...

Now, in logs I'm seeing many of these errors, for numerous domain queries,

...
Feb  1 09:58:51 dns001 named[37642]: 01-Feb-2018 09:58:51.316 client: 
error: query client=0x7fed700dccf0 thread=0x7fed75bbd700 
(api.stacksocial.com/A): rpz_rewrite_name: mismatched summary data; continuing
...

Per this thread

Latest BIND: Error "rpz_rewrite_name: mismatched summary data; 
continuing"
 https://lists.isc.org/pipermail/bind-users/2016-September/097550.html

suggested to 'avoid' the error by

(1) Don't use regular BIND 9.9 for RPZ. For using RPZ, please use 9.10 
and higher

and

(2) ... if you want to just not see this log message, just recompile 
after removing the offending CTRACE statement from bin/named/query.c. In fact, 
this code is normally enabled when configured with --enable-querytrace ...

which doesn't address the problem, beyond "not seeing" the errors.

What are these errors actually DUE to, and how are they to be fixed?

___
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: nested CNAMEs resolution failures?

[PGNet Dev]

On 1/29/18 7:08 AM, Tony Finch wrote:
> PGNet Dev <pgnet@gmail.com> wrote:
>>
>> Can these response timeouts be accommodated directly in the script?  Or
>> only by, perhaps, increasing the global query timeouts from default 10
>> sec?
> 
> Yes, there's a bootstrapping problem here ... possibly the easiest way to
> avoid depending on a server that sends cookies when reconfiguring it not
> to send cookies, is to point the script at 8.8.8.8. In my setup the script
> runs in a dev environment generating a static file that is deployed to
> production, but it's effectively the same trick of making the script use a
> different DNS server.

Pointing @goog NS is easy enough to manage, and it takes care of the problem 
for the ns[1234].irs.gov servers. Thx!


I added the 'caixin' servers -- not that I knowingly use them, just to test 
here -- and even querying @8.8.8.8, they timeout

  Jan 29 07:15:38 ns003 named[17757]: 29-Jan-2018 07:15:38.591 client: error: 
query client=0x7f626c0bfc30 thread=0x7f62741b7700 (ns0.caixin.com/A): 
query_gotanswer: unexpected error: timed out
  Jan 29 07:15:48 ns003 named[17757]: 29-Jan-2018 07:15:48.931 client: error: 
query client=0x7f626c03d5a0 thread=0x7f62741b7700 (ns10.caixin.com/A): 
query_gotanswer: unexpected error: timed out
  Jan 29 07:15:59 ns003 named[17757]: 29-Jan-2018 07:15:59.286 client: error: 
query client=0x7f626cae54c0 thread=0x7f62741b7700 (ns20.caixin.com/A): 
query_gotanswer: unexpected error: timed out

No such problems in either case with qwest or barclays servers ...
___
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: nested CNAMEs resolution failures?

[PGNet Dev]

On 1/29/18 6:03 AM, Tony Finch wrote:
> Use the script I posted the other day:
> https://lists.isc.org/pipermail/bind-users/2018-January/099481.html
> except amended like this

In a recent post, I bumped into a similar problem with ns[1234].irs.gov

The "no-cookie" solution fixes the problem.

Found your handy script, & added

 ns1.irs.gov.
 ns2.irs.gov.
 ns3.irs.gov.
 ns4.irs.gov.

On exec I notice in logs -- very frequently, but apparently NOT always -- 
timeouts

Jan 29 03:38:55 ns003 named[17757]: 29-Jan-2018 03:38:55.313 client: 
error: query client=0x7f626c03d5a0 thread=0x7f62741b7700 (ns1.irs.gov/A): 
query_gotanswer: unexpected error: timed out
Jan 29 03:39:05 ns003 named[17757]: 29-Jan-2018 03:39:05.313 client: 
error: query client=0x7f626400c5a0 thread=0x7f62741b7700 (ns1.irs.gov/A): 
query_gotanswer: unexpected error: timed out
Jan 29 03:39:05 ns003 named[17757]: 29-Jan-2018 03:39:05.315 client: 
error: query client=0x7f6264042310 thread=0x7f62741b7700 (ns1.irs.gov/): 
query_gotanswer: unexpected error: timed out
Jan 29 03:39:15 ns003 named[17757]: 29-Jan-2018 03:39:15.330 client: 
error: query client=0x7f626cae54c0 thread=0x7f62741b7700 (ns2.irs.gov/A): 
query_gotanswer: unexpected error: timed out
Jan 29 03:39:25 ns003 named[17757]: 29-Jan-2018 03:39:25.332 client: 
error: query client=0x7f626400c5a0 thread=0x7f62741b7700 (ns2.irs.gov/): 
query_gotanswer: unexpected error: timed out
Jan 29 03:39:35 ns003 named[17757]: 29-Jan-2018 03:39:35.347 client: 
error: query client=0x7f626c03d5a0 thread=0x7f62749b8700 (ns3.irs.gov/A): 
query_gotanswer: unexpected error: timed out
Jan 29 03:39:45 ns003 named[17757]: 29-Jan-2018 03:39:45.348 client: 
error: query client=0x7f626c0bfc30 thread=0x7f62749b8700 (ns3.irs.gov/): 
query_gotanswer: unexpected error: timed out
Jan 29 03:39:55 ns003 named[17757]: 29-Jan-2018 03:39:55.365 client: 
error: query client=0x7f626400c5a0 thread=0x7f62741b7700 (ns4.irs.gov/A): 
query_gotanswer: unexpected error: timed out
Jan 29 03:40:05 ns003 named[17757]: 29-Jan-2018 03:40:05.365 client: 
error: query client=0x7f626c03d5a0 thread=0x7f62749b8700 (ns4.irs.gov/A): 
query_gotanswer: unexpected error: timed out
Jan 29 03:40:05 ns003 named[17757]: 29-Jan-2018 03:40:05.366 client: 
error: query client=0x7f6264042310 thread=0x7f62749b8700 (ns4.irs.gov/): 
query_gotanswer: unexpected error: timed out

and

cat ../includes/named.conf.noedns
server 157.83.102.245 { send-cookie no; }; # ns21.barclays.com.
server 157.83.102.246 { send-cookie no; }; # ns22.barclays.net.
server 157.83.126.245 { send-cookie no; }; # ns23.barclays.com.
server 157.83.126.246 { send-cookie no; }; # ns24.barclays.net.
server 63.150.72.5 { send-cookie no; }; # sauthns1.qwest.net.
server 2001:428::7 { send-cookie no; }; # sauthns1.qwest.net.
server 208.44.130.121 { send-cookie no; }; # sauthns2.qwest.net.
server 2001:428::8 { send-cookie no; }; # sauthns2.qwest.net.

exec the same script ~30 seconds later, NO timeout errors in logs, and

cat ../includes/named.conf.noedns
server 152.216.7.164 { send-cookie no; }; # ns1.irs.gov.
server 2610:30:4000:53::90 { send-cookie no; }; # ns1.irs.gov.
server 157.83.102.245 { send-cookie no; }; # ns21.barclays.com.
server 157.83.102.246 { send-cookie no; }; # ns22.barclays.net.
server 157.83.126.245 { send-cookie no; }; # ns23.barclays.com.
server 157.83.126.246 { send-cookie no; }; # ns24.barclays.net.
server 152.216.7.165 { send-cookie no; }; # ns2.irs.gov.
server 2610:30:4000:53::91 { send-cookie no; }; # ns2.irs.gov.
server 152.216.11.132 { send-cookie no; }; # ns3.irs.gov.
server 2610:30:2000:53::90 { send-cookie no; }; # ns3.irs.gov.
server 152.216.11.133 { send-cookie no; }; # ns4.irs.gov.
server 2610:30:2000:53::91 { send-cookie no; }; # ns4.irs.gov.
server 63.150.72.5 { send-cookie no; }; # sauthns1.qwest.net.
server 2001:428::7 { send-cookie no; }; # sauthns1.qwest.net.
server 208.44.130.121 { send-cookie no; }; # sauthns2.qwest.net.
server 2001:428::8 { send-cookie no; }; # sauthns2.qwest.net.

Can these response timeouts be accommodated directly in the script?  Or only 
by, perhaps, increasing the global query timeouts from default 10 sec?
___
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: unable to resolve *.irs.gov at local bind 9.12.0 server ?

[PGNet Dev]

On 1/27/18 2:47 PM, Rob Sargent wrote:
> you should probably also add these so usitc.gov and sss.gov won’t fail if 
> they fail for you:
> 
>  server 63.150.72.5 { send-cookie no; }; # sauthns1.qwest.net
>  server 208.44.130.121 { send-cookie no; }; # sauthns2.qwest.net.

Done, thx.

> I prefer cycling to fixing all the brokenness with anything gov[ernment].  In 
> my younger years I’d take them on and try to help them.  I suspect it has 
> something to do with UDP tunneling because it wouldn’t work via my IPSEC link 
> but worked fine out my fibre DSL link.  The above work around fixed it for me 
> WRT usitc.gov.
> 
> I just tried removing all the server no-cookie lines from my config and I 
> couldn’t get to usitc.gov but no problem with irs.gov, go figure.  Anyhow as 
> soon as you said SERVFAIL and QWest, it clicked in my mind.  I wonder if the 
> IRS contracted out their DNS server ops to QWest?  Anyhow, have fun!

It's working, but I'm still seeing some strangeness ...

I apparently need to add the server clauses to BOTH my 'internal' & 'external' 
view.  Just one, or the other, doesn't do the trick.

I need to scratch my head a bit more about that one :-/

Also, even though it now 'works', it does so only AFTER I now see a couple of 
these timeouts in logs:

  Jan 27 15:02:08 core named[18703]: 27-Jan-2018 15:02:08.897 client: error: 
query client=0x7fc0f80eb4a0 thread=0x7fc100313700 (irs.gov/A): query_gotanswer: 
unexpected error: timed out
  Jan 27 15:02:08 core named[18703]: 27-Jan-2018 15:02:08.898 client: error: 
query client=0x7fc0f0066c30 thread=0x7fc0ffb12700 (irs.gov/): 
query_gotanswer: unexpected error: timed out

I've got no other timeouts in logs that I've found, so something unique to 
these again?
___
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: unable to resolve *.irs.gov at local bind 9.12.0 server ?

[PGNet Dev]

On 1/27/18 1:36 PM, Rob Sargent wrote:

Just for grins, try adding these lines to your named.conf file [within the 
appropriate view] to see if that fixes it.  I had to add something like it to 
get usitc.gov working for my customers:

server 152.216.7.164 { send-cookie no; }; # ns1.irs.gov
server 152.216.7.165 { send-cookie no; }; # ns2.irs.gov
server 152.216.11.132 { send-cookie no; }; # ns3.irs.gov
server 152.216.11.133 { send-cookie no; }; # ns4.irs.gov

or whatever IP is failing.  Not sure if your port 53 traffic goes thru QWest 
but QWest is well known to be broken.


That did the trick!  All of *irs.gov now resolve at my server.

Re: "well known", alas, not by me 'til now.  So thx!

It appears, then, that the set of servers in my tests are all 
'sensitive' to said brokenness.  I suppose if it's actual breakage, 
that's a good thing ...


Not clear to be why/how the 'big' NSs, e.g. Google, manage to avoid the 
problem.  Either they're INsensitive to the issue, or already have 
implemented a similar workaround?


Also, if it's well known wouldn't a QWest have been given notice of said 
probs?  Or are they in the DGAD camp?

___
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: unable to resolve *.irs.gov at local bind 9.12.0 server ?

[PGNet Dev]

On 1/27/18 11:33 AM, Lee wrote:

On 1/27/18, PGNet Dev <pgnet@gmail.com> wrote:

I've a local bind 9.12.0 server.  Works for virtually all domains.

For "irs.gov", it fails,


works for me on a local bind 9.11.2 server:
$ dig a irs.gov.


Do you any of

// forward first;
// forward only;
// forwarders {

set in your conf?

What does TR from your working server show ?
___
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: unable to resolve *.irs.gov at local bind 9.12.0 server ?

[PGNet Dev]

> Works for me, try figuring out if you have a routing problem getting to 
> ns[1234].irs.gov.  

Hm.

I've traceroute'd from my local network, & from 2 separate VPNs.  I.e., 
disparate, unrelated nets.

All 3 fail at the same points.  E.g.

at qwest.net,

traceroute to ns1.irs.gov (152.216.7.164), 64 hops max, 40 byte packets
 1  205.166.94.3 (205.166.94.3)  0.449 ms  0.502 ms  0.661 ms
 2  ge4-2.core1.sea2.hopone.net (209.160.60.197)  0.307 ms  0.214 ms  
0.221 ms
 3  ge4-0.core2.sea2.hopone.net (66.36.224.178)  0.311 ms  0.255 ms  
0.213 ms
 4  tuk-edge-14.inet.qwest.net (209.160.62.181)  4.990 ms  2.548 ms  
1.831 ms
 5  * * * * ^C

and, at above.net

traceroute to irs.gov (166.123.218.220), 64 hops max, 40 byte packets
 1  205.166.94.3 (205.166.94.3)  0.400 ms  0.357 ms  0.368 ms
 2  ge4-2.core2.sea2.hopone.net (209.160.60.221)  0.309 ms  0.219 ms  
0.221 ms
 3  xe1-0.core1.sea1.hopone.net (66.36.224.18)  0.899 ms  0.516 ms  
0.517 ms
 4  six.zayo.com (206.81.80.19)  5.727 ms  2.561 ms  2.713 ms
 5  ae28.cs2.sea1.us.eth.zayo.com (64.125.29.104)  73.903 ms  73.941 ms 
 73.880 ms
 6  ae2.cs2.ord2.us.eth.zayo.com (64.125.29.29)  79.937 ms  81.214 ms  
79.996 ms
 7  ae3.cs2.lga5.us.eth.zayo.com (64.125.29.212)  81.292 ms  81.616 ms  
83.187 ms
 8  ae4.cs2.dca2.us.eth.zayo.com (64.125.29.31)  75.848 ms  75.942 ms  
90.155 ms
 9  ae27.cr2.dca2.us.zip.zayo.com (64.125.30.249)  73.776 ms  73.742 ms 
 79.154 ms
10  ae2.er2.dca2.us.zip.zayo.com (64.125.26.178)  73.509 ms  73.459 ms  
73.443 ms
11  64.125.170.158.t00822-05.above.net (64.125.170.158)  95.315 ms  
95.392 ms  95.391 ms
12  * * * * ^C

What's your TR look like to "ns1.irs.gov" and "irs.gov" ?
___
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

unable to resolve *.irs.gov at local bind 9.12.0 server ?

[PGNet Dev]

I've a local bind 9.12.0 server.  Works for virtually all domains.

For "irs.gov", it fails,

dig A irs.gov

; <<>> DiG 9.12.0 <<>> A irs.gov
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2101
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, 
ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 924396a00e82e7e6cb3a18495a6cb893e564a4fc00f78373 
(good)
;; QUESTION SECTION:
;irs.gov.   IN  A

;; Query time: 2706 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jan 27 09:36:19 PST 2018
;; MSG SIZE  rcvd: 64

Resolution is fine at offsite servers

dig A irs.gov @8.8.8.8

; <<>> DiG 9.12.0 <<>> A irs.gov @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56261
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, 
ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;irs.gov.   IN  A

;; ANSWER SECTION:
irs.gov.236 IN  A   166.123.218.220

;; Query time: 43 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Jan 27 09:36:29 PST 2018
;; MSG SIZE  rcvd: 52

looking at local server trace,

dig +trace irs.gov

; <<>> DiG 9.12.0 <<>> +trace irs.gov
;; global options: +cmd
.   3328IN  NS  
a.root-servers.net.
.   3328IN  NS  
b.root-servers.net.
.   3328IN  NS  
c.root-servers.net.
.   3328IN  NS  
d.root-servers.net.
.   3328IN  NS  
e.root-servers.net.
.   3328IN  NS  
f.root-servers.net.
.   3328IN  NS  
g.root-servers.net.
.   3328IN  NS  
h.root-servers.net.
.   3328IN  NS  
i.root-servers.net.
.   3328IN  NS  
j.root-servers.net.
.   3328IN  NS  
k.root-servers.net.
.   3328IN  NS  
l.root-servers.net.
.   3328IN  NS  
m.root-servers.net.
.   3328IN  RRSIG   NS 8 0 518400 
2018020905 2018012704 41824 . 
DkeMZSxEcmxZ78udDb9pw7HxLylmNUJb4utqwV206pQ+ItBvuuJzMnmY 
pboHDZPEn15xUcGTmnAmDfpX1fhoHPYuBiXC3DmO/gwRG1ktl/xRKbjE 
m9E9PDvUmd1F+/FCcexTFsFm0RU/EMiziKIYJL1ttj2+Ozjc/j+ii6I9 
cOVwjH8DE+3XqGjti803qu4Ycr3MQYcPxQiO6NckxoidZM3GxZRkunmr 
mOz5bBDFfOBMbgC4uYGpfVuJ1OysDRzniNuFQXkftIlpFHmgeIi3U/GR 
RoeIuOip9YaJRiUfnK1V8iFaff/70YvPr6PQkpmb8NpayLdfDqQdsK3D 8rJORA==
;; Received 565 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms

gov.172800  IN  NS  
a.gov-servers.net.
gov.172800  IN  NS  
b.gov-servers.net.
gov.172800  IN  NS  
c.gov-servers.net.
gov.172800  IN  NS  
d.gov-servers.net.
gov.86400   IN  DS  7698 8 1 
6F109B46A80CEA9613DC86D5A3E065520505AAFE
gov.86400   IN  DS  7698 8 2 
6BC949E638442EAD0BDAF0935763C8D003760384FF15EBBD5CE86BB5 559561F0
gov.86400   IN  RRSIG   DS 8 1 86400 
2018020905 2018012704 41824 . 
jqlemnm+YBXTy0W+akzROVZNlZBsvyVnDOyCONEyDiOn4fXWTrFiDdXD 
lvq60ytuyQpaevkMQHC360Z5CIU4GRqODFom0G/v1whZOS140lBiqPVb 
f9xpX29Fx/RjEekGNXMlzXyrzXCtvy2yFQ7jcUYwl/JJ5DFRZerjAAt8 
7v/CdHrF42E5ocjcSnxMZ1EaUFBMAm549lYRVSOG4h6SSlfos4R/G8GF 
VKXs2JE27/EWXdIw0uMZKU88ExLdY6TVpCNHrrJ29W6CIT5JO59sI8GO 
woML2fwF7+gfM5zbNM5geHdOvAVh0KY1mhCRT8cln5r8maazH4ih+jvV akgTRQ==
;; Received 662 bytes from 199.7.83.42#53(l.root-servers.net) 
in 28 ms

irs.gov.86400   IN  NS  ns1.irs.gov.
irs.gov.86400   IN  NS  ns2.irs.gov.
irs.gov.86400   IN  NS  ns3.irs.gov.
irs.gov.86400   IN  NS  ns4.irs.gov.
irs.gov. 

Re: [ot] botched KSK rollover

[PGNet Dev]

You might want to look at gkg.net


fyi

@ Gandi

  rich DNS(SEC) API with XML-RPC call support & docs for python, php, 
nodejs, perl, ruby & c


http://doc.rpc.gandi.net/domain/reference.html


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

bind 9.11.1, linking with 'supported' OpenSSL fails at use of deprecated/undef'd v10x api symbol, ERR_load_crypto_strings

[PGNet Dev]

Upgrading from bind 9.10.3-P5 -> 9.11.1 release on linux64,

cat CHANGES
../dns/.libs/libdns.so: undefined reference to 
`ERR_load_crypto_strings'
collect2: error: ld returned 1 exit status
--- 9.11.0 released ---
...
4497.   [port]  Add support for OpenSSL 1.1.0. [RT 
#41284]
...
--- 9.11.0 released ---


Building, as always, with openssl v10x, all's well:

bind -V
BIND 9.11.1 
running on Linux x86_64 4.10.10-2.ga78ebd0-default #1 SMP 
PREEMPT Wed Apr 12 11:18:29 UTC 2017 (a78ebd0)
...
compiled by GCC 6.3.1 20170331 [gcc-6-branch revision 246609]
compiled with OpenSSL version: OpenSSL 1.0.2k  26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k  26 Jan 2017
...

OTOH,

Building, similarly, with openssl v110x FAILs still, at

...
Makefile:465: recipe for target 'sample-gai' failed
make[2]: *** [sample-gai] Error 1
...
libtool: link: /usr/bin/gcc-6 -O3 -Wall -fstack-protector 
-funwind-tables -fasynchronous-unwind-tables -fmessage-length=0 
-grecord-gcc-switches -march=native -mtune=native -I/usr/include 
-I/usr/local/lmdb/include -I/usr/include/libxml2 -fPIC -Wl,-rpath 
-Wl,/usr/local/openssl11/lib64 -Wl,-rpath -Wl,/usr/local/lmdb/lib64 -Wl,-rpath 
-Wl,/usr/local/lib64 -o .libs/resolve .libs/resolve.o  
-L/usr/local/openssl11/lib64 -L/usr/local/lmdb/lib64 -L/usr/local/lib64 
../irs/.libs/libirs.so -L/usr/lib -L/usr/local/lmdb/lib -L/lib64 
../dns/.libs/libdns.so -L/usr/local/openssl11/lib ../isccfg/.libs/libisccfg.so 
/usr/local/src/bind-9.11.1/lib/dns/.libs/libdns.so 
/usr/local/src/bind-9.11.1/lib/isc/.libs/libisc.so ../isc/.libs/libisc.so -lssl 
-lcrypto -lcap -ljson-c -lpthread /usr/local/lib64/libGeoIP.so -llmdb 
/usr/lib64/libxml2.so -lz -llzma -lm -ldl -Wl,-rpath 
-Wl,/usr/local/bind-9.11.1/lib64
../dns/.libs/libdns.so: undefined reference to `ERR_load_crypto_strings'
collect2: error: ld returned 1 exit status
Makefile:457: recipe for target 'resolve' failed
make[2]: *** [resolve] Error 1
../dns/.libs/libdns.so: undefined reference to `ERR_load_crypto_strings'
collect2: error: ld returned 1 exit status
Makefile:473: recipe for target 'sample-request' failed
make[2]: *** [sample-request] Error 1
libtool: link: /usr/bin/gcc-6 -O3 -Wall -fstack-protector 
-funwind-tables -fasynchronous-unwind-tables -fmessage-length=0 
-grecord-gcc-switches -march=native -mtune=native -I/usr/include 
-I/usr/local/lmdb/include -I/usr/include/libxml2 -fPIC -Wl,-rpath 
-Wl,/usr/local/openssl11/lib64 -Wl,-rpath -Wl,/usr/local/lmdb/lib64 -Wl,-rpath 
-Wl,/usr/local/lib64 -o .libs/sample-async .libs/sample-async.o  
-L/usr/local/openssl11/lib64 -L/usr/local/lmdb/lib64 -L/usr/local/lib64 
../dns/.libs/libdns.so -L/usr/local/openssl11/lib -L/usr/lib 
-L/usr/local/lmdb/lib -L/lib64 ../isccfg/.libs/libisccfg.so 
/usr/local/src/bind-9.11.1/lib/dns/.libs/libdns.so 
/usr/local/src/bind-9.11.1/lib/isc/.libs/libisc.so ../isc/.libs/libisc.so -lssl 
-lcrypto -lcap -ljson-c -lpthread /usr/local/lib64/libGeoIP.so -llmdb 
/usr/lib64/libxml2.so -lz -llzma -lm -ldl -Wl,-rpath 
-Wl,/usr/local/bind-9.11.1/lib64
../dns/.libs/libdns.so: undefined reference to `ERR_load_crypto_strings'
collect2: error: ld returned 1 exit status
Makefile:461: recipe for target 'sample-async' failed
make[2]: *** [sample-async] Error 1
make[2]: Leaving directory '/usr/local/src/bind-9.11.1/lib/samples'
Makefile:78: recipe for target 'subdirs' failed
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory '/usr/local/src/bind-9.11.1/lib'
Makefile:83: recipe for target 'subdirs' failed
make: *** [subdirs] Error 1

'ERR_load_crypto_strings' is an openssl10x symbol, deprecated in 11x.

it appears in bind sources,

cd bind-9.11.1
grep -rln ERR_load_crypto_strings .
./lib/dns/openssl_link.c


___
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

status openssl v1.1 support?

[PGNet Dev]

In Bind 9.11.0-P3's "CHANGES"

grep -i openssl CHANGES | grep "1\.1"
4129.   [port]  Address API changes in OpenSSL 1.1.0. [RT 
#39532]

seems the bug DB is private/closed, so can't see the status of that^.

Trying to build against openssl v11x fails @ configure

...
checking for OpenSSL library... using OpenSSL from 
/usr/local/openssl11/lib and /usr/local/openssl11/include
checking whether linking with OpenSSL works... yes
checking whether linking with OpenSSL requires -ldl... unknown
configure: error: OpenSSL has unsupported dynamic loading
...

Searching on that bug leads to


http://superuser.com/questions/1182479/configure-error-openssl-has-unsupported-dynamic-loading-when-building-bind9

"It turns out that bind does not yet support OpenSSL 1.1 (see 
OPenssl 1.1 and Bind on bind-users mailing list)."

and to the ML



OPenssl 1.1 and Bind
https://lists.isc.org/pipermail/bind-users/2016-August/097391.html

Where the last comment from marka at isc.org discusses direction

It was mostly accessor functions were missing which I wasn't worried
about as I expected them to turn up which they have.  You then have
to recode everything to deal with all the structures being opaque.

There is also the issue of making a code base that will compile w/
OpenSSL 1.1 and OpenSSL 1.0 (and 0.9 despite it being EOL).  I
suspect we will have static versions of the OpenSSL 1.1 accessor
functions so we can build w/ OpenSSL 1.0 and not have too many
#if/#else/#endif.  Aim to have all the code be written for OpenSSL 1.1.

Need to figure out how GOST is now done.

PKCS11 will most probably not be via OpenSSL anymore.

Then there is the gssapi support libraries that also need to support
OpenSSL 1.1.

but, afaict, nothing further.

What *IS* the current state/status of openssl 1.1 support in bind9?

Is it yet targeted for a specific release? or available as a current patchset?
___
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: 9.10.4 build fails in dlz/modules/filesystem; 9.10.3-P4 ok.

[PGNet Dev]

On 04/28/2016 04:54 PM, Mark Andrews wrote:

This should fix this.

diff --git a/contrib/dlz/modules/filesystem/dlz_filesystem_dynamic.c 
b/contrib/dlz/modules/filesystem/dlz_filesystem_dynamic.c
index 35bed58..cbd5049 100644
--- a/contrib/dlz/modules/filesystem/dlz_filesystem_dynamic.c
+++ b/contrib/dlz/modules/filesystem/dlz_filesystem_dynamic.c
@@ -825,6 +825,7 @@ isc_result_t
 dlz_create(const char *dlzname, unsigned int argc, char *argv[],
   void **dbdata, ...)
 {
+   isc_result_t result = ISC_R_NOMEMORY;
config_data_t *cd;
char *endp;
int len;
@@ -933,7 +934,7 @@ dlz_create(const char *dlzname, unsigned int argc, char 
*argv[],
dlz_destroy(cd);

/* return error */
-   return (ISC_R_NOMEMORY);
+   return (result);
 }

 void



Does the trick.

 named -v
  BIND 9.10.4 

Thanks.
___
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

9.10.4 build fails in dlz/modules/filesystem; 9.10.3-P4 ok.

[PGNet Dev]

Taking a stab at the new release ...

Building 9.10.3-P4' dlz modules on linux/64

...
cd contrib/dlz/modules/
cd  ./bdbhpt
make
ldd dlz_bdbhpt_dynamic.so
linux-vdso.so.1 (0x7fffa312c000)
libdb-4.8.so => /usr/lib64/libdb-4.8.so (0x7f50edc43000)
libc.so.6 => /lib64/libc.so.6 (0x7f50ed89b000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f50ed67d000)
/lib64/ld-linux-x86-64.so.2 (0x56482796b000)
cd ../filesystem
make
ldd dlz_filesystem_dynamic.so
linux-vdso.so.1 (0x7ffd99f34000)
libc.so.6 => /lib64/libc.so.6 (0x7fbb2713e000)
/lib64/ld-linux-x86-64.so.2 (0x564e6ae95000)
...

had no issues.

Same step in the build, with latest 9.10.4 sources, fails at 
dlz/modules/filesystem,


cd contrib/dlz/modules/
cd  ./bdbhpt
make
/usr/bin/gcc-6 -fPIC -g -I../include -shared -o 
dlz_bdbhpt_dynamic.so \
dlz_bdbhpt_dynamic.c -ldb
ldd dlz_bdbhpt_dynamic.so
linux-vdso.so.1 (0x7ffceedb4000)
libdb-4.8.so => /usr/lib64/libdb-4.8.so (0x7f45c2bbb000)
libc.so.6 => /lib64/libc.so.6 (0x7f45c2813000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f45c25f5000)
/lib64/ld-linux-x86-64.so.2 (0x5603fc83d000)
cd ../filesystem
make
/usr/bin/gcc-6 -fPIC -g -I../include -c dir.c
		/usr/bin/gcc-6 -fPIC -g -I../include -shared -o 
dlz_filesystem_dynamic.so \

dlz_filesystem_dynamic.c dir.o
dlz_filesystem_dynamic.c: In function ‘dlz_create’:
		dlz_filesystem_dynamic.c:856:3: error: ‘result’ undeclared (first use 
in this function)

   result = ISC_R_FAILURE;
   ^~
		dlz_filesystem_dynamic.c:856:3: note: each undeclared identifier is 
reported only once for each function it appears in

Makefile:12: recipe for target 'dlz_filesystem_dynamic.so' 
failed
make: *** [dlz_filesystem_dynamic.so] Error 1


Atm, this is with

gcc --version
gcc (SUSE Linux) 6.1.0 20160427 [gcc-6-branch revision 235475]

Known issue?  Perhaps a gcc version issue?

___
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