Solved by adding 'server-id' to named.conf.options.
Thank you Petr Špaček for the suggestion.
Op 14/02/2024 om 10:23 schreef Marco Davids (SIDN):
I have upgraded two servers to 9.18.24 and the funny thing is that on
one server id.servers works well:
;; ANSWER SECTION:
id.server. 0
I have upgraded two servers to 9.18.24 and the funny thing is that on
one server id.servers works well:
;; ANSWER SECTION:
id.server. 0 CH TXT "one"
And on the other it does not:
;; AUTHORITY SECTION:
id.server. 86400 CH SOA id.server. hostmaster.id.server. 0
Hi,
How hard would it be to let named-compilezone keep any remarks that are
present in the source file? Because now it strips them and that is
problematic.
--
Marco
OpenPGP_signature.asc
Description: OpenPGP digital signature
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to
Hi Anand,
Op 22-09-2023 om 14:46 schreef Anand Buddhdev:
Do you think that dig should be adjusted to suppress cryptographic
material from other records such as TLSA, SSHFP, CDNSKEY, CDS, etc, and
the man page updated to reflect this?
Great discussion! I don't have any strong opinions just
So, I was trying to enforce a GET with DiG 9.18.1, but according to the
pcap it is still a POST.
I did this:
dig +http-plain-get @doh.example.nl TXT example.com
What am I doing wrong?
--
Marco
smime.p7s
Description: S/MIME-cryptografische ondertekening
--
Visit
It stops with messages such as:
../../bin/delv/delv.rst:109:unknown option: +root
Is this a known issue already?
It compiled fine on a newer Ubuntu 22.04.
--
Marco
OpenPGP_signature
Description: OpenPGP digital signature
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to
Hi,
Not sure if this has been proposed before, but I am wondering:
Has ISC ever considered to change the default 'dig -t' option from A to
?
--
Marco
signature.asc
Description: OpenPGP digital signature
___
Please visit
On 20/10/2016 14:41, Marco Davids (SIDN) wrote:
> For testing-purposes I tried to simulate the situation in sidnlabs.nl:
>
> dig +dnssec -t ANY _sidn._dnssec-valcheck._1804289384.sidnlabs.nl
ERROR!
That should be:
dig +dnssec -t ANY _sidn._dnssec-valcheck._1804289384.dname.si
Hi,
I noticed some inconsistent behavior in a particular setup where a DNAME
is involved and I am trying to figure out who is right and who is wrong.
Players involved on the resolving side are:
Google Public DNS (resolves without an error)
BIND (often results in a timeout and a log-rule saying:
On 07/08/15 02:03, Charles Swiger wrote:
So ISC: please fix your list servers, let them rewrite the From headers!
How would this help? Changing the From header breaks your domain's DKIM
signing; are you asking them to take ownership of your messages and then DKIM
sign
them on behalf of
Hi,
What would be a good way to configure BIND-logging, or rather to filter
DNSSEC-validation errors from that logging?
Unbound logs stuff like this:
Mar 5 12:58:47 xs unbound: [16331:0] info: validation failure example.nl. A
IN: No DNSKEY record from 203.0.113.5 for key example.nl.nl. while
Darcy Kevin (FCA) schreef op 06-01-15 om 19:56:
This nameserver is forwarding to 208.67.222.222 and 208.67.220.220. Are those
valid and working?
OpenDNS, right?
--
Marco
smime.p7s
Description: S/MIME-cryptografische ondertekening
___
Please
On 21-03-14 14:03, Casey Deccio wrote:
I've adopted a number of zones and most of them contain localhost in
a 127.0.0.1 records. I'm curious what current RFC standards state and
what the community considers best practice.
I would take a look at the query logs for the zones in
On 05/03/14 15:15, Klaus Darilion wrote:
Does it only happen for IPv6 DNS requests? Maybe it is related to this:
https://open.nlnetlabs.nl/pipermail/nsd-users/2014-January/001783.html
Or, less likely, this:
http://marc.info/?l=linux-netdevm=139352943109400w=2
--
Marco
dig ANY example.org @..
Google Public DNS:
--
returns DS: no
BIND 9.9.3-P2:
--
returns DS: yes
Unbound 1.4.20:
---
returns DS: no
Personally I don't care much, but perhaps someone on this list has a
strong opinion about these differences that I
Hi Jaap,
On 05/06/13 16:09, Jaap Winius wrote:
2.) http://dnsviz.net/d/zuid.dapadam.nl/dnssec/
This shows two DS records in the parent zone, one not secure and one
bogus, and three DNSKEY records in the child zone, none of which are
secure.
Perhaps you could remove ns[12].transip.net
Hi,
Dig 9.9.1 is setting the AD-bit in queries by default.
Does anyone know why?
Took me a while to figure out, among other things because Wireshark has
a little bug that prevents the AD-bit being shown in queries.
(reported as bug 2472 and 7555 on https://bugs.wireshark.org/bugzilla/)
Hi,
It is not possible to configure NSEC3 as a default in named.conf (on a
per zone basis), is it? I would welcome such a feature.
I also find it a bit strange that BIND decides to go for NSEC, even when
the KSK and ZSK are configured with algorithm: 7 (NSEC3RSASHA1).
Thanks.
--
Marco
On
Phil,
On 03/07/12 10:27, Phil Mayers wrote:
On 03/07/2012 08:50 AM, Marco Davids (SIDN) wrote:
I also find it a bit strange that BIND decides to go for NSEC, even when
the KSK and ZSK are configured with algorithm: 7 (NSEC3RSASHA1).
AS I understand it, NSEC3 incurs overhead at validating
On 03-07-12 18:08, Evan Hunt wrote:
I also find it a bit strange that BIND decides to go for NSEC, even when
the KSK and ZSK are configured with algorithm: 7 (NSEC3RSASHA1).
There's no difference between algorithm 7 and algorithm 5 (RSASHA1).
The use of a new algorithm number for a
On 04/12/11 10:50, walter.jontofs...@t-systems.com wrote:
you could use ipv6calc (ftp://ftp.bieringer.de/pub/linux/ipv6/ipv6calc) to
calculate the reverse strings.
Yes.
Or do it 'the BIND way':
dig -x 2001:7b8:c05::80:1 | grep ip6.arpa | tail -1 | awk '{print $1}'
--
Marco
Im Auftrag
On 04/12/11 11:49, Michel de Nostredame wrote:
you could use ipv6calc (ftp://ftp.bieringer.de/pub/linux/ipv6/ipv6calc) to
calculate the reverse strings.
Yes.
Or do it 'the BIND way':
dig -x 2001:7b8:c05::80:1 | grep ip6.arpa | tail -1 | awk '{print $1}'
Beside them, is any potential
Op 10-03-11 18:26, Christian Laursen schreef:
On 03/10/11 17:05, Evan Hunt wrote:
and hadn't even given any thought to to the problem of supporting DNSSEC,
but we can add those features to the roadmap as well if there's user demand.
I just want to throw my vote for having DLZ support DNSSEC
On 07/14/10 00:43, Doug Barton wrote:
Can anyone explain to me why the 'ad'-flag is set for this query?
dig +dnssec -t RRSIG www.forfunsec.org
I use BIND 9.7.0rc1, configured to work with the IANA testbed.
I'd be interested to see what happens if you upgrade to the latest
versions in each
Hi,
Can anyone explain to me why the 'ad'-flag is set for this query?
dig +dnssec -t RRSIG www.forfunsec.org
How does a validating resolver determine that such an answer is secure?
Thank you.
--
Marco Davids
___
bind-users mailing list
Hi,
I run into an unclear situation while trying to resolve certain domains.
It happened when I tried with 9.7.0rc1, 9.7.0b and also with 9.7.0. I
dont's have a whole lot of other BIND versions at my disposal, but I
found an older one, 9.3.4-P1.2, and that one works fine.
One of the domains that
26 matches
Mail list logo
