Re: Sanity Check

On 17/02/2023 16:06, Bob McDonald wrote: I'm implementing a caching resolver under FreeBSD 13.1 running on a RaspberryPI. Bind 9.18.11 My named.conf is below. My question is do these look like workable options? I include logging and a statistics channel in my preliminary implementations for m

Sanity Check

I'm implementing a caching resolver under FreeBSD 13.1 running on a RaspberryPI. Bind 9.18.11 My named.conf is below. My question is do these look like workable options? I include logging and a statistics channel in my preliminary implementations for more detail on what's going on. That will go aw

Re: Requesting Update-Policy Statements Sanity Check, Please

Thanks Mark - that was the issue :-) I really, really appreciate the help Cheers Dulux-Oz On 04/02/2023 23:21, Mark Andrews wrote: Add DHCID to the list of record types permitted to be updated by the DHCP server. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe fro

Re: Requesting Update-Policy Statements Sanity Check, Please

Add DHCID to the list of record types permitted to be updated by the DHCP server. -- Mark Andrews > On 4 Feb 2023, at 21:15, duluxoz wrote: > > Thanks Mark (& Darren & Jan-Piet), > > So I made those changes you suggested (Mark), but I'm still having issues (ie > DHCP leases are not being

Re: Requesting Update-Policy Statements Sanity Check, Please

