On 8/18/20 5:55 PM, Mark Andrews wrote:
> If you are getting RST responses check your firewall settings. RST is often
> forged
> when TCP is blocked. The root servers normally accept TCP connections.
>
> % dig +tcp gmail.com @a.root-servers.net +dnssec
Bingo. This query failed before adding
bind 9.11.5.P4 on Debian 10
Greetings. I recently had to migrate a nameserver from FreeBSD to
Debian. It works fine most of the time but I've noticed a few
intermittent resolution failures.
After "gmail.com" failed to resolve I took a packet capture using
tcpdump to listen to the result of the
A newly minted ZSK signs a domain's SOA but not its A or MX records.
What basic config step did I miss?
For the domain 'trikids123.com' I created and installed a new ZSK with a
key ID of 28053 using these commands:
dnssec-keygen -a 8 -b 1024 trikids123.com
chown bind:bind * # this is bind910
On 7/31/15 4:33 AM, Tony Finch wrote:
David Newman dnew...@networktest.com wrote:
On 7/30/15 10:37 AM, Evan Hunt wrote:
On Thu, Jul 30, 2015 at 10:30:33AM -0700, David Newman wrote:
Hidden primary (not authoritative for this zone): Key still in zone
I think what you mean here
On 7/30/15 10:37 AM, Evan Hunt wrote:
On Thu, Jul 30, 2015 at 10:30:33AM -0700, David Newman wrote:
After that second procedure (and also chown'ing the keyfiles to the bind
user), the command 'dig +dnssec +multi dnskey example.com' gives
different results depending on which nameserver gets
On 7/30/15 9:06 AM, Evan Hunt wrote:
On Wed, Jul 29, 2015 at 07:29:29PM -0700, David Newman wrote:
It's a static zone. The zone file did not have the key in it.
... oh, it's inline-signing.
Sorry, I also didn't mention that this is a hidden primary server, which
may be relevant below
On 7/29/15 6:24 PM, Evan Hunt wrote:
On Wed, Jul 29, 2015 at 05:56:20PM -0700, David Newman wrote:
29-Jul-2015 17:18:19.439 general: warning:
dns_dnssec_keylistfromrdataset: error reading private key file
example.com/RSASHA256/36114: file not found
Delete that key from the DNSKEY rrset
On 2/11/14 7:38 AM, Chris Thompson wrote:
On Feb 10 2014, Mark Andrews wrote:
In message 52f94ee2.7080...@ksu.edu, Lawrence K. Chen, P.Eng. writes:
[... snip ...]
On 02/06/14 15:07, Timothe Litt wrote:
[... snip ...]
Note also the RFC 5155 recommendation:
The salt SHOULD be at least 64
The Michael W. Lucas DNSSEC book recommends changing NSEC3 salt every
time a zone's ZSK changes.
Is this just a matter of a new 'rndc signing' command, or is some action
needed to remove the old salt?
thanks
dn
___
Please visit
On 2/2/14 5:39 AM, Tony Finch wrote:
David Newman dnew...@networktest.com wrote:
On 1/31/14 10:35 AM, Tony Finch wrote:
David Newman dnew...@networktest.com wrote:
What action, if any, is needed?
Does rndc sign zone make it wake up?
Alas, no. There are a bunch of successful IXFR messages
On 1/31/14 3:10 AM, Tony Finch wrote:
2. For five domains, the log contains signature-has-expired warnings.
In all five cases, these are for NSEC3PARAM records.
Is any action needed on my part, for example manually doing NSEC3
signing of these zones?
See if named has already re-signed
On 1/31/14 10:35 AM, Tony Finch wrote:
David Newman dnew...@networktest.com wrote:
What action, if any, is needed?
Does rndc sign zone make it wake up?
Alas, no. There are a bunch of successful IXFR messages to slave servers
but the dates in that NSEC3PARAM RRSIG did not change
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/28/14 3:49 AM, Alan Clegg wrote:
On Jan 27, 2014, at 7:32 PM, David Newman dnew...@networktest.com
wrote:
Asking again, in a different and more generic form: When
rebuilding a bind 9.9.4 server running DNSSEC with auto maintain
for multiple
domains.
I'm concerned about keeping keys, serial numbers, and any other dynamic
info in sync.
Thanks!
dn
On 1/23/14 10:16 AM, David Newman wrote:
Are there any recommended practices/config changes needed when upgrading
or restoring a bind 9.9.4 server using DNSSEC inline signing
Are there any recommended practices/config changes needed when upgrading
or restoring a bind 9.9.4 server using DNSSEC inline signing and auto
maintain?
Asking specifically about upgrading a server running on NanoBSD, but
this question is really about upgrading or restoring any DNSSEC server
with
On 11/14/13 1:29 PM, Kevin Oberman wrote:
Don't forget that Google will white-list domains with known (by them)
broken DNSSEC and reply even though validation is broken, so using
8.8.8.8 for checking on whether validation is broken is not the best idea.
Really? Google sets the ad flag for
On 11/6/13 1:06 AM, Steven Carr wrote:
Start with chapter 11.4 The DNS Security Extensions in DNS BIND
http://www.amazon.com/DNS-BIND-5th-Edition-Cricket/dp/0596100574
Lucas' DNSSEC Mastery is also a useful resource, not only about DNSSEC
concepts but also about required prep work and
On 10/28/13 1:46 PM, Mark Andrews wrote:
In message 526eba87.7040...@networktest.com, David Newman writes:
3. Another internal nameserver gets intermittent dig +dnssec errors on
queries for internal resources. Sometimes after a restart, the result is
NOERROR and other times it's NXDOMAIN
What is the recommended practice for adding DNSSEC to an environment
that currently uses split DNS?
Apologies as I'm sure this has come up before, but most discussion I
found on bind-users was from 1999, and this isn't covered in the ARM.
I did find this draft (not RFC) from 2007, but even the
526857a2.8050...@networktest.com, David Newman writes:
What is the recommended practice for adding DNSSEC to an environment
that currently uses split DNS?
Apologies as I'm sure this has come up before, but most discussion I
found on bind-users was from 1999, and this isn't covered in the ARM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Alan,
Thanks very much for your responses. Per my comments inline below,
this actually wasn't broken to begin with, but I just wasn't seeing it.
On 10/14/13 10:43 AM, Alan Clegg wrote:
On Oct 13, 2013, at 9:03 PM, David Newman dnew
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/14/13 12:39 PM, Alan Clegg wrote:
In this case, I started with a serial of 2013092700, incremented
it to 2013092701, and reloaded. 'dig soa' would still return
2013092700.
Problem is, bind logged the current serial number as 2013092705.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/13/13 1:34 AM, Alan Clegg wrote:
On Oct 12, 2013, at 7:59 PM, Alan Clegg a...@clegg.com wrote:
On Oct 11, 2013, at 10:54 PM, David Newman
dnew...@networktest.com wrote:
4. Check that the new server is working and you can update
On 10/11/13 7:32 AM, Vishal Gandhi wrote:
We are planning to sign local zone (fdu.local). Is it required to sign
the parent zone (fdu.edu http://fdu.edu) as well or we can live with
it unsigned?
What are pros and cons of signing parent zone (fdu.edu http://fdu.edu)?
DNSSEC is based on a
On 10/4/13 10:23 AM, David Newman wrote:
On 10/3/13 5:27 PM, Sten Carlsen wrote:
This works for me and is the standard method:
rndc freeze
update serial
rndc thaw
Bingo. Thanks!
Sorry, spoke too soon. I followed your instructions and Mark's but I'm
not seeing the zone file serial number
On 10/10/13 4:26 AM, Lightner, Jeff wrote:
CentOS does put
bug and security fixes in (or RedHat does and CentOS gets them because
they build from RHEL source) but you still end up with something very
old (BIND 9.3.x) that most folks on this list don’t want to talk about
because it is long
On 10/8/13 5:54 PM, Mark Andrews wrote:
In message 52548a5d.3070...@networktest.com, David Newman writes:
bind 9.9.4
How to troubleshoot issues when keys are supposed to be invalidated or
deleted on specific dates, but aren't?
In this case, a KSK was supposed to be inactivated on 29
On 10/9/13 1:24 PM, Mark Andrews wrote:
In UTC terms, we've already passed the key's deletion date. Can I
retroactively extend the key's deletion date?
Yes. The files are not removed. You will need to tell named to re-read
the .private file using rndc signzone after setting the time the
bind 9.9.4
How to troubleshoot issues when keys are supposed to be invalidated or
deleted on specific dates, but aren't?
In this case, a KSK was supposed to be inactivated on 29 September 2013
and deleted on 9 October 2013.
From the .key file:
; This is a key-signing key, keyid 56989, for
On 10/8/13 3:51 PM, Alan Clegg wrote:
On Oct 8, 2013, at 6:42 PM, David Newman dnew...@networktest.com
wrote:
bind 9.9.4
How to troubleshoot issues when keys are supposed to be
invalidated or deleted on specific dates, but aren't?
In this case, a KSK was supposed to be inactivated
, David Newman wrote:
Thanks all for your responses.
On 10/1/13 6:42 PM, Mark Andrews wrote:
As Alan said copy the .key and .private files over.
Disable updating on the old master.
Transfer the zone contents by setting up as a slave
using masterfile-format text; or using by using dig
Thanks all for your responses.
On 10/1/13 6:42 PM, Mark Andrews wrote:
As Alan said copy the .key and .private files over.
Disable updating on the old master.
Transfer the zone contents by setting up as a slave
using masterfile-format text; or using by using dig.
This will give you the
Is there a recommended order of operations when moving DNSSEC-enabled
nameservers to a hidden-master setup?
I'm hoping it's just as simple as moving all these files into place on
the hidden master:
*.key
*.private
managed-keys.bind
*.jbk
*.jnl
*.signed
*.signed.jnl
If not, what do I need to do?
On 8/1/13 10:48 PM, rams wrote:
Thanks david,
This the response i get
dig +short rs.dns-oarc.net http://rs.dns-oarc.net txt @forwarderip
rst.x3827.rs.dns-oarc.net http://rst.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net http://rst.x3837.x3827.rs.dns-oarc.net.
On 7/24/13 2:29 AM, Stephane Bortzmeyer wrote:
I'm trying auto-dnssec maintain; with a BIND 9.9.3-P1. My
configuration is:
options {
directory /tmp/bind;
key-directory /tmp/bind;
Not sure if this is the problem, but have you tried with
managed-keys-directory in options
FreeBSD 9.1-RELEASE-p4, BIND 9.9.3-P1 ESV installed from ports
What are the correct directory and file permissions for DNSSEC static
zone signing with bind?
By default, everything in /var/named/etc/namedb is owned by bind except
for the master directory. For example:
drwxr-xr-x bind wheel
On 7/23/13 3:44 PM, Mark Andrews wrote:
In message 51ef00af.4090...@networktest.com, David Newman writes:
FreeBSD 9.1-RELEASE-p4, BIND 9.9.3-P1 ESV installed from ports
What are the correct directory and file permissions for DNSSEC static
zone signing with bind?
By default, everything
37 matches
Mail list logo
