Re: compile and install from source

[@lbutlr]

On Mar 30, 2015, at 2:30 AM, Matthew Seaman  
wrote:
> On 03/30/15 00:35, @lbutlr wrote:
>> Downloaded and compiled bind-9.9.7 (FreeBSD 8.4-RELEASE) and it built fine 
>> (./configure && make && make install).
> 
> On FreeBSD, building software out of the ports is definitely
> recommended.  It does the usual configure and make dance, but you also
> get the benefit of using the package management system, and any OS
> specific patches that might need to be applied.  (Not that there are
> many with BIND).

And I normally do that, however in this specific case it was not possible.

> Can you start the named process "by hand" -- the command line should be
> something like:
> 
> # /usr/local/sbin/named -u bind -c /etc/namedb/named.conf \
>   -t /var/named

Yes, that works without reporting any errors, so the issue appears to be with 
/usr/local/etc/rc.d/named startup script.

> syslogd_flags="-l /var/named/var/run/log"
> 
> to /etc/rc.conf and restarting syslogd may get you some better logging
> information.

Don’t see anything logged on either the startup or the failed startup.

However, if I try to check rndc…

# /usr/local/sbin/rndc status
rndc: neither /etc/rndc.conf nor /etc/rndc.key was found

Now, it is true that there is no rndc.conf, but that is true all all three name 
servers. There is a rndc.key in /var/named/etc/namedb/rndc.conf

I’m not sure why it is looking in (I assume /var/named/etc instead of)  
/var/named/etc/namedb.

is named_chrootdir="/var/named" not correct?


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

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

Re: compile and install from source

[@lbutlr]

> On Mar 31, 2015, at 02:46, Mathieu Arnold  wrote:
> 
> +--On 30 mars 2015 19:32:09 -0600 "@lbutlr"  wrote:
> |> # /usr/local/sbin/named -u bind -c /etc/namedb/named.conf \
> |>-t /var/named
> | 
> | Yes, that works without reporting any errors, so the issue appears to be
> | with /usr/local/etc/rc.d/named startup script.
> 
> Well, your first post says you're using 8.4, so there should be no such
> script, it should be in /etc/rc.d.

Yes, you’re right. That was a thinko.

>  /usr/local/sbin/rndc status
> | rndc: neither /etc/rndc.conf nor /etc/rndc.key was found
> 
> That's because you built named manually and not from ports, so it doesn't
> know where it should find its bits.

I don’t see why not, /etc/defaults/rc.conf shows:

named_program="/usr/sbin/named" # Path to named, if you want a different one.
named_conf="/etc/namedb/named.conf" # Path to the configuration file
named_chrootdir="/var/named"# Chroot directory (or "" not to auto-chroot it)

So it seems it should be looking in /var/named/etc/namedb/ (and in fact it does 
look there for the conf file); rndc seems to be looking elsewhere though.

> | Now, it is true that there is no rndc.conf, but that is true all all
> | three name servers. There is a rndc.key in /var/named/etc/namedb/rndc.conf
> | 
> | I’m not sure why it is looking in (I assume /var/named/etc instead of)
> | /var/named/etc/namedb.
> 
> Because you built it manually so it did not get all the right configure
> options the port has.

OK, well I cannot build via ports, so what magic does the port invoke?

> | is named_chrootdir="/var/named" not correct?
> 
> It is.

Then why can’t rndc find the key file? And why is it looking outside the chroot?

 # cp rndc.key /etc
 # rndc status
version: 9.9.7 
[… Stuff …]
server is up and running
 #


-- 
Honesty may be the best policy, but it's important to remember that
apparently, by elimination, dishonesty is the second-best policy.

___
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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 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
https://lists.isc.org

$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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

base domain doesn't respond with an IP

[lbutlr]

On a domain all the subdomain names resolve to IP address (mail, ns1, www, etc 
etc) but the base domain name does not.

the config files looks like:

$ORIGIN .
$TTL 86400  ; 1 day
covisp.net. IN SOA  ns1.covisp.net. root.covisp.net. (
   2016103100 ; serial
 1H ; refresh
 15 ; retry
 1w ; expire
 600 ; minimum
   )
   NS  ns1.covisp.net.
   NS  ns2.covisp.net.
   NS  mail.covisp.net.
   MX  10 mail.covisp.net.