Thanks Mark (& Darren & Jan-Piet), So I made those changes you suggested (Mark), but I'm still having issues (ie DHCP leases are not being added to the DNS zones), so I've included my Bind9 config: ~~~ acl "bogusnets" {     !"internal_hosts";     0.0.0.0/8;     10.0.0.0/8;     172.16.0.0/12;

Re: Requesting Update-Policy Statements Sanity Check, Please

You need to replace the rule type with something more appropriate for the type of update being preformed. For the updates made by the DHCP server I would use “zonesub”. “name” is fine for LetsEncrypt. update-policy {grant update-key zonesub A ;}; update-policy {grant update

Re: Requesting Update-Policy Statements Sanity Check, Please

> On 3 Feb 2023, at 21:47, Darren Ankney wrote: > > You would probably need to attach your entire named.conf file (with > sensitive bits (keys and the like) redacted and perhaps subnets > obscured to examples such as 192.0.2.0/24, for example) before anyone > would be able to help you. > > Tha

Re: Requesting Update-Policy Statements Sanity Check, Please

You would probably need to attach your entire named.conf file (with sensitive bits (keys and the like) redacted named-checkconf -px is your friend: prints out the named.conf and included files in canonical form if no errors were detected and obscures shared secrets by replacing them with str

Re: Requesting Update-Policy Statements Sanity Check, Please

You would probably need to attach your entire named.conf file (with sensitive bits (keys and the like) redacted and perhaps subnets obscured to examples such as 192.0.2.0/24, for example) before anyone would be able to help you. That being said, your update policy statements don't look correct to

Requesting Update-Policy Statements Sanity Check, Please

Hi All, I'm pretty new to configuring Bind and so it would be great if someone(s) could just check my code re: the update-policy zone command(s) below - thanks in advance. For the first zone (a regular internal forward-lookup zone) I'd like to be able to update (from Kea via ddns) the zone w

Re: DNSSEC migration sanity check

Howdy bind-users list. TLDR: we were able to move zones between DNS servers with different KSK/ZSK while keeping the zones secure. First I want to say a BIG thank you for the replies received since it helped in documenting our workflow for these migrations. Off list, Paul E. mentioned that a

Re: DNSSEC migration sanity check

Hi John, It all depends on the key material that is used to sign your zone. It looks like you have to update the DNSKEY RRset, so I assume the vendors are responsible for signing and each have their own key material. In order to let the world know you are going to use new keys you will have to pr

Re: DNSSEC migration sanity check

Not sure I understand why you need to do anything except change the authoritative NS records in the zone and in the delegation at the registrar. You also only really need to decrease the TTL on the NS records, not all of the records in the zone. Why touch any keys and the corresponding DS records?

DNSSEC migration sanity check

We are in the process of moving from one IPAM vendor to another. All of our zones are DNSSEC signed and the TTL's have been lowered to 300 seconds. At a high level, the playbook is to update the registrar with names/IP addresses of the new servers and update the DSKEY. Depending on the time of

sanity check: localhost rpz

With a few exceptions, I'd like to block external answers for 127.0.0.0/8 Is the following really how it's supposed to be done? I can see having to whitelist the net-snmp.org names, but having to whitelist zones I'm authoritative for seems a bit weird. named.conf: options { ... response-po

Re: auto-dnssec sanity check (please)

In message , Jim Popovitch writes: > Hello, > > I recently rollled out auto-dnssec and inline-signing (v9.9.5), and > today (1-Oct 00:00 UTC) was the first automatic zsk rollover. > According to http://dnsviz.net/d/domainmail.org/dnssec/ it appears > that the SOA is signed by the new zsk, but t

auto-dnssec sanity check (please)

Hello, I recently rollled out auto-dnssec and inline-signing (v9.9.5), and today (1-Oct 00:00 UTC) was the first automatic zsk rollover. According to http://dnsviz.net/d/domainmail.org/dnssec/ it appears that the SOA is signed by the new zsk, but the rest of the RRs are still signed by the old. T

Re: problem registering DS records with EDUCAUSE, sanity check please

In message <070d01cfa067$ad9b1050$08d130f0$@acm.org>, "Paul B. Henson" writes: > > From: Stephane Bortzmeyer > > Sent: Tuesday, July 15, 2014 12:43 AM > > > > You can also note that it is quite common to publish DS without any > > matching KSK. It is even documented in RFC 6781, section 4.2.4. For

RE: problem registering DS records with EDUCAUSE, sanity check please

> From: Stephane Bortzmeyer > Sent: Tuesday, July 15, 2014 12:43 AM > > You can also note that it is quite common to publish DS without any > matching KSK. It is even documented in RFC 6781, section 4.2.4. For an > actual example, see .UK (the yellow > path). Inter

Re: problem registering DS records with EDUCAUSE, sanity check please

On Mon, Jul 14, 2014 at 07:14:57PM -0700, Paul B. Henson wrote a message of 56 lines which said: > I also don't think this is what educause is doing, as I haven't had > any trouble entering DS records for published but not activated > KSK's in the past, You can also note that it is quite comm

RE: problem registering DS records with EDUCAUSE, sanity check please

> From: Mark Andrews > Sent: Monday, July 14, 2014 6:33 PM > > For a DS to *work* it needs to point to a key that signs the DNSKEY > RRset. Validators check that the signature exists. Activating the > key will add 1 signature to the zone. Let me preface this reply by indicating that I am far fro

Re: problem registering DS records with EDUCAUSE, sanity check please

In message <20140715004923.gg31...@bender.unx.csupomona.edu>, "Paul B. Henson" writes: > On Tue, Jul 15, 2014 at 10:19:10AM +1000, Mark Andrews wrote: > > > The new key does not sign the DNSKEY RRset. > [...] > > Make sure the DNSKEY RRset is signed with the new key then try to > > add the DS re

Re: problem registering DS records with EDUCAUSE, sanity check please

On Tue, Jul 15, 2014 at 10:19:10AM +1000, Mark Andrews wrote: > The new key does not sign the DNSKEY RRset. [...] > Make sure the DNSKEY RRset is signed with the new key then try to > add the DS record to the parent. It's intentionally not being used for signing; it's published but not yet activa

Re: problem registering DS records with EDUCAUSE, sanity check please

ublished and does exist. > > After opening a trouble ticket, they indicate that they have received no > other complaints and as far as they know their system is working correctly. > While they continue to look into it, I was hoping to get a quick sanity > check to make sure I'm

RE: problem registering DS records with EDUCAUSE, sanity check please

> From: Stephane Bortzmeyer > Sent: Monday, July 14, 2014 1:43 PM > > > So, I suspect a bug in EDUCAUSE. > > Your DNSKEY set being a little over 1500 bytes, you may suspect a MTU > issue. Cool, thanks for double checking me and a potential problem to look at. Makes me feel a little bit better tha

Re: problem registering DS records with EDUCAUSE, sanity check please

On Mon, Jul 14, 2014 at 10:40:19PM +0200, Stephane Bortzmeyer wrote a message of 19 lines which said: > So, I suspect a bug in EDUCAUSE. Your DNSKEY set being a little over 1500 bytes, you may suspect a MTU issue. ___ Please visit https://lists.isc.

Re: problem registering DS records with EDUCAUSE, sanity check please

On Mon, Jul 14, 2014 at 01:24:38PM -0700, Paul B. Henson wrote a message of 135 lines which said: > And finally, the new key I just created, for which I'm trying to add DS > records. The dsset file created by dnssec-signzone says these records should > be: I find the same values as you, using

problem registering DS records with EDUCAUSE, sanity check please

, they indicate that they have received no other complaints and as far as they know their system is working correctly. While they continue to look into it, I was hoping to get a quick sanity check to make sure I'm not doing something stupid :). As of today, there are three DNSKEY KSK

Re: dnssec config sanity check

On 10/5/2011 10:25 AM, michoski wrote: Your initial hope is what I missed comments on... Me too; didn't get any "that's horribly broken because" or any "that looks good" feedback, guess I'll just have to review it a couple more times and hope for the best. "It is recommended that the transit

Re: dnssec config sanity check

On Wed, Oct 05, 2011 at 12:22:58AM -0700, Stephane Bortzmeyer wrote: > Not true. For every problem reported by the tool, I contacted the > managers of the domain, both to report they have an issue and to ask > them what system they were using. So, I'm pretty confident that > OpenDNSSEC had no suc

Re: dnssec config sanity check

On 10/4/11 3:49 PM, "Paul B. Henson" wrote: > dnssec is fairly complicated, and the issue of timing can be complex, > but once the variables are determined than the actual procedures of > implementation are pretty simple. Generate keys with appropriate > publication, activation, inactivation, and

Re: dnssec config sanity check

On Tue, Oct 04, 2011 at 03:49:25PM -0700, Paul B. Henson wrote a message of 40 lines which said: > Other than knowing a given domain had an issue, you have no idea > what caused it, or what tool they may have been using, and it is > only an assumption that the issue arose from a custom program

Re: dnssec config sanity check

On 10/3/2011 11:45 PM, Stephane Bortzmeyer wrote: Experience of DNSSEC deployment (see my paper at SATIN ) shows that custom programs have many timing bugs. Many things can go wrong Why not using an existing program such as Open

Re: dnssec config sanity check

On 10/3/2011 6:31 PM, Mark Andrews wrote: Don't ASSUME that the DS will be published in time. Build checks into your proceedures from the beginning. e.g. Publish and activate July 1. Change DS records July 8. Check that DS is published July 15 and set inactivate and deletion

Re: dnssec config sanity check

On Mon, Oct 03, 2011 at 05:32:18PM -0700, Paul B. Henson wrote a message of 59 lines which said: > Our zone data is maintained in a revision control repository; when > changes are made there is a process that generates a bind format > zone file from the data, checks it for syntax errors, compi

Re: dnssec config sanity check

In message <4e8a5412.7050...@acm.org>, "Paul B. Henson" writes: > We are getting ready to deploy dnssec, and I'd appreciate a quick sanity > check on our configuration and key timings to make sure I didn't miss > anything that would cause things to blow up ;

dnssec config sanity check

We are getting ready to deploy dnssec, and I'd appreciate a quick sanity check on our configuration and key timings to make sure I didn't miss anything that would cause things to blow up ;). Our zone data is maintained in a revision control repository; when changes are made there is

Re: Bind 9.7 - sanity check or a bug

> Interesting; can you be more specific - what version info are you > referring to, and which checking routines. When you update a zone, the new version of the zone has to be internally consistent. There was a bug where the consistency check was being applied against the old version of the zone

Re: Bind 9.7 - sanity check or a bug

In case two, you are sending the delete as one transaction and the add as a 2nd transaction. I'm surprised the 2nd case fails at the 2nd transaction, not the first. Known bug. The version information was not passed down to the checking routines. Interesting; can you be more specific - what

Re: Bind 9.7 - sanity check or a bug

In message <4d42a8df.10...@imperial.ac.uk>, Phil Mayers writes: > On 28/01/11 10:50, Din Jo wrote: > > > case 1: > > # nsupdate > > > server 127.0.0.1 > > > update delete server2.test.com A > > > update add server2.test.com A 10.0.0.2 >

Re: Bind 9.7 - sanity check or a bug

On 28/01/11 10:50, Din Jo wrote: case 1: # nsupdate > server 127.0.0.1 > update delete server2.test.com A > update add server2.test.com A 10.0.0.2 > send > quit case 2: # nsupdate > server 127.0.0.1 > update delete server2.test.c

Re: Bind 9.7 - sanity check or a bug

d: REFUSED > quit syslog will show: "updating zone 'test.com/IN': update rejected: post update name server sanity check failed" In case 1 it is not giving any error. Why it is giving "sanity check error" in case 2 only? If this is because "NS records without A

Bind 9.7 - sanity check or a bug

d: REFUSED > quit syslog will show: "updating zone 'test.com/IN': update rejected: post update name server sanity check failed" In case 1 it is not giving any error. Why it is giving "sanity check error" in case 2 only? If this is because "NS records without A