Delete/update MX record

[@lbutlr]

Using nsupdate when I try to delete an MX record for a domain, I get REFSUED.

When I try to add an MX record with the same priority (or not), it leaves the 
old record as well.

How do I remove and replace the MX record for a domain with nsupdate?

-- 
A woman stays up all night with two men
(Singin' in the Rain)

-- 
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: managed-keys-zone: Failed to create fetch for DNSKEY update

[@lbutlr]

On 2022 Apr 12, at 18:25, @lbutlr  wrote:
> 
> My secondary DNS server (bind916-9-16-27) is reporting:
> 
> managed-keys-zone: Failed to create fetch for DNSKEY update

Named.conf relevant settings (I think) are:

recursion yes;
allow-query { any; };
allow-recursion { 127.0.0.1; ; };

listen-on   { ; 127.0.0.1; };

forwarders { ; };
forward first;

Dig @localhost returns:

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 23697
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

-- 
If you must choose between two evils, pick the one you've never tried
before.

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

managed-keys-zone: Failed to create fetch for DNSKEY update

[@lbutlr]

My secondary DNS server (bind916-9-16-27) is reporting:

managed-keys-zone: Failed to create fetch for DNSKEY update

At this point it only respond SERVFAIL to all queries.

The secondary DNS is a spare machine that is not used for anything else but 
DNS, so no one has touched it other than to update packages on it on well over 
18 months.

Ideas?

(Search pointed me to one bug report for 9.17..mumble that got no answer other 
than 'create a report on git')

-- 
"I don't think the kind of friends I'd have would care."

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

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


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

Signatures expired?

[@lbutlr via bind-users]

In the process of setting u a new domain I noticed that some existing domains 
are logging and error into /var/log/messages

domain.tld.signed:120: signature has expired

Each domain that is expired shows the same :120

The lines in question do refer to old ALG-7 signatures but shouldn’t those go 
away from the signed file (O've been using ALG 13 for a couple of years.
 
-- 
"Are you pondering what I'm pondering?"
"Yes, Brain, I think so, but do nuts go with pudding?"

-- 
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: Adding a new domain with DNSSEC

[@lbutlr]

On 2022 Apr 10, at 05:37, Bjørn Mork  wrote:
> "@lbutlr"  writes:
> 
>> # dnssec-keygen -a 13 example,com
>> # dnssec-keygen -f KSK -a 13 example,com
>> 
>> Add $INLCUDE to the zone file for each of these 4 keys.
> 
> 4? You've generated 2 key pairs. There should be only 2 public keys
> included in the zone.

Ah, right, of course. I knew it was something dumb.

> But I can recommend the automated zone maintenance instead, either using
> the modern "dnssec-policy":

I do have that set, but getting the domain setup in the first place seemed to 
still be necessary.

Now to find the DS key...

-- 
"He has never been known to use a word that might send a reader to
the dictionary." - William Faulkner (about Ernest Hemingway).

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

Adding a new domain with DNSSEC

[@lbutlr]

I have an several domains setup in bind, all with DNSSEC implemented, and am 
trying to add a new domain, and seem to have missed a step.


 # dnssec-keygen -a 13 example,com
 # dnssec-keygen -f KSK -a 13 example,com

Add $INLCUDE to the zone file for each of these 4 keys.

 # dnssec-signzone -3 $(head -c 1000 /dev/random | shasum | cut -b 1-16) -o 
example.com -t example.com

dnssec-signzone: warning: keys/Kexample.com.+013+55923.private:1: unknown RR 
type 'v1.3'
dnssec-signzone: fatal: failed loading zone from 'example.com': unknown 
class/type


-- 
"Are you pondering what I'm pondering?"
"I think so, Brain! But ruby-studded stockingswould be mighty
uncomfortable wouldn't they?"

-- 
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: AA flag

[@lbutlr]

On 2022 Feb 27, at 05:46, Bob McDonald  wrote:
> I'm guessing that the zone files hosted on the new DNS servers still contain 
> NS records pointing to the old DNS servers.

After propagation everything seems to have settled out properly, no errors on 
dnsviz now.

Thanks though.


-- 
Advance and attack! Attack and destroy! Destroy and rejoice!

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

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


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

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

[@lbutlr]

On 2022 Feb 22, at 04:31, Julien Salort  wrote:
> For information, bind 9.18.0 compiles fine under Macports on a variety of 
> systems, including Catalina.

And with homebrew as well, though I don't know what versions  of macOS it does 
back to (Everything here is now on M1s with Monterey).

-- 
All I know is that using the strap makes me feel like a hot woman in
sunglasses. :-) ~jeffcarlson

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

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


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

AA flag

[@lbutlr]

Is this a result of the propagation of DNS still occurring and dnsviz still 
seeing the old DNS servers? The DNS pointers have been changed with the 
registrar, but dnsviz is throwing quite a few errors, including this one.

"DNSKEY: The Authoritative Answer (AA) flag was not set in the response."

It is definitely still showing the old DNS servers in some error messages.

My thought is to wait until the TTL completely expires (2 days in total), but 
if this could indicate something I did incorrectly on my side I'd rather work 
on it now.

Everything looks the same AFAICT as the other domains, only the other domains 
have bind files of example.com.signed and this one ended up with e signed file 
that is just example.net (and a journal file).

-- 
New plan. I give up on Fillory and dedicate myself completely to destroying 
Todd.

-- 
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: nsupdate TSIG error?

[@lbutlr]

On 2022 Feb 24, at 14:19, @lbutlr  wrote:
> I am invoking nsupdate with 

Oh, never mind. Major Brain Fart.


-- 
"Everyone has a photographic Memory, some just don't have film."
~Steven Wright

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

nsupdate TSIG error?

[@lbutlr]

I am invoking nsupdate with 

nsupdate -k /etc/namedb/admin.key

When I make the changes to a domain and `send` I get, 

; TSIG error with server: expected a TSIG or SIG(0)
update failed: REFUSED

/etc/namedb is an alias to /usr/local/etc/namedb/ and admin.jet contains:

# cat admin.key
key "rndc-key" {
   algorithm hmac-sha256;
   secret "stuff=";
};

This is the same key that is in named.conf.

(I am trying to reduce the TTL on the NS servers in preparation for moving the 
domain to be locally hosted, so right now the DNS servers it is pointing to are 
not under my control).

Here's the whole thing wrong show to send:

> zone example.net
> show
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; ZONE SECTION:
;example.net.IN  SOA

> update delete example.net. IN NS ns1.example.com.
> update add example.net. 3600 IN NS ns1.example.com.
> show
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; ZONE SECTION:
;example.net.IN  SOA

;; UPDATE SECTION:
example.net. 0   NONENS  ns1.example.com.
example.net. 3600IN  NS  ns1.example.com.

> send
; TSIG error with server: expected a TSIG or SIG(0)
update failed: REFUSED
>

-- 
I loved you when our love was blessed I love you now there's nothing
left But sorrow and a sense of overtime

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

A record for @?

[@lbutlr via bind-users]

I have a domain that I hot DNS and email for, but not web. I set the A record 
for www.example.com to the IP of the web server with nsupdate, removing the old 
CNAME the pointed to the local webserver, but the web monkey for the new 
website is saying that www has to be a CNAME and the @ record should be the A 
record pointing to the IP.

I don't think this is right, and if it is I am not sure how to use nsupdate to 
make this change.


-- 
'Yes, but humans are more important than animals,' said Brutha. 'This
is a point of view often expressed by humans,' said Om. (Small
Gods)

___
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: non-improving referral

[@lbutlr]

On 2021 Jul 05, at 18:20, Mark Andrews  wrote:
> On 6 Jul 2021, at 06:40, @lbutlr  wrote:
>> DNS format error from 64.70.78.82#53 resolving ok.contact/NS for 
>> 127.0.0.1#16749: non-improving referra
> 
> This is an error with the delegation of ok.contact.  The NS records at the 
> delegation point do not match those at the zone apex.

Ah, thank you. I should have realized that was a domain.

Too many TLDs. Why in my day, in my day there were like 5 and that was good 
enough for everyone! .edu .org .com… Three! There were three! :)

-- 
Like so many Americans, she was trying to construct a life that
made sense from things she found in gift shops.

___
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

non-improving referral

[@lbutlr]

I've been getting a few errors along these lines (bind 9.16.18), the IPs 
changes, but I don't know what "non0improving referral" means or if I should be 
concerned. 

DNS format error from 64.70.78.82#53 resolving ok.contact/NS for 
127.0.0.1#16749: non-improving referra

This IP is  owned bv CenturyLink, which was the company providing our Internet 
service (they have recently become something called "Lumen", but the IP blocks 
respond as savvin.net).

Other IPs have appeared, but I did not note them as the logs rolled as I was 
distracted by other issues at the time.

My concern is that they may point to a configuration issue on my end, though 
dnsviz is happy.


-- 
Bart, don't use the Touch of Death on your sister.

___
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: Any interest in a write-up showing how to configure BIND 9.17x with DoH and LetsEncrypt?

[@lbutlr via bind-users]

On 30 May 2021, at 12:23, Grant Taylor via bind-users 
 wrote:
> On 5/30/21 9:24 AM, Richard T.A. Neal wrote:
>> I spent a little time this weekend setting-up BIND 9.17.13 on Ubuntu 21.04 
>> and configuring the system as a recursive resolver offering DNS over HTTPS 
>> using a LetsEncrypt certificate.
> 
> Nice work.
> 
>> Is there any interest in me writing this up as a web article, or has 
>> everyone who’s interested in DoH already got it running comfortably in their 
>> test environment?
> 
> Yes!

+1

Or, perhaps, +100


-- 
NO ONE WANTS TO HEAR FROM MY ARMPITS Bart chalkboard Ep. 3F01

___
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: DNSSEC upgrade

[@lbutlr]

On 30 Apr 2021, at 12:15, Tony Finch  wrote:
> 
>   dig +ttlunits example.com ds @$(dig +short com ns | head -1)

I update the last of my zones over a month ago and they are still showing 
alg-7. The longest TTL int e zone files is 2w, but we're 29 days in.

Te signed file has

RRSIG   SOA 7 2 86400 (
20210509074649 20210425064649 45309 example.com.
Oj+ObzW/dle9fJHffNqNCVd9udd8AQwxRXcq/BF5+fUu
wyS5Gb0htl2hrwyAXK24sA4aZ4RUiwNoKwJTeOGZPWeC
O2Eb2PkjsNUmd9UaIWKYrFroI8FZsqh4g8lM/YEdnpAq
GeekIXFT4s6xE8lRC3Rcx88b8YBRNnSxiy/8xqI= )
RRSIG   SOA 13 2 86400 (
20210509074649 20210425064649 11217 example.com.
yzrM5cWL6UYhzJ4cS+hMcZShBqwFZZR6LVRYntehHzVN
vBSzUBNNf6u6BdQSAyQFbjD5R9g5HEKtei1yIADx8g== )

I'm sure I missed a step on these specific domains, but there are only a 
handful that are still using alg-7 and many more that are now on alg-13 only. 
The +ttlunits from above show 1d for the answer sections and 2d in the 
authority (com.) section.

If I do a dig ds on the domain (at 8.8.8.8 or others, in addition to my own 
bind server), I only get the alg-13 key, but +dnssec shows both RRSIGs

Ideas?

-- 
'Somewhere, A Crime Is Happening,' said Dorfl. --Feet of Clay

___
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: CVE-2021-25216

[@lbutlr]

On 30 Apr 2021, at 08:21, Jordan Tinsley  wrote:
> Is BIND 9.11.6 (Extended Support Version) vulnerable?
> 
> Is BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.3 (Extended Support Version) 
> vulnerable?

The CVE descriptions indicates both of those versions are vulnerable.

"In BIND 9.5.0 -> 9.11.29 … configured to use GSS-TSIG features" is how the 
description starts. 


-- 
Wally: That's my nickname, "Waly" with one el.
Dilbert: Who calls you that?
Wally: Most people, they just don't realize it.