$ORIGIN covisp.net.
mailA   65.121.55.42
ns1 A   65.121.55.43
ns2 A   65.121.55.44
www A   65.121.55.45

dnscheck.pingdom.com shows everything is fine.

>

# dig covisp.net @ns2.covisp.net
…

;covisp.net.IN  A

;; AUTHORITY SECTION:
covisp.net. 600 IN  SOA ns1.covisp.net. 
root.covisp.net. 2016103100 3600 15 604800 600

(I have also tried the following, with no change:

$ORIGIN covisp.net.
.A   65.121.55.42
mail A   65.121.55.42

I’m sure it’s something stupid….

___
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: base domain doesn't respond with an IP

[lbutlr]

On Nov 2, 2016, at 3:24 AM, Alberto   wrote:
> @INAip.ip.ip.ip

Ah, of course!

Thanks!

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

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

Reasons to upgrade?

[lbutlr]

It looks like there are three version of Bindcurrently supported, 9.9.9, 9.10, 
and 9.11.

Are there specific reasons to move from 9.9 to 9.10 or 9.11 other than the 
usual "it's newer and you're going to have to move at some point anyway"?

Any gotchas?

-- 
Apple broke AppleScripting signatures in Mail.app, so no random signatures.



-- 
Apple broke AppleScripting signatures in Mail.app, so no random signatures.

___
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: Reasons to upgrade?

[lbutlr]

On 2017-01-18 (09:07 MST), Mukund Sivaraman  wrote:
> 
> On Wed, Jan 18, 2017 at 08:02:04AM -0700, lbutlr wrote:
>> It looks like there are three version of Bindcurrently supported,
>> 9.9.9, 9.10, and 9.11.
>> 
>> Are there specific reasons to move from 9.9 to 9.10 or 9.11 other than
>> the usual "it's newer and you're going to have to move at some point
>> anyway"?
> 
> See:
> 
> https://kb.isc.org/article/AA-01432/0/BIND-9.11.0-Release-Notes.html

Thanks everyone, I’ve got some reading to do.

One note for whoever maintains the list, I use my twitter handle as my real 
name, but this list has a very aggressive grep match that triggers on the @ in 
my twitter handle.

(the grep is ^From:.*@.*@.*$ and should be ^From:.*\<.*@.*@.*\>$

-- 
Apple broke AppleScripting signatures in Mail.app, so no random signatures.

___
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 with dnscrypt-proxy

[lbutlr]

Running bind 9.9.9 and am interested in setting up dnscrypt to go with it.

Is dnscrypt-proxy the right way to go, or encrypt-wrapper? (it looks like 
wrapper is a client tool and that -proxy is what actually talks to the clients).

If anyone has done this is it reasonably simple to setup and maintain? 

NB: "The message headers matched ^From:.*@.*@.*$" is the dumbest filter ever 
and a perfect example of a lazy regex.

-- 
Apple broke AppleScripting signatures in Mail.app, so no random signatures.

___
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

SOA settings

[lbutlr]

I am looking at a config file and seeing:

2017112100 ; serial
1H ; refresh
15 ; retry
1w ; expire
1H ; minimum

Is that 15 15 seconds?

I'm guess ion it should be 15m?

-- 
ADVANCE TO THE REAR!
___
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: SOA settings

[@lbutlr]

On 2 Feb 2018, at 12:57, Warren Kumari war...@kumari.net> wrote:
> 
> ) yes, that is 15 seconds, and is almost definitely not what
> you want.

That's what I figured. I suspect, based on the spacing in the file, someone<1> 
inadvertently deleted the 'm'.

Thanks all (and yes, that was /PART/ of an SOA record :)

<1> me, almost certainly, but I'll deny it.

-- 
Greedo didn't shoot first, motherfucker!

___
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: Minimum TTL?

[@lbutlr]

On 2018-02-08 (03:10 MST), Michelle Konzack  
wrote:
> 
> Hi,
> 
> Am 2018-02-08 hackte LuKreme in die Tasten:
>> Is it possible to tell bind to ignore very short TTLs and enforce
>> a...say... 5 second minimum TTL?
> 
> VERY SHORT TTL?

YEs.

> 5 sec minimum?

Yes.

> What Du you mean with ignoring?

Ignoring responses with TTLs or <5 seconds and treating them as if the TTL was 
5 seconds.

> It is you YOU have to configure Bind9 correctly to longer TTLs.

I cannot configure bind for other DNS servers.

> If the NS Entry is not a Dyn-DNS entry,
> it should have anyway at least 3600 seconds.

"Should" is a pointless word 99.999% of the time it is used.


-- 
i wasn't born a programmer. i became one because i was impatient. - Dave
Winer

___
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: Minimum TTL?

[@lbutlr]

On 2018-02-08 (08:51 MST), Mukund Sivaraman  wrote:
> 
> Also, just for argument's sake, one user wants to extend TTLs to
> 5s. Another wants 60s TTLs. What is OK and what is going too far?


For the record, the issue is not RBLs or legitimate domains, it is spammer scum 
that set super-low DNS because they are shotgunning spam from a a vast botnet 
and they want to have maximal impact, so you get a different IP for every spam 
they send. It is a way of trying to overwhelm a machines tarpits, blacklists, 
sshguard protections, and others.

But to answer your question, off-hand, I'd say that any TTL under 60s is 
suspicious and any TTL under 10s is almost certainly intentionally abusive.

But that's just me, giving it maybe 20 seconds of thought.

-- 
So now you know the words to our song, pretty soon you'll all be singing
along, when you're sad, when you're lonely and it all turns out wrong...

___
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: Minimum TTL?

[@lbutlr]

On 2018-02-09 (21:11 MST), John Levine  wrote:
> 
> In article  you write:
>> For the record, the issue is not RBLs or legitimate domains, it is =
>> spammer scum that set super-low DNS because they are shotgunning spam =
>> from a a vast botnet and they want to have maximal impact, so you get a =
>> different IP for every spam they send. It is a way of trying to =
>> overwhelm a machines tarpits, blacklists, sshguard protections, and =
>> others.
> 
> Um, you have it completely backward.

No, I don't.

AS I explained upthread, the mechanism works something like this.

buy garbage domain. Setup DNS with a  TTL of 1S and have the IP change to 
random machines on your botnet.

Spew Spam at a single mail server.

The target, instead of very quickly rejecting the spam because of the lack of a 
domain or the lack of DNS, instead has to deal with thousands of different IPs.

Everyone of those is going to hit scammer scums DNS servers.

At some point those thousands (tens of thousands? hundreds of thousands?) 
requests are going to have a serious impact on your mail server. Meanwhile, you 
are giving spammer scum a lot of information about how much traffic your server 
can deal with since they can easily see when your responses start to slow down.

> Botnets are computers with IP addresses.  They don't need DNS pointing at 
> them to send spam.

They do to send spam to any mail admin with even half a brain who would not 
accept unauthenticated mail from an IP without an actual domain attached.

> I hope you're not planning to do much spam filtering.

a 5s TTL will not make an appreciable effect on RBLs 

-- 
If you mixed vodka with orange juice and Milk Of Magnesia, would you get
a Philip's Screwdriver?

___
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: Minimum TTL?

[@lbutlr]

On 2018-02-10 (12:15 MST), Barry Margolin  wrote:
> 
> Just because you have the right to do something doesn't mean it's a 
> reasonable thing to do.

No one has made an argument that would imply this is not reasonable.

> And if you're offering a service, you have responsibilities to your customers 
> in addition to rights. They likely have expectations of the quality of your 
> service. Sure, you have the right to disappoint them, but do you really want 
> to do that intentionally if you have alternatives?

I don't think anyone is expecting that respecting a 1-4s TTL is part of a 
service arrangement.


-- 
Outside of a dog, a book is a man's best friend. Inside of a dog, it's
too dark to read.

___
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: DNS not resolving on google, but is on other services

[@lbutlr]

On 2018-02-17 (02:48 MST), Niall O'Reilly  wrote:
> 
> In my not-very-extensive experience, Google's 8.8.8.8 service seems to have 
> limited tolerance of badly-behaving authority servers; in such a case, it 
> seems to give up early and report SERVFAIL.
> 
> As it happens, there seem to be problems with the set of authority servers 
> involved.
> 
> You'll find more information at https://zonemaster.fr/test/932ded6946bfebb4 .

Thank you for that, I got the missing server up and running and it all checks 
out now (Well, other than my servers are in the same IP block, which I cannot 
do anything about).

I've never heard of zonemaster.fr before, so I've added it to my bookmarks.

-- 
"His mother should have thrown him away and kept the stork." - Mae West

___
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: DNS not resolving on google, but is on other services

[@lbutlr]

On Feb 17, 2018, at 06:04, Reindl Harald  wrote:
> "Is google just b0rked?" is mostly wrong to start with

As I said, that seems unlikely. But the different behavior from multiple large 
DNS services was odd.

> Delegation
> 
> Failed to find name servers of david-dodge.com/IN.

I may have been mucking with it then. Everything returns correct now except 
that the serial numbers don’t match on one server because the delegation has 
failed to sync. I’ll see if it clears on its own.

-- 
This is my signature. There are many like it, but this one is mine.
___
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

questions on allow-query

[@lbutlr]

If I set 

allow-query { 127.0.0.1; [myipblock]; }

Then my DNS doesn't respond to any other servers, right? This would be bad for 
being authoritative. so, should I set that and then set allow-query { any; }; 
in each zone?

Is that better than simply setting the IPs that are allowed recursion?



___
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: "Hiding" version.bind in /etc/bind/named.conf.options doesn't work

[@lbutlr]

On Feb 28, 2018, at 09:57, G.W. Haywood via bind-users 
 wrote:
> On Wed, 28 Feb 2018, (Ing. Pedro Pablo Delgado Martell) wrote:
>> Good morning, I'm trying to make it more difficult for an attacker to
>> get my DNS server version.
> 
> Waste of time.  The attacks are automated, and will be mounted anyway.

And attackers don’t care what the version string is as they do not even look 
for it.

-- 
This is my signature. There are many like it, but this one is mine.


___
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: Odd behavior on a secondary server

[@lbutlr]

On 2018-03-22 (08:13 MDT), John Miller  wrote:
> 
> Is this normal or am I missing something.

It is normal. It is confusing, but it is normal.

-- 
Traveling through hyperspace ain't like dusting crops, boy.

___
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: Cause BIND 9.10.6-P1 running dnssec to update zone A record

[@lbutlr]

On 2018-03-29 (11:58 MDT), Kim Culhan  wrote:
> 
> Made a change to an ip address in an A record and bind is still showing the 
> old
> address.
> Updated the serial and it doesn't show the new serial either.
> 
> How can I get bind to update from the data in the zone file?
> 
> I 've restarted named and used rndc to reload and have not
> found how to get it to update.

Sound like you are editing the wrong file.

rndc relaid reloads the files, if the change is not being rejected, you need to 
figure out where the right file is.

-- 
The voice of the majority is no proof of justice.

___
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

DNSSEC and secondary DNS servers

[@lbutlr]

So, I setup up DNSSEC on my authoritative bind 9.12 server, which was very 
straightforward and works fine:

dig covisp.net +dnssec +short @8.8.8.8
65.121.55.42
A 7 2 86400 20181008122535 20180908122535 17363 covisp.net. 
pkpVdFONJ2dYN+7wQ4pVcQTlWIThY3+mbNdXsE8p5uWiLNvIefVT32JE 
i9itA3Si91/pImofmPnLPbxRbLzWt+dSfbxBoHaoCYK1ZCngw/vy9QlG 
36Um0De5ItCC/GuflXUnBKmEJKx0pQOlvqSnkRSV75yLnAw3NA0BdKnf 
CBJP9QLQH/A1vojRafIER5MNM34lKfJC9QrMDBiUBYzrv3i/2QK3gE7t 
8Y1Zpoemux8Uz/zps1I/pmjVAIixk2ilVOLDXkeS6Ta4ODrWayyuFM8b 
xwkodXsMtFAx5PhkVyHT5zJyScYYzC82aZs7fTmA6F01saabVsxIYAi6 78upgA==

But now, what do I need to do for other DNS servers? Is it enough to simply add

dnssec-enable yes;
dnssec-validation yes;
managed-keys-directory "/usr/local/etc/namedb/working/keys";

? Should it simply validate the key with the primary and go from there? 

I tried this, but trying to do a dig +dnssec on the secondary DNS doesn’t 
return the record, so I think there must be something else.


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

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

Re: DNSSEC and secondary DNS servers

[@lbutlr]

On 08 Sep 2018, at 09:59, Niall O'Reilly  wrote:
> On 8 Sep 2018, at 14:58, @lbutlr wrote:
> 
>> so I think there must be something else.
> 
> You might need to so some other housekeeping:
> 
> https://zonemaster.net/domain_check
> http://dnsviz.net/d/covisp.net/dnssec/

Oh, well, that is interesting. I though Bind always listened on port 53 for 
both TCP/UDP.

# sockstat -4 -l | grep :53
bind named  48714 21 tcp4   65.121.55.42:53   *:*
bind named  48714 23 tcp4   127.0.0.1:53  *:*
bind named  48714 512 udp4  65.121.55.42:53   *:*
bind named  48714 513 udp4  65.121.55.42:53   *:*
bind named  48714 514 udp4  65.121.55.42:53   *:*
bind named  48714 518 udp4  127.0.0.1:53  *:*
bind named  48714 519 udp4  127.0.0.1:53  *:*
bind named  48714 520 udp4  127.0.0.1:53  *:*

And there’s nothing interesting in pfctl

 # pfctl -s rules
block drop in quick on em0 from  to any label "sshguardblock"
block drop in quick on em0 from  to any
pass in quick on em0 proto tcp from  to (em0) port = ssh flags S/SA 
keep state
pass in on em0 proto tcp from any to (em0) port = ssh flags S/SA keep state 
(source-track rule, max-src-conn 5, max-src-conn-rate 4/300, overload  
flush global, src.track 300)


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

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

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

Re: DNSSEC and secondary DNS servers

[@lbutlr]

On 08 Sep 2018, at 11:46, @lbutlr  wrote:
> I need to check that I am supposed to generate the digest.

to check *HOW* I am supposed to generate the digest.



-- 
Ille Qui Nos Omnes Servabit

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

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

Re: DNSSEC and secondary DNS servers

[@lbutlr]

On 08 Sep 2018, at 10:21, Mark Elkins  wrote:
> Have you DNSSEC Signed your Domain - that is "covisp.net" because I
> don't see any DS records for it in the "net" zone.

Not yet, I want to have everything working on my side before I go upstream. 
Hover is pretty simple to setup the DNSSEC but I need to check that I am 
supposed to generate the digest.



-- 
I never wanted to do this in the first place.

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

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

Re: DNSSEC and secondary DNS servers

[@lbutlr]

On 9 Sep 2018, at 14:58, Mark Elkins  wrote:
> Umm... this initially looks great but something is seriously strange. The 
> first numerical value after DS should be the Key ID (or Key Tag). I really 
> doubt that you would (randomly) create two different DNSKEY records with 
> sequential Key-ID's (Tags) starting from "1"... its usually a relatively 
> random value between 1 and 2^16

Yes, that was a mistake in the configuration.

> Also as an aside - many people are no longer putting the SHA-1 Digest type DS 
> record in their parent, just the longer (more secure?) SHA-256 (Digest Type 
> 2) record.

Thanks, I keep that in mind.

> As the root uses Algorithm 8 - many people also use algorithm 8 - you are 
> using algorithm 7. Algorithm roll-overs are a pain so if you can - move 
> straight to 8.


And that.

> I also can not detect a DNSKEY in your zone?
> dig covisp.net dnskey +cd
> ...gives your SOA.
> Without the "+cd" (ignore any DNSSEC validation) - I get a SERVFAIL.

Yes, I was in the midst of futzing with things at the time.

> Adding DS records into your parent should be the last part of the process in 
> securing your Zone with DNSSEC.

I've pulled the DNSSEC entirely for right now as there is still some research I 
need to do (things like renewal, automating the process for other domains, etc).

-- 
"I've had a perfectly wonderful evening. But this wasn't it." - Groucho
Marx

___
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 UDP tuning

[@lbutlr]

On 30 Sep 2018, at 09:59, Alex  wrote:
> It also tends to happen in bulk - there may be 25 SERVFAILs within the
> same second, then nothing for another few minutes.

That really makes it seem like either you modem or you ISP is interfering 
somehow, or is simply not able to keep up.


-- 
'Who's that playing now, Mr. Dibbler?' "'And you".' 'Sorry, Mr.
Dibbler?' 'Only they write it &U,' said Dibbler. --Soul Music

___
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

DNSEC and Bin 9.12

[@lbutlr]

A couple of questions

First, guides on setting up DNSSEC say to add  dnssec-lookaside auto; in the 
options, but bind repots an error:

/usr/local/etc/namedb/named.conf:35: dnssec-lookaside 'auto' is no longer 
supported

Does this mean the entire declaration is not supported, or that auto should be 
changed to something else?

Second, I’ve seen recommendations for " dnssec-validation auto;” and " 
dnssec-validation yes;” but no clear explanation on which should be used.

Third, what does “not at top of zone” mean in dnssec-verify?

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

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

Re: DNSEC and Bin 9.12

[@lbutlr]

On 21 Jan 2019, at 13:49, Mark Andrews  wrote:

Thanks for the info on the first two questions.

>> Third, what does “not at top of zone” mean in dnssec-verify?
> 
> Some record that should have been at the zone’s apex (name) wasn’t.  Either 
> you passed the wrong
> zone name to dnssec-verify or you have put records in the wrong place in the 
> zone.

OK, named-checkzone returns "OK" but the dnssec-verify complains about not at 
top of zone. 

Ah, wait, no, I was doing it wrong.

Now both commands return success, but after reloading bind and trying to query 
localhost for the DNSEC information it returns nothing.

I then removed "auto-dnssec maintain" and "inline-signing yes" from the zone 
record in name.conf and now everything is behaving as expected when I query 
localhost for the DNSSEC info. (I know this is not complete until I update the 
records at the registrar, but I am not ready to do that).

Which brings up one more question, what sort of maintenance/renewal process do 
I need to implement, if any? Once the zone is signed I assume that signature 
expires at some point. when I edit the conf file, I will have to manually 
regenerate the sonf.signed file since I had to remove "auto-dnssec maintain", 
yes?

-- 
'You know the worst of it?' said Rincewind.
'Oook?'
'I don't even remember walking under a mirror.' --Mort

___
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: DNSEC and Bin 9.12

[@lbutlr]

On 26 Jan 2019, at 12:20, @lbutlr  wrote:
> I then removed "auto-dnssec maintain" and "inline-signing yes" from the zone 
> record in name.conf and now everything is behaving as expected when I query 
> localhost for the DNSSEC info.

I should have said, I have update-policy local; in the zone record, but if I 
add "inline-signing yes;" and/or "auto-dnssec allow;" then the query fails.


-- 
Rick: And remember, this gun is pointed right at your heart. Captain Renault: 
That is my *least* vulnerable spot

___
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: DNSEC and Bin 9.12

[@lbutlr]

On 26 Jan 2019, at 12:55, Alan Clegg  wrote:
> With the appropriate trust anchors in place, data in the zone validates.

Everything appears to be working locally at this point, including with 
"auto-dnssec maintain;" which I swear was not working a few hours ago. Perhaps 
I tyoped.

> Does this help at all?  If not, can you be a bit more detailed in the problem 
> you are trying to solve?

Just trying to get the configuration right before I go add the DNSSEC to the 
registrar, and also trying to understand how it is all supposed to work so I 
don't run into any surprises in a week or a month or a year (especially the 
latter, when I will have forgotten everything).