___
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: Deprecating BIND 9.18+ on Windows (or making it community improved and supported)

[@lbutlr]

On 29 Apr 2021, at 05:35, Ondřej Surý  wrote:
> * Windows now has WSL2 
> (https://docs.microsoft.com/en-us/windows/wsl/install-win10) that can be used 
> to run BIND 9 natively

I'd suggest this be the first listed reason as it pretty much makes all the 
other reasons irrelevant. OTOH, I don't have a dog in this race.


-- 
And she was drifting through the backyard And she was taking off her
dress And she was moving very slowly Rising up above the earth

___
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: Preventing a particular type of nameserver abuse

[@lbutlr]

On 13 Apr 2021, at 04:02, Anand Buddhdev  wrote:
> A legitimate client, following a normal chain of referrals, has *no*
> reason to query a server for zones it is not authoritative for.

Well, that's not really true. A mobile user might have their device configured 
to always check their corporate DNS server first, for example, then fall back 
if that fails.

Refusing makes everything faster, ignoring breaks things and makes things 
slower.

When a DNS host refuses a query, it will not be queried again, wen it times 
out, is is still in the rotation.

> Most of the time, such a query would only arrive at a name server from a 
> naughty
> client.

Unlikely as there is no benefit to the "naughty" client. This is not a 
amplification attack, the refusal is a short packet, meaning the query from the 
client is probably larger than the response. Very inefficient for naughty 
clients.

> And then, replying with any response, even REFUSED, is
> satisfying this client's naughtiness.

How?

> I think it's quite okay for an authoritative name server to simply DROP
> UDP queries for zones

It's not.

> that it's not authoritative for. It's better to
> ignore naughty clients, and give them the cold shoulder, and not
> participate in reflection attacks using REFUSED responses.

How do you imagine this is a reflection attack? It is far too small to be an 
effective attack for anything.


-- 
'Today Is A Good Day For Someone Else To Die!' --Feet of Clay

___
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: Zone 126.0.0.1 has 0 SOIA records

[@lbutlr]

On 12 Apr 2021, at 07:04, Matthijs Mekking  wrote:
> Perhaps inspect the zone file?

Ah, since it is named localhost-reverse.db I assumed it was not plain txtm but 
some db format.

>>>FILE
$ORIGIN .
$TTL 3600   ; 1 hour
0.ip6.arpa  IN SOA  localhost. nobody.localhost. (
48 ; serial
86400  ; refresh (1 day)
43200  ; retry (12 hours)
604800 ; expire (1 week)
10800  ; minimum (3 hours)
)
NS  localhost.
CDS 0 0 0 (
00 )
CDNSKEY 0 3 0 (
AA==
) ; ZSK; alg = 0 ; key id = 768
$ORIGIN 0.0.0.ip6.arpa.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR localhost.
1   PTR localhost.
FILE

That looks… very wrong. I wonder what happened. OK, storing that file from 
backup too.

> Also the CDS/CDNSKEY consistency checks stick out. Perhaps remove them from 
> the unsigned zone files?

Yeah, I don't know what happened to these files; they should be the default 
ones FreeBSD makes )they are, now, once again)

Thank you so much, I would never have found that.

-- 
Keep Virginia clean...throw your trash into Maryland.

___
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

Zone 126.0.0.1 has 0 SOIA records

[@lbutlr]

I restored a backup of my named.conf after a little bit of an oops. The file is 
the same exact file as it was yesterday, bt on starting bind I get:

named[24161] 
named[24161] BIND 9 is maintained by Internet Systems Consortium,
named[24161] Inc. (ISC), a non-profit 501(c)(3) public-benefit
named[24161] corporation.  Support and training for BIND 9 are
named[24161] available at https://www.isc.org/support
named[24161] 
named[24161] command channel listening on 127.0.0.1#953
named[24161] zone localhost/IN: CDS/CDNSKEY consistency checks failed
named[24161] zone localhost/IN: not loaded due to errors.
named[24161] /usr/local/etc/namedb/working/localhost-reverse.db:3: ignoring 
out-of-zone data (0.ip6.arpa)
named[24161] /usr/local/etc/namedb/working/localhost-reverse.db:17: ignoring 
out-of-zone data 
(1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa)
named[24161] /usr/local/etc/namedb/working/localhost-reverse.db:18: ignoring 
out-of-zone data (1.0.0.0.ip6.arpa)
named[24161] zone 127.in-addr.arpa/IN: has 0 SOA records
named[24161] zone 127.in-addr.arpa/IN: has no NS records
named[24161] zone 127.in-addr.arpa/IN: not loaded due to errors.
named[24161] zone 0.ip6.arpa/IN: CDS/CDNSKEY consistency checks failed
named[24161] zone 0.ip6.arpa/IN: not loaded due to errors.
named[24161] all zones loaded
named[24161] DNS format error from 82.192.82.228#53 resolving 
112.242.54.110.in-addr.arpa/PTR for 65.121.55.44#55292: Name in-addr.arpa (SOA) 
not subdomain of zone 242.54.110.in-addr.arpa -- invalid response
named[24161] DNS format error from 82.192.82.228#53 resolving 
112.242.54.110.in-addr.arpa/PTR for 127.0.0.1#27795: Name in-addr.arpa (SOA) 
not subdomain of zone 242.54.110.in-addr.arpa -- invalid response

This last repeats periodically

Stoping and starting named don't clear the error, but named appears to be fine 
(checking domains returns expected results). Key files are updating every hour 
as expected. The secondary servers are in sync…


-- 
"Life is one damned kitten after another." Mehitabel the Alley Cat

___
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: Still seeing some ALG-7 DNSSE

[@lbutlr]

> On 12 Apr 2021, at 01:12, Matthijs Mekking  wrote:
> 
> 
> 
> On 11-04-2021 01:22, @lbutlr wrote:
>> On 06 Apr 2021, at 01:13, Matthijs Mekking  wrote:
>>> In 9.16.13, a new "dnssec-policy" option is introduced, "purge-keys". By 
>>> default the keys are retained for 90 days after their latest usage. So in 
>>> that case keys will be cleaned up automatically.
>> Excellent. Does that go in the zone record with default, or does it replace 
>> default> I don't see the syntax in the release notes.
> 
> If you don't set "purge-keys" it will be retained for 90 days. Otherwise, set 
> it inside the 'dnssec-policy' you are using. In other words, If you want 
> something else, use this:
> 
> dnssec-policy "myway" {
>purge-keys P30D;
>...
>// other policy options
> };

I am using dnssec-policy default, not my own dnssec policy

>> Or do I add a
>> dnssec-policy "default" {
>>   purge-keys 30; // (or is that field seconds?)
>> }
>> Or will that mess up the predefined for default?
> 
> First, you cannot (re)configure "default" policy, it is a builtin policy.

I found that out, yes.

> You can configure a new policy and just add a single option "purge-keys". 
> Zones with that policy will act the same as the default policy except for how 
> long to retain keys.

So, I have to add a new policy to every zone? That's annoying. I was hoping to 
force the old keys to go away faster.

> The field is a ttl value or a ISO 8601 duration. So a number is treated as 
> seconds. If you want 30 days, use 30d or P30D.

Thank you, I may just wait and see what happens. Though no alg-7 files have 
been deleted yet, even for domains that are not reporting any alg-6 o dnsviz 
(and they are updated every hour) along with the lag-13 key.

-- 
I CAN BE ROBBED BUT NEVER DENIED, I TOLD MYSELF. WHY WORRY?  'I too
cannot be cheated,' snapped Fate. SO I HAVE HEARD.

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

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


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

Dnssec-policy Purge-keys

[@lbutlr via bind-users]

Doe anyone know the syntax for using purge-keys in 9.16.13? I've search and all 
I can find is notes that it was added. I've tried a couple of things, but I am 
shooting in the dark. I cannot redefine the "default" policy as that gives and 
error and simply putting "purge-keys P90D;" or "dnssec-policy purge-keys P90D;" 
in options files.

I'm sure it's simple, but simply what?

-- 
So, the apocalypse is happening and whatever and this little piggy comes all
this way, but you won’t accept my help because I’m a woman?
Pig: Quite right.

___
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: Still seeing some ALG-7 DNSSE

[@lbutlr]

On 06 Apr 2021, at 01:13, Matthijs Mekking  wrote:
> In 9.16.13, a new "dnssec-policy" option is introduced, "purge-keys". By 
> default the keys are retained for 90 days after their latest usage. So in 
> that case keys will be cleaned up automatically.

Excellent. Does that go in the zone record with default, or does it replace 
default> I don't see the syntax in the release notes.

Or do I add a 

dnssec-policy "default" {
  purge-keys 30; // (or is that field seconds?)
}

Or will that mess up the predefined for default?

-- 
'There has to be enough light,' he panted, 'to see the darkness.'

___
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

Still seeing some ALG-7 DNSSE

[@lbutlr]

If I do:

cd /etc/named/working/main/
for i in *; do dig $i +dnssec | grep "A 13 2" | awk '{print $1}';done

I see a list of all the domains on the system, so that's good, everything has a 
ALG-13 signature.

If I do

for i in *; do dig $i +dnssec | grep "A 7 2" | awk '{print $1}';done

I see a list of a handful of domains that still have ALG-7 signatures. This is 
confirmed by a warning in dnsviz.

I don't see any differences in the configurations, and none of the main records 
on the registrar list ALG-7 anymore, only ALG-13.

All of the domains are setup with  dnssec-policy default.

Thera re still 007 keyholes on the system for ALL domains (unexpected), updated 
every hour  (expected).

 8 -rw-r--r--  1 bind  bind   1.0K Apr  5 06:21 Kkreme.com.+007+01083.key
 8 -rw-r--r--  1 bind  bind   587B Apr  5 06:21 Kkreme.com.+007+01083.state
 8 -rw---  1 bind  bind   3.3K Apr  5 06:21 Kkreme.com.+007+01083.private
 8 -rw-r--r--  1 bind  bind   708B Apr  5 06:21 Kkreme.com.+007+30512.key
 8 -rw-r--r--  1 bind  bind   520B Apr  5 06:21 Kkreme.com.+007+30512.state
 8 -rw---  1 bind  bind   1.8K Apr  5 06:21 Kkreme.com.+007+30512.private
 8 -rw-r--r--  1 bind  bind   399B Apr  5 06:21 Kkreme.com.+013+29597.key
 8 -rw-r--r--  1 bind  bind   651B Apr  5 06:21 Kkreme.com.+013+29597.state
 8 -rw---  1 bind  bind   215B Apr  5 06:21 Kkreme.com.+013+29597.private

This domain does not show any ALG-7 keys in dig:

# dig kreme.com +dnssec +short
65.121.55.45
A 13 2 3600 20210415161448 20210401155316 29597 kreme.com. 
Sea2LPlKGeH/aP1kwONwtuH0Jkp2TVHNb/v9PEOUiVQVzCwKMkg79+K9 
bE8yhNQ2vLV4Fxvzk4jknP8Cbq98lQ==

Is there anything I need to do here or not? Will those alg-7 key files continue 
to hang around forever? Do I need to do something to get dnsviz and dig +dnssec 
to stop reporting the old keys or is that like propagation and it will sort 
itself out? I don't see a pattern in the domains that are still showing alg-7 
but it is possible they had the DS/registrar info updated later than the other 
domains.

-- 
I loved you when our love was blessed I love you now there's nothing
left But sorrow and a sense of overtime

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

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


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

Re: BIND 9.16.13 and Mac OS X 10.13.6 - problems with ./configure

[@lbutlr]

On 26 Mar 2021, at 14:32, alcol alcol  wrote:
> seriously? is like linux/unix FAQ 

Oh, I would say learning how to post to mailing lists in linux/unix 101. 
Perhaps you could review that yourself and not send bloated messages full of 
HTML garbage?

-- 
"Are you pondering what I'm pondering?"
"Well, I think so, Brain, but snort no, no, it's too stupid!"

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

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


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