-- 
"His mother should have thrown him away and kept the stork." - Mae West

___
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: DNSEC and Bin 9.12

[@lbutlr]

On 21 Jan 2019, at 12:32, @lbutlr  wrote:
> A couple of questions

I’d like to thank everyone who helped out on this, got it all sorted, added to 
the registrar, and it is all working, Now to do it for all the other domains. :)


-- 
The most perfidious way of harming a cause consists of defending it
deliberately with faulty arguments.

___
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: Selective forwarding?

[@lbutlr]

> On 29 Jan 2019, at 00:25, ObNox  wrote:
> 
> On 24/01/2019 10:26, Sam Wilson wrote:
> 
 Note:  I'm assuming a zone expiry of a week to a month.  I think that 
 would accommodate most outages.
>>> 
>>> I thought of that too :-) A week would be far enough in my case.
>> Be careful of what you mean by "a week".  If a problem happens on a Friday 
>> just after you leave for a week's holiday/vacation then you need a 10-day 
>> timeout to be able to fix it on the Monday you come back.
> 
> Sorry for the late reply.
> 
> I really like how sysadmins think :-) I always take that into account. When I 
> setup something to a "week" or a "month", in reality it's  + 
> 2~3 days depending on the situation.

A "week" is a minimum of 10 days, because 5 works days plus two weekends in 9 
days.

-- 
And the three men I admire most, the father son and the holly ghost they
caught the last train for the coast…

___
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