Dnssec delegation NS RRset

[@lbutlr via bind-users]

I am getting the following warning:

The following NS name(s) were found in the authoritative NS RRset, but not in 
the delegation NS RRset (i.e., in the com zone): (a DNS server)

The DNS server exists and is used by other domains, so This is something 
specific to this one domain and not to the DNS servers, so I think it must be 
something on the registrar.

Missing glue records?

-- 
You have the effrontery to be squeamish, it thought at him. But we
were dragons. We were supposed to be cruel, cunning, heartless,
and terrible. But this much I can tell you, you ape - the great
face pressed even closer, so that Wonse was staring into the
pitiless depths of his eyes - we never burned and tortured and
ripped one another apart and called it morality. --Guards!
Guards!

___
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: DoH Support in bind 9.17?

[@lbutlr]

On 24 Feb 2021, at 03:38, Ondřej Surý  wrote:
>> On 24. 2. 2021, at 11:36, @lbutlr  wrote:

>> I also see this note from last year:
>> 
>> <https://gitlab.isc.org/isc-projects/bind9/-/wikis/BIND-9.17-Plan>
>> "September 2020 DoH backported to Extended Support Version (9.16) of BIND 9”

> There’s this joke - if you want to make god(s) laugh then make plans…
> 
> This is going to happen, but the development team needs to polish it bit more 
> before
> backporting such large feature to the stable release.

Ah, I read that as something that had happened.


-- 
I got up one morning, couldn't find my socks, so I called
Information. She said, "Hello, Information." I said, "I can't
find my socks." She said, "They're behind the couch." And they
were! -- Steven Wright

___
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: DoH Support in bind 9.17?

[@lbutlr]

On 23 Feb 2021, at 23:02, Evan Hunt  wrote:
> DoH is supported in named in 9.17.10 (server side only).  Client-side
> support will be added to dig in 9.17.11.

There's 9.17.10? I have 9.16.12 and see no sign of 9.17.x in FreeBSD ports. Is 
it "bind9-devel"?

I seem to recall something about the odd and even versions of bind that made me 
thing it was preferable to wait for bind 9.18 to move from bind 9.16.

I also see this note from last year:


"September 2020 DoH backported to Extended Support Version (9.16) of BIND 9"

-- 
"Are you pondering what I'm pondering?"
"I think so, Brain, but calling it pu-pu platter? Huh, what were they
thinking?"

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

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


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

Re: Bind 9.11 serving up false answers for a single domain.

[@lbutlr]

On 11 Feb 2021, at 16:38, John W. Blue via bind-users 
 wrote:
> I have found to tshark to be useful as well but the failing it has is that it 
> is generally not included in a unix OS distribution.

Is bind? I mean, I have to install a bunch of stuff right off on a new bistro 
just to get a useable (for me) system. And if it's Linux I often have to 
UNinstall some things as well. I don't care about the purity of the 
distributions software set.

-- 
Hey kids, shake it loose together the spotlight's hitting something
That's been known to change the weather we'll kill the fatted
calf tonight So stick around you're gonna hear electric music:
Solid walls of sound

___
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: DNSSEC and NSEC missing ZSK?

[@lbutlr]

On 09 Feb 2021, at 16:19, Mal via bind-users  wrote:
> On 09/02/2021 10:47 pm, @ wrote:
>> Well, I have finally ogttenteh test zone to the point where dnssec-verify is 
>> happy and everything that I can check also seems happy except dnsviz which 
>> is very very VERY angry and basically says the zone is entirely garabge. I 
>> am hoping this is a propagation issue, but I kind of doubt it since it 
>> should be quarrying the authoritative DNS for the DNSKEY and RRSIG and such, 
>> I'd think.

> The easiest way to get help is to post your named.conf and zone file. 

Not doing that for domains that are not actually owned by me, which includes 
the domain I was using to test this setup.

> DNSVIZ displays your current state very well.  If its showing you
> errors, then it requires you to act.

Seems not to be the case as after 10 hours or so, dnsviz has stopped 
complaining.

-- 
Heisenberg's only uncertainty was what pub to vomit in next and Jung
fancied Freud's mother too. -- Jared Earle

___
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: DNSSEC and NSEC missing ZSK?

[@lbutlr]

> On 08 Feb 2021, at 07:24, Matthijs Mekking  wrote:
> 
> Hi,
> 
> On 08-02-2021 12:20, @lbutlr wrote:
>> I feel I am getting close. I got the digest generated for hover.com and 
>> updated the DNS on the test zone, but I am getting errors on verify that I 
>> don't understand.
>> #v+
>> # dnssec-verify -I text -o example.com /etc/namedb/working/example.com.signed
>> Loading zone 'example.com' from file '/etc/namedb/working/example.com.signed'
>> Verifying the zone using the following algorithms:
>> - ECDSAP256SHA256
>> Missing ZSK for algorithm ECDSAP256SHA256
>> Missing NSEC record for blog.example.com
>> Missing NSEC record for wiki.example.com
>> Missing NSEC record for foobar.example.com
>> Missing NSEC record for barfoo.example.com
>> The zone is not fully signed for the following algorithms:
>>  vECDSAP256SHA256
>> .
>> DNSSEC completeness test failed.NSSEC completeness test failed.
>> #v-
>> The missing ZSK is throwing me, and I don't know what to add to my zone 
>> record for NSEC. I am following along (trying) with 
>> https://bind9.readthedocs.io/en/latest/dnssec-guide.html which makes no 
>> mention of this, but shows NSEC showing up in the output of the signed file.
> 
> Use dnssec-verify -z to indicate that the ZSK may be the same key as the KSK.

Thanks, so that is sorted.

> The missing NSEC records are more worrisome.

Oddly, some of the NSEC entries are in the signed zone file (well, I assume 
that is what this means):

NSECblog.example.com. A NS SOA MX TXT RRSIG NSEC DNSKEY CDS CDNSKEY 
TYPE65534
RRSIG   NSEC 13 2 3600
NSECwiki.example.com. CNAME RRSIG NSEC
RRSIG   NSEC 13 3 3600 (

)all the subdomains are CNAME

And some other occurrences of NSEC, but not the home and foobar or barfoo.

>> #v-
>> Is there a way to force rndc/bind to recreate the .signed file? If I move it 
>> aside and restart named or rndc reload or rndc reconfig, the signed zone 
>> file is not recreated.
> 
> 
> rndc sign zone

That recreates the .signed.jnl and not the .signed file. No errors are reported.


-- 
How you have felt, o men of Athens, at hearing the speeches of my
accusers, I cannot tell; but I know that their persuasive words
almost made me forget who I was, such was the effect of the,; and
yet they have hardly spoken a word of truth.

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

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


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

DNSSEC and NSEC missing ZSK?

[@lbutlr]

I feel I am getting close. I got the digest generated for hover.com and updated 
the DNS on the test zone, but I am getting errors on verify that I don't 
understand.

#v+
# dnssec-verify -I text -o example.com /etc/namedb/working/example.com.signed
Loading zone 'example.com' from file '/etc/namedb/working/example.com.signed'

Verifying the zone using the following algorithms:
- ECDSAP256SHA256
Missing ZSK for algorithm ECDSAP256SHA256
Missing NSEC record for blog.example.com
Missing NSEC record for wiki.example.com
Missing NSEC record for foobar.example.com
Missing NSEC record for barfoo.example.com
The zone is not fully signed for the following algorithms:
 vECDSAP256SHA256
.
DNSSEC completeness test failed.NSSEC completeness test failed.
#v-

The missing ZSK is throwing me, and I don't know what to add to my zone record 
for NSEC. I am following along (trying) with 
https://bind9.readthedocs.io/en/latest/dnssec-guide.html which makes no mention 
of this, but shows NSEC showing up in the output of the signed file.

The only thing I can find that seems relevant (though it is for bind 9.7.3) is 
part of the key generation, but I did not generate the keys manually, bind did 
that with dnssec-policy default;

#v+
; This is the state of key 18434, for example.com.
Algorithm: 13
Length: 256
Lifetime: 0
KSK: yes
ZSK: yes
Generated: 20210202180145 (Tue Feb  2 11:01:45 2021)
Published: 20210202180145 (Tue Feb  2 11:01:45 2021)
Active: 20210202180145 (Tue Feb  2 11:01:45 2021)
PublishCDS: 20210203190645 (Wed Feb  3 12:06:45 2021)
DNSKEYChange: 20210202200645 (Tue Feb  2 13:06:45 2021)
ZRRSIGChange: 20210203190645 (Wed Feb  3 12:06:45 2021)
KRRSIGChange: 20210202200645 (Tue Feb  2 13:06:45 2021)
DSChange: 20210203190645 (Wed Feb  3 12:06:45 2021)
DNSKEYState: omnipresent
ZRRSIGState: omnipresent
KRRSIGState: omnipresent
DSState: rumoured
GoalState: omnipresent
#v-

So the state file says the ZSK is yes, but dnssec-verify says no.

I ran delv test and it looks as I expect based on he guide linked above.

#v+
# delv @127.0.0.1 -a /tmp/Kexample.com.+013+18434.key +root=example.com 
example.com SOA +multiline
; fully validated
example.com.  3600 IN SOA ns1.example.net. admin.example.net. (
2018022422 ; serial
300; refresh (5 minutes)
300; retry (5 minutes)
18000  ; expire (5 hours)
3600   ; minimum (1 hour)
)
example.com.  3600 IN RRSIG SOA 13 2 3600 (
20210221095138 20210207085138 18434 example.com.
Qps8u4m6…=
#v-

Is there a way to force rndc/bind to recreate the .signed file? If I move it 
aside and restart named or rndc reload or rndc reconfig, the signed zone file 
is not recreated.

-- 
'I don't see why everyone depends on me. I'm not dependable. Even I
don't depend on me, and I'm me.'

___
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: Scripting dnssec-verify - processing command output

[@lbutlr]

On 06 Feb 2021, at 17:45, Paul Kosinski via bind-users 
 wrote:
> It sounds to me like dnssec-verify is sending the output in question to 
> STDERR instead of STDOUT.

Dnssec-verify sends errors (like missing /Bad/Expected lines) to stderr, it 
sends status warnings like "The zone is not fully signed" to stdout.

Easy to see that the output is by adding 2>/dev/null to your command on the 
shell and seeing what goes where.

On my system messages like 

Zone fully signed:
Algorithm: … 

appear on stdout.

-- 
BART BUCKS ARE NOT LEGAL TENDER Bart chalkboard Ep. 8F06

___
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

DNSKEY failure

[@lbutlr]

So, with my test domain that is using dsnssec-policy default dnsviz reports 

"DNSKEY: No response was received from the server over UDP"

But:

dig +norec +dnssec +bufsize=512 +ignore dnskey

Shows a DNSKEY record.

(There is no DNSKEY record shown on the domains still using auto-dnssec 
maintain; with alg-7 keys, but I think that is expected).

Is this a propagation issue, or is there something I need to do for 
"192.112.36.4, UDP_-_EDNS0_512_D_KN" to see the DNSKEY record?

example.com.  3600IN  RRSIG   DNSKEY 13 2 3600 20210217190645 
20210203180645 18434 example.com. {blah blah blah}


-- 
"Get your facts first, and then you can distort them as much as you
please." - Mark Twain

___
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

$INCLUDE in zone file?

[@lbutlr]

Is the mechanism of using $INCLUDE  in the zone file still used? 

If so, do I need to update the  when moving to a new alg method or 
are they only used when initially creating a signed zone file or are they no 
longer needed at all?

-- 
'I'll tell you this!' shouted Rincewind. 'I'd rather trust me than
history! Oh, shit, did I just say that?'

___
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: Updating a DNSSEC config to use a different algorithm

[@lbutlr]

On 02 Feb 2021, at 07:36, Matthijs Mekking  wrote:
> If the PDF is not working for you, perhaps https://bind9.readthedocs.io/ 
> suits you better?

The PDF works fine, and I can search for "dnssec" and "policy" but it is using 
some emdash or similar character for the - in between which makes searching an 
issue (even if I copy the text from the PDF and then search for what.I copied).

>> (This domain has a RRSIG range of 2021010953 - 20210221230953)
>> I am guessing as soon as I add that DNSSEC-policy I also need to change each 
>> domain record from "auto-dnssec maintain;" to "dnssec-policy default;" or do 
>> I do that after the .state files have been created? (That doesn't sound 
>> right, but best to check).
> 
> I guess with "each domain record" you mean "each zone".

Yes. I still think of them as domains (because they are all domains in my case).

> If you are migrating, don't change it to "dnssec-policy default;". This is a 
> built-in policy that does not match your existing keys.

OK, now I am a bit confused.

In named.conf there is dsnssec-policy alg13-ksk-unlimited-zsk-60day { … 

Then in the zone currently I have:

zone "kreme.com" { type primary; file "kreme.com.signed"; auto-dnssec maintain; 
allow-update { key "rndc-key"; }; }

Are you saying I need to change auto-dnssec maintain; to "dsnssec-policy 13;"?

> I would recommend to first check if the .state files look correct before 
> changing your dnssec-policy (do the keys in your zone match the .state file? 
> Are the states set to OMNIPRESENT? Is the goal set to OMNIPRESENT?

I did this with a domain that does not get email as a test:

#v+
named.conf:
dnssec-policy alg13-ksk-unlimited-zsk-60day {
keys {
   ksk key-directory lifetime unlimited algorithm 7 2048;
   zsk key-directory lifetime P60D algorithm 7 1024 ;
};
};

zone "example.com" { type primary; file "example.com.signed"; dnssec-policy 
default; allow-update { key "rndc-key";}; };

; This is the state of key 2611, for mrsbutler.com.
Algorithm: 13
Length: 256
Lifetime: 0
KSK: yes
ZSK: yes
Generated: 20210202134627 (Tue Feb  2 06:46:27 2021)
Published: 20210202134627 (Tue Feb  2 06:46:27 2021)
Active: 20210202134627 (Tue Feb  2 06:46:27 2021)
PublishCDS: 20210203145127 (Wed Feb  3 07:51:27 2021)
DNSKEYChange: 20210202155127 (Tue Feb  2 08:51:27 2021)
ZRRSIGChange: 20210202134627 (Tue Feb  2 06:46:27 2021)
KRRSIGChange: 20210202155127 (Tue Feb  2 08:51:27 2021)
DSChange: 20210202134627 (Tue Feb  2 06:46:27 2021)
DNSKEYState: omnipresent
ZRRSIGState: rumoured
KRRSIGState: omnipresent
DSState: hidden
GoalState: omnipresent
#v-

I also have new key and private and state files for the alg 7 KSK and ZSK files 
for the zone I am testing with, and the old files are gone, so I think it 
migrated correctly?

But I guess that is what you meant by it using a single key for KSK and ZSK?

Is there a reason NOT to use default? If I use default can I then eliminiate 
the dnssec-policy alg13-ksk-unlimited-zsk-60day { … } block entirely once the 
new keys and state files are created?

I tried to use `rndc dnssec -checkds published example.com" but it wants a -key 
and doesn't seem to want the name of the .key file, so not sure what the syntax 
is there and the man page on rndc isn't helping. Status, on the other hand:

# rndc dnssec -status example
dnssec-policy: default
current time:  Tue Feb  2 10:01:32 2021

key: 1058 (NSEC3RSASHA1), ZSK
  published:  no
  zone signing:   no

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

key: 37515 (NSEC3RSASHA1), KSK
  published:  no
  key signing:no

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

key: 2611 (ECDSAP256SHA256), CSK
  published:  yes - since Tue Feb  2 06:46:27 2021
  key signing:yes - since Tue Feb  2 06:46:27 2021
  zone signing:   yes - since Tue Feb  2 06:46:27 2021

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

Am I concerned about "No rollover scheduled"? O do noe that the removal of the 
alg 7 from the records is a problem as the registrar still has them listed and 
I do not know what the digest or "Key tag" are to update the record on the 
registrar, so yep, I obviously did something wrong here.

Good thing I am testing.


-- 
"Are you pondering what I'm pondering?"
"I think so, Brain, but why would anyone want a depressed tongue?"

___
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

Re: Updating a DNSSEC config to use a different algorithm

[@lbutlr]

On 02 Feb 2021, at 02:23, Matthijs Mekking  wrote:
> 1. Create a dnssec-policy that matches your current keys (so in your case 
> algorithm 7, also make sure you use the same length).
> 
> So I guess something like:
> 
>dnssec-policy alg13-ksk-unlimited-zsk-60day {
>keys {
>ksk key-directory lifetime unlimited algorithm 7 2048;
>zsk key-directory lifetime P60D algorithm 7 1024 ;
>};
>};
> 
> This is an assumption. Check the key length with your existing keys.

Yes, the current keys are alg 7 2048 bit. Is there a document on the various 
options here? I am plowing through the "BIND 9 Administrator Reference Manual, 
Release BIND 9.16.5 (Stable Release)" but it is slow going right now and 
"dnssec-policy" does not appear in the pdf in a searchable form, which makes 
things even more fun).

(This domain has a RRSIG range of 2021010953 - 20210221230953) 

I am guessing as soon as I add that DNSSEC-policy I also need to change each 
domain record from "auto-dnssec maintain;" to "dnssec-policy default;" or do I 
do that after the .state files have been created? (That doesn't sound right, 
but best to check).

> Now that you have migrated your existing key files (they will now have a 
> .state file), you can reconfigure your dnssec-policy with a new algorithm,. 
> The alg-7 keys will be gracefully removed from the zone, while new keys with 
> a new algorithm will be introduced.

So once all the domains have a .state file associated with them in the key 
directory I can change the dnssec-policy to the sample I had before and it will 
just migrate from the alg 7 keys above to alg ECDSAP256SHA256 (or I can just 
say alg 13 instead).

#v+
dnssec-policy alg13-ksk-unlimited-zsk-60day {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime P60D algorithm 13;
};
};
#v-

That seems very straightforward, there must be a catch somewhere.

-- 
I want a refund, I want a light, I want a reason for all this night
after night after night after night

___
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: Updating a DNSSEC config to use a different algorithm

[@lbutlr]

On 01 Feb 2021, at 07:14, Matthijs Mekking  wrote:
> Depends on what your DNSSEC configuration is. Are you using 
> dnssec-signzone/named? auto-dnssec maintain? inline-signing? dnssec-policy? 
> dnssec-keymgr?

These are all good questions, and when I set this up I could have answered with 
some degree of confidence.

What I have in named.conf is simply dnssec-validation auto; and domains have 
auto-dnssec maintain, so I guess that answers that question.

> Yes there are a lot of ways to maintain DNSSEC in BIND. The recommended way 
> forward is to use dnssec-policy. Migrating to it may still be a bit tricky*, 
> but once you use it, changing a new signing algorithm is pretty simple:
> 
> 1. Update your dnssec-policy, reload config.

Assuming there is no dnssec-policy (there is not) what would I update it to?

This did give me enough to DDG on, does this link look reasonable?



#v+
dnssec-policy alg13-ksk-unlimited-zsk-60day {
 keys {
 ksk key-directory lifetime unlimited algorithm ECDSAP256SHA256;
 zsk key-directory lifetime P60D algorithm ECDSAP256SHA256;
 };
};
#v-

If so, what are the possible values for the algorithm? And for the actual 
policy (alg13-…)? I also see mention of a dissed-policy default but that is out 
of context so I don't know if that is simply telling the domain to use the 
policy defined separately in the the named.conf as above. Alg13-ksk gives two 
hits on DDG, and the second one is in Japanese.

> 2. Wait a little bit.
> 3. When the new DS is in the parent, run "rndc dnssec -checkds published
>   on the right key id."
> 4. Also run "rndc dnssec -checkds withdrawn" on the id of the key that
>   has its DS removed from the parent.
> 5. Have a celebratory drink.

Way ahead of you there! 弄

> *In principal you can just switch to dnssec-policy with your existing key 
> files and BIND will initialize key state files for those keys. But there is 
> at least one known bug that deleted keys may be used again for signing (those 
> deleted keys still have their key files in the key directory). [GL #2406]

Hopefully that will not be an issue as there are no old key files. Or rather 
they are all about the same age of Jan-Feb of 2019,

-- 
'I don't see why everyone depends on me. I'm not dependable. Even I
don't depend on me, and I'm me.'

___
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

Updating a DNSSEC config to use a different algorithm

[@lbutlr]

I've been using alg-7 for DNS, but that is no longer recommended. How difficult 
is it to change the signing algorithm and what is the process (Bind 9.16.11)?


-- 
"He raised his hammer defiantly and opened his mouth to say, "Oh,
yeah?" but stopped, because just by his ear he heard a growl. It
was quite low and soft, but it had a complex little waveform
which went straight down into a little knobbly bit in his spinal
column where it pressed an ancient button marked Primal Terror."

___
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: Quick dynamic DNS?

[@lbutlr]

On 23 Dec 2020, at 21:23, Grant Taylor via bind-users 
 wrote:
> On 12/23/20 6:53 PM, @lbutlr wrote:
>> Give that I have a authoritative bind9 server for example.com and given that 
>> I have a home connection that is (technically) dynamic home.example.com what 
>> is the easiest way for me to automatically update the DNS on the rare 
>> occasions that it changes?
> 
> I assume:
> 
> 1)  That example.com is a stand in for the real domain name(s)

That is what example.com always is, yes.

> 2)  Your bind9 server is somewhere on the Internet

As I said, it is authoritative for example.com.

> 3)  You are asking how to dynamically update it to change where 
> home.example.com resolves to.

Yep.

>> The example.com domain is setup with DNSSEC and the home connection has a 
>> rPI already acting as an unbound/piHole server, if that helps.
> 
> Are you wanting to do some sort of zone transfer from the rPI to BIND?

No, I just want my bind server to get updated with the external IP of my home 
connection when it changes and update the A pointer.

> Is home.example.com public or private?  Can the world query it?

The world can reach my home connection, but no the world cannot send DNS 
queries to it since it does not run an external DNS server (unbound is just a 
catching server, piHole is a DNS blocker that prevents LAN machines from 
reaching known bad hosts).

>> I used to use a dynamic DNS service, but I figure I have the tools available 
>> to do this all myself. What am I doing right now is just manually changing 
>> the IP.
> 
> ACK
> 
> I'm going to further assume:
> 
> 4)  That you have home.example.com delegated to the rPI at your house.

No, I just have home.example.com as a A record the points to my home IP 
address. There is no delegations and no subdomains for home.example.com.

> 5)  That you want to dynamically update this delegation.

I just want to update the IP address in a single A record.

> You can use BIND's support for Dynamic DNS across the Internet.  (I can't 
> speak to the security of such.)  I assume that you will be using something 
> like TSIG keys or Kerberos to authenticate your Dynamic DNS updates.  
> (Possibly even a VPN or the likes.)

Possibly, though that is certainly part of what I am asking.

> Or you can use nsupdate on the system hosting your public BIND DNS server.

But the bind server doesn't know the new IP address?

> Please clarify where the Dynamic DNS client will be in comparison to the BIND 
> DNS server.  Then we can get into the minutia of how to go about things.

As I said. The bind server is at example.com. It is authoritative for 
example.com (and several other domains as well).

At home I have a connection to an ISP and that connection MAY change since it 
is in a DHCP pool. I want to be able to updated my DNS server so that 
"home.example.com" points to my home IP address.

I have done this in the past with various dynamic DNS services (like DynDNS) 
where their software client would automatically update a custom subdomain of 
one of their domains like homeftp.net (the have many and which one isn't 
relevant) and then on the Bind server I would have, for example, in example.com,

homeCNAME lbutlr.homeftp.net. #example name, not real dynDNS address)

When the client updated my IP address, bind would simply relay connections to 
home.exmple.com to lbutlr.homeftp.net regardless of what the IP address was.

What I want to do is eliminate the 3rd party service and client so that the 
bind server can simply have:

homeA   12.34.56.789 # obvs not a real IP

-- 
I went to a restaurant that serves "breakfast at any time". So I
ordered French Toast during the Renaissance.

___
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

Quick dynamic DNS?

[@lbutlr]

Give that I have a authoritative bind9 server for example.com and given that I 
have a home connection that is (technically) dynamic home.example.com what is 
the easiest way for me to automatically update the DNS on the rare occasions 
that it changes?

The example.com domain is setup with DNSSEC and the home connection has a rPI 
already acting as an unbound/piHole server, if that helps.

I used to use a dynamic DNS service, but I figure I have the tools available to 
do this all myself. What am I doing right now is just manually changing the IP.

-- 
"There will always be women in rubber flirting with me."

___
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: Forwarded lookup failing on no valid RRSIG

[@lbutlr]

On 18 Dec 2020, at 10:56, Nicolas Bock  wrote:
> ;; ANSWER SECTION:
> com. 63779 IN DS 30909 8 2 
> E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766

> In other words, the forwarder returns a Delegation Signer
> record but not an RRset Signature record. Presumably that
> means that that the forwarder is not validating the zone?

This is what I get when checking against my bind server.

;; ANSWER SECTION:
com.43195   IN  DS  30909 8 2 
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.43195   IN  RRSIG   DS 8 1 86400 2020123005 
2020121704 26116 . y2okmC5beWCbF84ZmlSM1ALT6Rd3xw9t41MEv6d8ITX8F8PV2Y/RDHvo 
81ZlZK5sNsJFGXsTGyI+u5MrpSzlrD+6QXrE/h5Bt+YIvPI18DK4r5vk 
4676uoPTnU+Lg/3CJOV73BkLhmZ4B50jV5vwnDXHobX8stKtuUyIA5hE 
Uvh1a5znj3mQRrmCXjuQ+Sb5DOORAymJdLlo3RzXs2LurDnnxml4DlnT 
b1BG/tXjOsK/H/QLH7jkPg/9OBQqB7eROkZO+qMQFkkMxmMXFvnR9Mxx 
mDcftsZ7d+/JiYflQh+PHEh3ncnOlLD2+O/FV5Qe9vugmGVybTuf7INt /TiF7g==

-- 
Steak and suspicious-organ pie

___
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: Abour RRL and Best Practise

[@lbutlr]

On 27 Nov 2020, at 00:00, Onur GURSOY  wrote:
> Hello Everyone,

Oh, come on!

-- 
"Are you pondering what I'm pondering?"
"Wuh, I think so, Brain, but if we didn't have ears, we'd look like
weasels."
___
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: Malformed transaction errors

[@lbutlr]

On 19 Oct 2020, at 08:57, Bob McDonald  wrote:
> When you talk about "putting the .jnl file aside" what are you doing? 
> Stopping named THEN deleting the .jnl file?

I did not delete the file. I stopped named and moved the file, then restarted 
named. After everything seemed to be working, then I removed the file.

> Using rndc sync -clean  ? In the case of the rndc command, you 
> don't need to cycle named.

That's good to know, will try the next time if goes pear-shaped.

> What user is named running as? Are the directory permissions for the 
> directory housing the .jnl file correct?

There are many domains, all with same permissions (bind/bind).

-- 
And what rough beast, its hour come round at last,
Slouches towards Bethlehem to be born?

___
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: Malformed transaction errors

[@lbutlr]

On 19 Oct 2020, at 00:54, Matus UHLAR - fantomas  wrote:
> On 18.10.20 11:00, @lbutlr wrote:
>> I am getting the following error on one specific domain and I am unsure how 
>> to fi it. Searching for the error lead to suggestions about not running 
>> multiple copies of bind on the same machine, but that is not the case here 
>> (and it is only affecting one domain).
>> 
>> named[652] malformed transaction: example.com.signed.jnl last serial 
>> 2018022385 != transaction first serial 2018022384
>> named[652] zone example.com/IN: zone_resigninc:dns_journal_write_transaction 
>> -> unexpected error
>> named[652] malformed transaction: example.com.signed.jnl last serial 
>> 2018022385 != transaction first serial 2018022384
>> named[652] zone example.com/IN: zone_resigninc:dns_journal_write_transaction 
>> -> unexpected error
>> 
>> If I put aside the jnl file and stop/start bind the error goes away, but 
>> eventually it comes back, always for the same domain.
>> 
>> (Setup is DNS primary on on machine and a secondary server on a separate 
>> machine. Errors are on the primary server.)
> 
> what's the primary server? maybe broken DNS implementation

Bind $CURRENT ((9.16.7)), though this has been happening sporadically for 
months.

Stopping and starting bind after removing the jnl files seems to fix it for 
quite awhile

Other than the logged error there seems to be no other side-effect of this, the 
domain continues to resolve. I suspect it might have something to do with the 
DNSEC self-updating, but that is only a guess based on the fact it takes a long 
time to recur.

-- 
Mirrors contain infinity. Infinity contains more things than you
think. Everything, for a start. Including hunger. Because there's
a million billion images, but only one soul to go around.
--Witches Abroad

___
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: forwarders used in order or based on RTT ?

[@lbutlr]

On 16 Oct 2020, at 08:36, Bob Harold  wrote:
> That is certainly not obvious.  How do I request improving the manual?
> 
> "in turn" would seem to imply "in order", and the order would logically be 
> the order I listed them.]

I disagree. In turn means one is tried, then if that fails the next is tried. 
There is no implication at all that the order they are tried in is the order 
specified.

It would not hurt anything to say they were tried in turn accords to RTT, but 
as it stands the documentation doesn’t say what you think it says.

Again, "in turn" doesn’t mean "in the order I expect" it simply means one after 
another until all are checked (or one succeeds).


-- 
"Are you pondering what I'm pondering?"
"Wuh, I think so, Brain, but I prefer Space Jelly."

___
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

Malformed transaction errors

[@lbutlr]

I am getting the following error on one specific domain and I am unsure how to 
fi it. Searching for the error lead to suggestions about not running multiple 
copies of bind on the same machine, but that is not the case here (and it is 
only affecting one domain).

named[652] malformed transaction: example.com.signed.jnl last serial 2018022385 
!= transaction first serial 2018022384
named[652] zone example.com/IN: zone_resigninc:dns_journal_write_transaction -> 
unexpected error
named[652] malformed transaction: example.com.signed.jnl last serial 2018022385 
!= transaction first serial 2018022384
named[652] zone example.com/IN: zone_resigninc:dns_journal_write_transaction -> 
unexpected error

If I put aside the jnl file and stop/start bind the error goes away, but 
eventually it comes back, always for the same domain.

(Setup is DNS primary on on machine and a secondary server on a separate 
machine. Errors are on the primary server.)

-- 
Thunder rolled... It rolled a six.

___
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: Sudden DNS issues

[@lbutlr]

On 23 Sep 2020, at 19:19, @lbutlr  wrote:
> named[652] malformed transaction: managed-keys.bind.jnl last serial 1204 != 
> transaction first serial 1159
> named[652] managed-keys-zone: keyfetch_done:dns_journal_write_transaction -> 
> unexpected error
> named[652] managed-keys-zone: error during managed-keys processing 
> (unexpected error): DNSSEC validation may be at risk

I tried various things to no avail, and finally rebooted the server last night. 
That seems to have cleared up whatever the issue was.



-- 
'Tell me, Sir Samuel, do you know the phrase "Quis custodiet ipsos
custodes?"? (...) It means "Who guards the guards themselves?"
(...) Who watches the Watch?' --Feet of Clay

___
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

Sudden DNS issues

[@lbutlr]

Getting these in the logs:

named[652] malformed transaction: managed-keys.bind.jnl last serial 1204 != 
transaction first serial 1159
named[652] managed-keys-zone: keyfetch_done:dns_journal_write_transaction -> 
unexpected error
named[652] managed-keys-zone: error during managed-keys processing (unexpected 
error): DNSSEC validation may be at risk

===>>> bind-tools-9.16.6
===>>> bind916-9.16.6_1

(This is the newest version available to me in FreeBSD ports)



-- 
HILLBILLIES ARE PEOPLE TOO Bart chalkboard Ep. AABF11

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

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


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

Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?

[@lbutlr]

On 21 Jul 2020, at 06:37, Mark Andrews  wrote:
> On 21 Jul 2020, at 18:23, @lbutlr  wrote:
>> 
>> Bind is a poor choice for desktop use. Packages like unbound are much better 
>> for that sort of use, and it is fr less critical if those packages have 
>> security issues.
> 
> Anything that talks to the net is critical path from a security perspective.

There are different levels of critical, and unbound is a lot further down that 
list that bind.



-- 
We are born naked, wet and hungry; then it's all downhill.

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

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


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

Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?

[@lbutlr]

On 20 Jul 2020, at 10:09, tale  wrote:
> And for what it's worth, not all systems moved away from "named" to
> "bind9".  I've been running FreeBSD for decades, and I can't remember
> ever calling the service "bind9".

The service is always named, the package is bind. I stopped adding the 9 many 
years ago unless I need to specify a specific version like "bind nine dot 
eleven".

On 20 Jul 2020, at 11:45, Ted Mittelstaedt  wrote:
> When FreeBSD was used mostly for servers it wasn't a problem. But more
> and more people are using it for desktop use where they want to basically 
> install it and forget about it, never run patches, never give
> a fig about security.

Bind is a poor choice for desktop use. Packages like unbound are much better 
for that sort of use, and it is fr less critical if those packages have 
security issues.

I agree that anyone using a FreeBSD install as a server should be using bind, 
but I also agree it should not be the default install. You install bind when 
you figure out you need it, and not before.



-- 
Mickey and Mallory know the difference between right and wrong; the
just don't give a damn.

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

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


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

Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?

[@lbutlr]

On 17 Jul 2020, at 11:56, Ted Mittelstaedt  wrote:
> In fact, the ONLY reason that the name "bind9" was ever even coined
> at all was because the changes from bind8 both in the syntax of the
> config file and how the program operated they wanted to boot admins
> in the behind to get them to change their config files.  It should
> have been put to bed as a name a long time ago, or named "bind
> version 9" like every other software program does with their versions.

This. Exactly this.



-- 
"Yessir, Captain Tight Pants."

___
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: scripts-to-block-domains

[@lbutlr]

On 14 Jul 2020, at 00:31, MEjaz  wrote:
> 

Please do not post images. Copy and paste the text.

(Over 100 lines of quoted lines with no content deleted)



-- 
I WILL NOT BARF UNLESS I'M SICK Bart chalkboard Ep. 8F15

___
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: your mail

[@lbutlr]

On 28 Jun 2020, at 09:13, Matus UHLAR - fantomas  wrote:
>> zone "abc.com" {
>>   type forward;
>>   forwarders {1.1.1.1;};
> 
> of 1.1.1.1 is IP of nameserver for abc.com, you should better configure it
> as "type stub" or "type static-stub".

1.1.1.1 is a DNS resolver for Cloudflare and resolves to one.one.one.one.

(I know the sis old, but since it is a DNS server that I use, I found it odd os 
see acclaim that it was abc.com which is 143.204.25.15, 143.204.25.61, 
143.204.25.54, and 143.204.25.50.



-- 
"Are you pondering what I'm pondering?"
"I think so, Brain. But Trojans won’t arrive on the scene for another
300 years."

___
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: issue of Amplification attack

[@lbutlr]

On 12 Jul 2020, at 06:28, Matus UHLAR - fantomas  wrote:
>> On 7/12/20 6:23 AM, ShubhamGoyal wrote:
>>> I am thinking to stop or drop ANY type queries from our DNS Recursive 
>>> resolver , so please tell me how can we drop or stop ANY type queries from 
>>> bind.

Don't do this.

> On 12.07.20 12:48, Michael De Roover wrote:
>> There was a very interesting conversation about this last week. See 
>> https://www.mail-archive.com/bind-users@lists.isc.org/msg29187.html.
> 
> alternative link:
> https://lists.isc.org/pipermail/bind-users/2020-July/103389.html

Specifically read this message before you decide you want to disable responses 
to ANY.





-- 
"I can't see the point in the theatre. All that sex and violence. I
get enough of that at home. Apart from the sex, of course." -
Baldrick

___
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

Dumb Question is an A or AAAA record required?

[@lbutlr]

Given a domain that is hosted and used for email and web, is an A record for 
that domain actually required?

That is, if bob.tld is hosted by example.com can you simply have

NS ns1.example.com
NS ns2.example.com
MX mx.example.com

www CNAME www.example.com

Without specifying 

A 11.22.33.444

(I am pretty sure this is *technically* allowed, but is it really OK to do or 
are there reasons not to do this?)



-- 
And there were all the stars, looking remarkably like powered
diamonds spilled on black velvet, the stars that lured and
ultimately called the boldest towards them…

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

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


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

Re: Bind 9.16.x won't start from systemd

[@lbutlr]

On 08 Jul 2020, at 05:03, Adrian van Bloois  wrote:
> When I try to start bind 9.16.x from systemd it fails not being able to
> find something.

… 

> What could be the problem???

Not really possible to guess without the error message.


-- 
"Are you pondering what I'm pondering?"
"I think so, Brain, but would Danish flies work just as well?"

___
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: DNS security, amplification attacks and recursion

[@lbutlr]

On 07 Jul 2020, at 12:06, Michael De Roover  wrote:
> On 7/7/20 4:06 PM, Tony Finch wrote:
> 
>>  max-udp-size 1420;
>>  https://dnsflagday.net/2020/

> Interesting, I wasn't aware of this campaign. I don't know if I'm 
> knowledgeable enough on UDP to be able to make educated decisions on this 
> myself but I look forward to its eventual release.

The URL has a good explanation of this setting and it looks like 1420 is a more 
than adequate packet size. 

>From  the page:
An EDNS buffer size of 1232 bytes will avoid fragmentation on nearly all 
current networks. This is based on an MTU of 1280, which is required by the 
IPv6 specification, minus 48 bytes for the IPv6 and UDP headers.

Sunce 1420 is still well under the MTU on most connections (usually 1500, 
sometimes 1492) and well above the required, I suspect this is fine as well. 
I've gone ahead and added to to my named.conf with a comment linking to Tony's 
message.




-- 
"Are you pondering what I'm pondering?"
"I think so, Mr. Brain, but if the sun'll come out tomorrow, what's
it doing right 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: DNS security, amplification attacks and recursion

[@lbutlr]

On 07 Jul 2020, at 08:06, Tony Finch  wrote:

Excellent post, and a nice summary of some best practices.

I have a couple of questions.

> Response rate limiting is very effective. Start off by putting the
> following in your options{} section, and look in the BIND ARM for other
> directives you can put in the rate-limit{} section.
> 
>   rate-limit { responses-per-second 10; };

Does that apply to local queries as well (for example, a mail server may easily 
make a whole lot of queries to 127.0.0.1, and rate limiting it would at the 
very least affect logging and could delay mail if the MTA cannot verify DNS.

Do these setting also need to be applied to the secondary servers?



-- 
What's another word for Thesaurus?

___
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: Fun with nsudpate and ac1.nstld.com

[@lbutlr]

On 06 Jul 2020, at 17:59, Mark Andrews  wrote:
> Nsupdate can normally determine the name of the zone that has to be updated 
> so most of the time you don’t need to specify the zone.  There are a few 
> cases, like when adding delegating NS records or glue to the parent zone you 
> have to override the normal zone discovery procedure.

So if I were to try adding web2.example.com via nsupdate I could simply 

> update add web2.example.com 96400 IN CNAME www.covisp.net
> send

That's good to know, but I fear I will remember that and use it in cases where 
I do need to specify it and muck things up.

I change DNS settings so infrequently that each time it is almost like starting 
over, especially since the underlying software has changed as well. Also, I 
need better notes, which I am taking this time. (Most of the serials on the DNS 
files are more than two years old)

The latest surprise was that dnssec-enable yes; is obsolete in Bind 9.16. I've 
noticed no fallout from simply uncommenting it, so I assume it is either 
required now or implied with dnssec-validation set or auto-dnssec in the zone 
config.

I do have motivation to get all this nsupdate stuff square, however, as I want 
to move Letsencrypt to wildcard certs and that requires updating the DNS during 
the LE exchange.



-- 
Vi Veri Veniversum Vivus Vici

___
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: issue in bind installation

[@lbutlr]

On 06 Jul 2020, at 22:00, ShubhamGoyal  wrote:
> I am installing bind  latest version with additional feature , it gave me 
> "configure: error librpz.so and dlopen needed for dnsrps"   error.
> I am searching for that error but i did not find the solution. 

You have configured bind for dnsrps and you do not have the necessary 
requirements installed would be my guess.

Re you using a package manager to compile or building manually.

-- 
"Are you pondering what I'm pondering?"
"Well, I think so -POIT- but where do you stick the feather and call
it macaroni?"
___
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: Fun with nsudpate and ac1.nstld.com

[@lbutlr]

On 06 Jul 2020, at 16:47, Kevin Darcy  wrote:
> You didn't dot-terminate covisp.net in the "zone" statement



Ow!



Sigh.



-- 
The whole thing that makes a mathematician's life worthwhile is that
he gets the grudging admiration of three or four colleagues

___
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

Fun with nsudpate and ac1.nstld.com

[@lbutlr]

Trying to verify that I can make changes with nsupdatem and running into 
something I don’t understand.
 
 mail # nsupdate -k admin.key 
> zone name covisp.net
> update delete ns1.covisp.net. INA   65.121.55.42
> update add ns1.covisp.net. 3601 INA   65.121.55.42
> send
; Communication with 192.42.173.30#53 failed: timed out

Uh… what? Why is it trying to update 192.42.173.30 (ac1.nstld.com)?

That IP does not appear in any file in /usr/local/etc/ nor in /etc/ on my 
system.

What am I missing here?

In fact, the only file on the entire /usr/ that has this IP address in it is 
the draft copy of this email.


___
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

Syntex for primary/secondary

[@lbutlr]

When seeing up a secondary zone what do I replace # with in following (the 
old syntax was masters instead od master, so I am guessing it needs a new 
keyword)?

zone "example.com" {
  type secondary;
  # { 192.168.10.1; };
  file "/var/lib/bind/db.example.com";
};

in https://bind9.readthedocs.io/en/v9_16_4/reference.html it appears that the 
syntax is till masters?

4.2.11. masters Statement Grammar

masters  [ port  ] [ dscp
 ] { (  |  [
port  ] |  [ port
 ] ) [ key  ]; ... }; 




-- 
Man is born free, but is everywhere in chains.

___
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: unknown option 'trust-anchors'

[@lbutlr]

On 05 Jul 2020, at 07:51, @lbutlr via bind-users  
wrote:
> mail # rndc reload
> rndc: 'reload' failed: failure
> mail # tail /var/log/messages
> Jul  5 07:41:24 mail.covisp.net named[53940] 
> /usr/local/etc/namedb/bind.keys:29: unknown option 'trust-anchors'
> Jul  5 07:41:24 mail.covisp.net named[53940] reloading configuration failed: 
> failur

When checking on things I see that despite INSTALLING bind 9.16 I neglected to 
restart bind at the time, so the running version is still 9.14.11. Could this 
be the cause of this issue? I am loathe to stop and restart named in case this 
is NOT the issue and I then end up with a non-functioning primary DNS. 



-- 
'The only reason we're still alive now is that we're more fun alive
than dead,' said Granny's voice behind her. --Lords and Ladies

___
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: $INCLUDE Kexamle.com.+007...

[@lbutlr]

On 05 Jul 2020, at 10:12, Tony Finch  wrote:
> @lbutlr  wrote:
> 
>> When a domain configuration file contains an include line for the key,
>> where is that include looking for the key file?
> 
> ... good question, I have avoided having to find that out ...

Heh.

> So it sounds like "the current directory" is the answer to your question.

That would certainly explain why it fails then.

> However, I don't think you need to $INCLUDE key files. I think maybe that
> used to be a thing when signing a zone had to involve dnssec-signzone? But
> nowadays even dnssec-signzone will automatically insert public keys into
> the signed zone.

Ah, that would be good. When I resolve the other issue I posted about I will 
check that.

My configuration started in … um… 1995? I'm sure I should start all over with 
the 9.16 manual from scratch, but you know, I have all this TV to watch. 

> Does that make sense?

It does, and thank you.



-- 
It's against my programming to impersonate a deity.

___
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

unknown option 'trust-anchors'

[@lbutlr via bind-users]

In named.conf I have 
dnssec-enable yes;
dnssec-validation auto;

# rndc managed-keys status
view: _default
next scheduled event: Sun, 05 Jul 2020 20:43:00 GMT

name: .
keyid: 20326
algorithm: RSASHA256
flags: SEP
next refresh: Sun, 05 Jul 2020 20:43:00 GMT
trusted since: Mon, 21 Jan 2019 14:53:55 GMT
 mail # rndc reload
rndc: 'reload' failed: failure
 mail # tail /var/log/messages
Jul  5 07:41:24 mail.covisp.net named[53940] 
/usr/local/etc/namedb/bind.keys:29: unknown option 'trust-anchors'
Jul  5 07:41:24 mail.covisp.net named[53940] reloading configuration failed: 
failure

Bind is currently running just fine and has been since 8 June.

The bind.keys file has:

# See https://data.iana.org/root-anchors/root-anchors.xml for current trust
# anchor information for the root zone.

But that URL does not load and gives an XML error.



-- 
-=> 

 <=-

___
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

$INCLUDE Kexamle.com.+007...

[@lbutlr]

When a domain configuration file contains an include line for the key, where is 
that include looking for the key file?

I'm in a situation where the keys seems to work fine for updating DNSSEC, but 
nsdiff complains the key file is not found.

Obviously something in named.conf or the domain file is off as far as nstiff is 
concerned, and I’d like to fix it, but it’s hard to debug when the actual key 
update is working.

In Named.conf I have
key-directory   "/usr/local/etc/namedb/working/keys”;

And that is where the keyholes are stored.

But nsdiff returns an error the key file cannot be found.

Or I am using nstiff improperly?


nsdiff -k admin.key covisp.net  working/master/covisp.net
nsdiff: loading zone covisp.net. via AXFR from ns1.covisp.net.
zone covisp.net/IN: loaded serial 2019022695 (DNSSEC signed)
OK
nsdiff: loading zone covisp.net. from file working/master/covisp.net
dns_master_load: working/master/covisp.net:48: Kcovisp.net.+007+34178.key: file 
not found
dns_master_load: working/master/covisp.net:49: Kcovisp.net.+007+46143.key: file 
not found
zone covisp.net/IN: loading from master file working/master/covisp.net failed: 
file not found
zone covisp.net/IN: not loaded due to errors.
nsdiff: missing SOA record

___
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: DNS Misconfiguration on- http://cyberia.net.sa/

[@lbutlr]

On 05 Jun 2020, at 04:10, Jukka Pakkanen  wrote:
> Thx for the info, had missed this one and actually we have that minor 
> misconfiguration too. Have had since 1995 when started our nameservers and 
> never noticed…

If it makes you feel better, it wasn't an error in 1995.

I remember removing the last of the localhost pointers in my dns setup less 
than 20 years ago. Perhaps a lot less? More than 8 years ago for sure.

I do not remember why it was recommended in the first place for sure, but I 
think it was to reduce load on the DNS, nor why it stopped being recommended, 
probably some attack vector?


-- 
Do not meddle in the affairs of Dragons for you are crunchy and taste
good with ketchup


___
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: DoH plugin for BIND

[@lbutlr]

On 29 Apr 2020, at 14:19, Tony Finch  wrote:
> DoT is easier since you only need a raw TLS reverse proxy, and there are
> lots of those, for example, nginx:

DOH is better because it cannot be blocked without blocking all https traffic.

(FSVO of better, of course. I am sure there is a vi/emacs space/tab trek/wars 
religious canonical war here, but being able to guarantee access to secure DNS 
is definitely better for users).

All that its need to subvert DoT is to block port 853.

If DoT takes off, I expect all US ISPs to block port 853 universally. There’s 
nothing they can do about DoH.

Not that it is all sunshine and rainbows in DoH-land, of course. Use of cookies 
is “discouraged” but not prevented, most obviously.




-- 
'You're your own worst enemy, Rincewind,' said the sword. Rincewind
looked up at the grinning men. 'Bet?' --Colour of Magic


___
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

Nsupdate and TTL

[@lbutlr via bind-users]

What is the proper syntax gor changing the TTL on a zone with nsupdate?

Does the existence of $TTL 86400 in the domain.conf file override nssupdate’s 
attempts to change the TTL?

# nsupdate -k /path/to/key
> zone example.com
> ttl 3600
> send
> ^d

No errors, but no change in the TTL.



-- 
"I know she's in there," said Verence, holding his crown in his hands
in the famous Ai-Se-or-Mexican-Bandits-Have-Raided-Our-Village
position


___
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: Batch updating all DNS records on my Bind server

[@lbutlr]

On 18 Apr 2020, at 09:34, Reindl Harald  wrote:
> Am 18.04.20 um 17:23 schrieb @lbutlr:
>> Is it possible to batch update all the domains? Looking at nsupdate it looks 
>> like I have to step through and do every domain individually.

> well, where is the issue iterate all your domains in a bash script as
> you don't seem to have some sql backed admin interface?

“nsupdate does not support batch updates” would have been shorter.



-- 
showing snuffy is when Sesame Street jumped the shark


___
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

Batch updating all DNS records on my Bind server

[@lbutlr]

We are making some changes to our NSP account and the NSP is threatening to 
change our IP block. This means I will have to update all the domains on the 
system (all using DNSSEC). We are still arguing with them since there is no 
technical reason for forcing this change on us, but chances are they will prove 
to be inflexible.

Is it possible to batch update all the domains? Looking at nsupdate it looks 
like I have to step through and do every domain individually.

The only occurrence of ‘batch’ on the nsupdate man page is:

 -vUse TCP even for small update requests. By default, nsupdate uses
   UDP to send update requests to the name server unless they are too
   large to fit in a UDP request in which case TCP will be used. TCP
   may be preferable when a batch of update requests is made.


-- 
'They say that whoever pays the piper calls the tune.' 'But,
gentlemen,' said Mr Saveloy, 'whoever holds a knife to the
piper's throat writes the symphony.' --Interesting Times


___
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.14 and bind-tools 9.16

[@lbutlr]

With my install of bind 9.14 bindtools 9.16.0 was also installed.

This version is missing some (legacy) algorithms that I am still using on my 
system, specifically hmac-sha256

dnssec-keygen [options] name

Version: 9.16.0
name: owner of the key
Options:
-a :
RSASHA1 | NSEC3RSASHA1 |
RSASHA256 | RSASHA512 |
ECDSAP256SHA256 | ECDSAP384SHA384 |
ED25519 | ED448 | DH
 
This is the only version of bind-tools in FreeBSD 12.1 AFAICT.

I need to generate hmac-sha256 for lets encrypt/dehydrated (at least that is 
what the documentation says).

dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST -K  _acme-challenge.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: Advice on balancing web traffic using geoip ACls

[@lbutlr via bind-users]

On 23 Feb 2020, at 07:57, @lbutlr  wrote:
> (9.11.6 should be coming really soon)

9.11.16, and I appear to be behind a touch, it is already released.

___
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: Advice on balancing web traffic using geoip ACls

[@lbutlr]

On 22 Feb 2020, at 18:25, Scott A. Wozny  wrote:
> I’m setting up hot-hot webserver clusters hosted on the west and east coasts 
> of the US and would like to use Bind 9.11.4

I’d consider changing that version. While Bind 9.11 *is* still supported, it is 
EOL at the end of this year. If you really really want to run 9.11, at least 
run the latest patch level (9.11.6 should be coming really soon).

9.14.10 is the current stable release and 9.11.15 is the current extended 
support release. Unless you know something is broken in 9.14.10 (unlikely) that 
would be the version to look at.


You absolutely should not be running a bind version several years old, as 
9.11.4 is.




___
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 and HTTPS?

[@lbutlr]

On 11 Jul 2019, at 10:52, Lefteris Tsintjelis via bind-users 
 wrote:
> On 11/7/2019 15:35, Tony Finch wrote:
>> Lefteris Tsintjelis via bind-users  wrote:
>>> 
>>> Why would you want something like that?
>> https://datatracker.ietf.org/wg/dprive/about/
> 
> If you are willing to sacrifice speed.

Not really. Using DOH servers now doesn’t have any noticeable impact on speed 
of DNS.



-- 
"...and that's not incense”

___
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 and HTTPS?

[@lbutlr]

Is it possible to setup bind to use DOH (FNS over HTTPS) rather than 
unencrypted DNS lookups? Our in addition to?



-- 
'An appointment is an engagement to see someone, while a morningstar is
a large lump of metal used for viciously crushing skulls. It is
important not to confuse the two.’

___
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: A policy for removing named.conf options.

[@lbutlr]

On 13 Jun2019, at 17:48, Browne, Stuart via bind-users 
 wrote:
> For options that have passed their warning phase and have been removed, I'm 
> all for BIND failing to start and named-checkconf erroring out , rather than 
> quietly ignoring them.

Yes, I think this is the best way, otherwise there will be useless kruft 
getting in the way forever.


-- 
The only way of discovering the limits of the possible is to venture a
little way past them into the impossible.


___
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: Should we remove the DLV code?

[@lbutlr]

On 22 May 2019, at 23:31, Evan Hunt  wrote:
> One possible reason is distribution of trust anchors for a private corporate 
> domain. 

Aren't there better days to do this?

Or at least other ways to do this?

Anything to make bind leaner and meaner and with fewer LOCs seems like a plus 
to me.

-- 
-=>



<=-


___
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: nsupdate reject

[@lbutlr]

On 20 May 2019, at 20:45, @lbutlr  wrote:
> 
> On 20 May 2019, at 16:21, Noel Butler  wrote:
>>   allow-update { key "keyname"; };
> 
> Ah, no I did not. The instructions I found, as I mentioned in a later post, 
> were to add grant dons-key. iOS this a change in 9.14, because I did not have 
> to do this in 9.12?

zone "kreme.com" { 
type master; 
file "master/kreme.com.signed"; 
update-policy local;
auto-dnssec maintain;
allow-update { 
key "rndc-key";
};
 };

gives "'allow-update' is ignored when 'update-policy' is present" when I load 
the conf file.

If I remove "update-policy local; " the nsupdate works, but it seems like it 
should have worked with the update-policy since I was in fact local to the bind 
server.

-- 
My little brother got his arm stuck in the microwave. So my mom had to
take him to the hospital. My grandma dropped acid this morning, and she
freaked out. She hijacked a busload of penguins. So it's sort of a
family crisis. Bye!


___
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: nsupdate reject

[@lbutlr]

On 20 May 2019, at 16:21, Noel Butler  wrote:
>allow-update { key "keyname"; };

Ah, no I did not. The instructions I found, as I mentioned in a later post, 
were to add grant dons-key. iOS this a change in 9.14, because I did not have 
to do this in 9.12?

> and nsLOOKUP ?

Just a thinko.

-- 
The hippo of recollection stirred in the muddy waters of the mind.



___
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: nsupdate reject

[@lbutlr]

On 19 May 2019, at 18:27, @lbutlr  wrote:
> This is the same key block that is in named.conf. I am launching NSLOOKUP 
> with -k admin.key, but when I try to make a change and then "send", I get 
> "update failed: REFUSED."

I found a page that recommended adding a ddns-key and then adding "grant 
ddns-key zonesub ANY;" to the zone info, but that produces and error "unknown 
option 'grant'".

-- 
'You know what the greatest tragedy is in the whole world?' said Ginger,
not paying him the least attention. 'It's all the people who never find
out what it is they really want to do or what it is they're really good
at. It's all the sons who become blacksmiths because their fathers were
blacksmiths. It's all the people who could be really fantastic flute
players who grow old and die without ever seeing a musical instrument,
so they become bad ploughmen instead. It's all the people with talents
who never even find out. Maybe they are never born in a time when it is
possible to find out.'



___
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

nsupdate reject

[@lbutlr]

Trying to update some DNS under a relatively newly installed bin 9.14 with 
nsupdate.

I have a file admin.key that looks basically like this:
key "rndc-key" {
   algorithm hmac-sha256;
   secret "SECRETSTUFF=";
 };

This is the same key block that is in named.conf. I am launching NSLOOKUP with 
-k admin.key, but when I try to make a change and then "send", I get "update 
failed: REFUSED."

Is this not the key that is wanted? It appears to be the only key I have. Do I 
need to change to some different key type for bind 9.14, or am I forgetting 
something else.

I did make some changes to the DNS back in 9/12 several months ago, and I don't 
recall having to even provide the key then.

-- 
There's a race of men that don't fit in, A race that can't stay still So
they break the hearts of kith and kin, And they roam the world at will.


___
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

Updating to 9.14

[@lbutlr]

Currently running latest release of Bind 9.12, which is now EOLed and want to 
move to 9.14. I was looking on google for 

update "bind9.12" "bind 9.14"

But did not find anything of use. I did find the 9.14 announcement, but there 
isn't a link there to release notes. I know there has been at least one 
significant change in the named.conf file.



Other than the “allow-update” and “allow-update-forwarding” issue which does 
not affect me, what other configuration issues am I going to hit?

I am still OpenSSL 1.0.2r, do I need to move to OpenSSL 1.1.1? I mean, I am 
probably going to do that anyway, RSN, but this would be an excuse to do it now.

-- 
Forgive your enemies, but remember their names.




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

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

Re: Bind > 9.12 Will Not Start On FreeBSD

[@lbutlr]

On 27 Apr 2019, at 16:21, Tim Daneliuk  wrote:
> Why is 9.12+ now suddenly so grumpy about who owns the files?  Is this a 
> recent fix to reduce the attack surface on files owned by root?

Pretty sure. I thought it was mentioned in the 9.12 release notes, but now I 
can't find it.


-- 
One of the most basic rules of survival on any planet is never to upset
someone wearing black leather. --The Last Continent


___
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: max file size or line count for BIND zone file

[@lbutlr]

On 25 Apr 2019, at 06:10, Martin Meadows via bind-users 
 wrote:
> 
>  ns ms,sans-serif">Wondering if anyone is aware of a max file size or max nu=
> mber of lines that a given BIND zone file can contain?=C2=A0 s=3D"gmail_default" style=3D"font-family:comic sans ms,sans-serif"> v> f">Thanks, s ms,sans-serif">Marty ly:comic sans ms,sans-serif">--  r" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"> "ltr"> =3D"font-size:12.801907349px">Martin MeadowsMTA and=
>  DNS Administrator | Salesforce 01907349px"><=
> /div>

WHY?


-- 
Aren't you a little short for a stormtrooper?


___
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: allow-update in global options (was Re: bind and certbot with dns-challenge)

[@lbutlr]

On 17 Mar 2019, at 15:52, Grant Taylor via bind-users 
 wrote:
> If the consensus is that the new behavior is desired, I would hope ~> expect 
> for a survey of the BIND user community like I've seen in the past about 
> removing / significantly altering functionality.

I disagree. I'd prefer the best decision be made by consensus of the 
contributors rather than the community at large. The community includes a lot 
of people with a barely functioning understanding of DNS and no basis in 
knowledge for making a qualified decision as to if this is a good thing or not.

I know this, because this describes me (and everyone I've met in person who has 
to deal with DNS) pretty accurately.



-- 
"I program Windows - of course it isn't safe." - Meski


___
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: Freeze/thaw and signed zone files

[@lbutlr]

On 23 Feb 2019, at 14:45, Mark Andrews  wrote:
> On IPv6 why wouldn’t you support it?

Our ISP does not support it. We get 5 static IPv4 addresses and no IPv6 at all.

-- 
Critics look at actresses one of two ways: you're either bankable or
boinkable.

___
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: Freeze/thaw and signed zone files

[@lbutlr]

On 22 Feb 2019, at 12:28, @lbutlr  wrote:
> ; Communication with ::1#53 failed: timed out

I am still getting this error whenever I try to make a change in the zone with 
nsupdate -l, should I not worry about it?

I mean, the records appear to be updating… 路‍♀️

-- 
First we must assume a spherical cow.

___
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: Freeze/thaw and signed zone files

[@lbutlr]

On 22 Feb 2019, at 12:12, Tony Finch  wrote:
> Get it from the link above, if you want :-)

Doh!

OK, got it, installed it, changed the path to perl, and that’s pretty slick.

-- 
"I don't think the kind of friends I'd have would care.”

___
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: Freeze/thaw and signed zone files

[@lbutlr]

I did try manually updating vi nsupdate -l

> zone example.com
> update add example.com. 86400 IN SOA  ns1.example.net. admin.example.com. 
> 2019022200 3600 300 1209600 3600
> update add konamicode.example.com. 86400 IN CNAME   www.example.com.
> send
; Communication with ::1#53 failed: timed out
update failed: FORMERR

Why is it defaulting to IPv6? This system is not setup for IPv6. Do I have to 
setup named.conf to listen on ::1?

Also, confusingly, despite the error the zone WAS updated.

-- 
There used to be such simple directions, back in the days before they
invented parallel universes - Up and Down, Right and Left, Backward and
Forward, Past and Future... But normal directions don't work in the
multiverse, which has far too many dimensions for anyone to find their
way. So new ones have to be invented so that the way can be found. Like:
East of the Sun, West of the Moon Or: Behind the North Wind. Or: At the
Back of Beyond. Or: There and Back Again. Or: Beyond the Fields We
Know. --Lords and Ladies




___
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: Freeze/thaw and signed zone files

[@lbutlr via bind-users]

On 22 Feb 2019, at 09:54, Tony Finch  wrote:
> You might want a config like
> 
>   zone "example.com" {
>   type master;
>   file "master/example.com”;

Not example.com.signed?

>   update-policy local;
>   auto-dnssec maintain;
>   inline-signing yes;
>   };
> 
> Alternatively, with your current config you can update the zone using
> https://dotat.at/prog/nsdiff/ like this:
> 
>   nsdiff example.com master/example.com | nsupdate -l

Where the second one of those is my example.com.signed file?

Is nsdiff a separate package? It’s not on my FereeBSD 11.2 system with Bind 9.12

-- 
Well boys, we got three engines out, we got more holes in us than a
horse trader's mule, the radio is gone and we're leaking fuel and if we
was flying any lower why we'd need sleigh bells on this thing... but we
got one little budge on those Roosskies. At this height why they might
harpoon us but they dang sure ain't gonna spot us on no radar screen!

___
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: Freeze/thaw and signed zone files

[@lbutlr via bind-users]

On 21 Feb 2019, at 20:43, Grant Taylor via bind-users 
 wrote:
> 
> On 2/21/19 6:28 PM, @lbutlr wrote:
>> rndc reload did not recreate (or at least update the time stamp) on the 
>> .signed file.
> 
> Hum.  Maybe it's something different about how you're doing DNSSEC than I am.
> 
> I have BIND managing DNSSEC for me via "auto-dnssec maintain;".  So I don't 
> get .signed files.

the .signed files were created when I first signed the zones with 
dnssec-signzone which is what gave me the dsset file containing the information 
I needed to add DNSSEC to my domain's registrar.

dnssec-signzone -3 $(head -c 1000 /dev/random | shasum | cut -b 1-16) -A -N 
INCREMENT -o ZONE -t ZONEFILE

I was assuming, perhaps wrongly, that these ,signed files continue to be 
required, as they were placed alongside the regular zone files.

> I was just able to do the following:
> 
> rndc freeze $ZONE
> rndc sync -clean $ZONE
> $EDITOR $ZONEFILE
> rndc thaw $ZONE
> rndc sign $ZONE
> 
> I did have to manually do the "rndc sign" for DNSViz to be happy with the new 
> test entry.  I don't know if that's expected or not.

Overnight, many of my zones have new zone.signed.jnl files

> Does your actual zone file have the DNSSEC records in it?  That's where mine 
> are.  I don't have a separate unsigned zone file.

I have three files for each zone:

example.com (less than 2K, unsigned, no DNSSEC info, contains $INCLUDE lines at 
the end for the two public keys.

example.com.signed (12K, All the DNSSEC info)

example.com.signed.jnl (Created by bind, about double the size of .signed and a 
binary file) This file is updated when I issue the rind sign ZONE command.

> I believe so.  Do you have a "managed-keys-directory" entry in your 
> named.conf file?  (I do.  My .key and .private files are in the specified 
> directory.)

My private files are in that directory, I have the public ones in both the 
directory and the master/ directory Which is what seems to be needed (probably 
because of the include statement).

In named.conf I have


zone "example.com" { type master; file "master/example.com.signed"; 
update-policy local; auto-dnssec maintain; };


-- 
"Alas, earwax."

___
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: Freeze/thaw and signed zone files

[@lbutlr via bind-users]

On 21 Feb 2019, at 18:28, @lbutlr  wrote:
> Is the original random key that was generated at the time of signing kept 
> somewhere? NSEC3 seems to contain a 16 character hex sting that recurs 
> throughout the file.

OK, I moved aside the signed file, resigned the domain using the 16 character 
string I found repeated in the original .signed file and the dsset file 
contained the same strings, and the signed file was created anew and it 
contains the new subdomains. So, that immediate problem is solved.

First instance is on NSEC3PARAM parma line, so awk '/NSEC3PARAM 1/{ print $NF}’ 
zone.signed

-- 
people didn't seem to be able to remember what it was like with the
elves around. Life was certainly more interesting then, but usually
because it was shorter. And it was more colourful, if you liked the
colour of blood. --Lords and Ladies

___
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: Freeze/thaw and signed zone files

[@lbutlr]

>> OK, but rndc flush example.com results in:
>> rndc: 'flush' failed: not found
> 
> *FACEpalm*
> 
> I'm sorry.  I gave you the wrong command.  You want "sync", not "flush".  My 
> brain always thinks "flush the journal to disk" when it's really supposed to 
> be "sync the journal to disk".  You can pass the optional "-clean" command to 
> cause BIND to remove the synced journal file.
> 
> "flush" is flushing caches, and you can optionally specify a view.  I'm 
> guessing that you don't have a view named "example.com".
> 
>> Then service named stop, service named start.
> 
> When you use the proper commands, you don't need to restart the named 
> service.  You can also use rndc reload without needing to restart the named 
> service.

rndc reload did not recreate (or at least update the time stamp) on the .signed 
file.

But at no point do I get the new subdomains I added to the zone added to the 
zone.signed

I’ll try sync clean and see if I get further.

Nope, now the .signed file isn’t touched at all after the zone file is edited.

zone "example.com" { type master; file "master/example.com.signed"; 
update-policy local; auto-dnssec maintain; };

So I am still with a zone file that contains two subdomains that are not 
represented in the .signed zone file, so do not load and nothing that I do 
seems to be able to recreate the .signed file with the correct information.

Is the original random key that was generated at the time of signing kept 
somewhere? NSEC3 seems to contain a 16 character hex sting that recurs 
throughout the file.

-- 
all your snowflakes are urine and you can't even find the cat

___
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: Freeze/thaw and signed zone files

[@lbutlr via bind-users]

> On 21 Feb 2019, at 13:41, Grant Taylor via bind-users 
>  wrote:
> 
> On 02/21/2019 01:34 PM, @lbutlr via bind-users wrote:
>> I edited a zone file after issuing a rndc freeze command, added two new sub 
>> zones, changed the serial number, saved the file, and then did an rndc thaw.
> 
> I don't see an "rndc flush " in there.

OK, but rndc flush example.com results in:

rndc: 'flush' failed: not found

> rndc freeze $ZONE
> rndc flush $ZONE
> $EDITOR $ZONE
> rndc thaw $ZONE

Other than the flush, that is what I did.

> I don't recall if reloading or thawing will automatically re-sign the zone or 
> if you need to also explicitly "rndc sign $ZONE”.

Sign recreates the .jnl file, but doesn’t touch the .signed file.

Doing the following recreated the .signed file, but still didn’t add the new 
subdomains.

Freeze, flush, edit, thaw, 

Then service named stop, service named start.

Had a previous subdomain gallery and it is listed in both the zone file and the 
signed file 

Zone:
gallery CNAME   www

zone.signed:
gallery CNAME   www

Added a new sub zone, cam

Zone:
cam CNAME   www

zone.signed:


This matches up with the results from dig. So, now I do have a .signed file 
that has the serial number updated to match the zone file, but still doesn’t 
contain the new sub zones.

So, I did the whole dance again. Freeze, flush, edit (change serial, add 
another subdomain, thaw, stop/start). Nothing. But the time stamp on the 
.signed file changes. 

And I misspoke earlier, the serial number in the signed file’s SOA didn’t 
change, but the serial numbers/dates in the RRSIG did update.

-- 
This wasn't a proper land. The sky was blue, not flaming with all the
colours of the aurora. And time was passing. To a creature not born
subject to time, it was a sensation not unakin to falling. --Lords and
Ladies

___
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

Freeze/thaw and signed zone files

[@lbutlr via bind-users]

I edited a zone file after issuing a rndc freeze command, added two new sub 
zones, changed the serial number, saved the file, and then did an rndc thaw.

In var/log.messages I get

zone serial (2019020105) unchanged. zone may fail to transfer to slaves.

which is the previous serial number.

So, I tried to move the .signed file aside, thinking maybe thaw might recreate 
it, But no, it complains the file doesn’t exist, so I put it back. 

Is it possible for me to edit the zone file (as in with vim) and have bind 
update, or do I have to do everything through nsupdate and never access the 
zone files directly?

At this point, how do I get the zone updated?

If I try to dig for the new subdomains that are in the zone, they do not 
resolve, and all the information in DNS is the information that was there on 
21090201.

I am currently updating to bind912-9.12.3P1_3 to see if anything changes.

-- 
If you think that Mick Jagger will still be doing the whole rock star
thing at age fifty, well, then, you are sorely, sorely mistaken.

___
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: incorrect section name: $ORIGIN

[@lbutlr]

> On 5 Feb 2019, at 04:57, Tony Finch  wrote:
> 
> @lbutlr  wrote:
>> 
>> OK, then how do I get Bind9.122 to update the .signed files?
> 
> Did you see my previous message?

I did not, sorry.

> https://lists.isc.org/pipermail/bind-users/2019-February/101335.html

>> Are you doing `rndc freeze` and `rndc thaw` before and after editing the
> 
>> unsigned zone file?

No. I was under the impression that when bind reloaded (rndc reload and/or 
service named stop/start and/or service named reload) and saw a new serial 
number, it would generate a new .signed file for that zone as part of the 
process of refreshing its information and notifying the slaves.

It appears that I need an entirely different workflow that the one I've been 
using for the last couple of decades of editing the zone files and reloading 
the DNS server.

So, to update a zone now I should either use nsupdate to make the changes, or I 
should rndc freeze, edit the file, rndc thaw.

>> How are you checking the signed zone?

dig +dnssec example.com @127.0.0.1

So, right now, given that I did not freeze/thaw nor did I make the edits via 
nsupdate, how do I get the .signed files to be regenerated from the existing 
example.com zone file?


-- 
Two, Four, Six, Eight! Time to Transubstantiate!

___
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