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
CH NS id.server.
Other queries, like authors.bind, hostname.bind, version.bind, seem to
work fine.
--
Marco Davids
Research Engineer
SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM
T +31 (0)26 352 55 00 | www.sidnlabs.nl | Twitter: @marcodavids
https://mastodo
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 un
+multi
-t
It serves me well, mostly. Sometimes it bites me as well.
In general I'm happy with it.
Best regards,
--
Marco Davids
Research Engineer
SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM
T +31 (0)26 352 55 00 | www.sidnlabs.nl | Twitter: @marcodavids
https://masto
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 https://lists.isc.org/mailma
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 unsubsc
A TXT _dmarc.domain.tld "v=DMARC1; p=reject" might also be useful.
--
Marco
On 19/08/2019 23:31, Kevin Darcy wrote:
> [ Classification Level: PUBLIC ]
>
> MXes are for *receiving* mail of course. The request is about *sending*
> mail.
>
> Setting the SPF record to "-all" is probably about the b
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 https://lists.isc.org/
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 beha
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 : No DNSKEY record from 203.0.113.5 for key example.nl.nl. while building
chain o
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 vi
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
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-netdev&m=139352943109400&w=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 should
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
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/)
Thanks.
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 pre
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 i
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 03/0
Hello Gaurav,
You might want to have a look at our whitepaper on 'authenticated denial
of existence' to gain better understanding of this somewhat complicated
aspect of the DNSSEC specification:
https://www.sidn.nl/fileadmin/docs/PDF-files_UK/wp-2011-0x01-v2.pdf
Regards,
--
Marco
On 02/14/20
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 p
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
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
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
On 07/13/10 23:58, 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'm using 9.7.1-P1 with dlv and I'm not seeing the AD flag on that. What
> version of BIND are you using?
>
Hi Doug,
I use BIND 9.7.0rc1,
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
7;proc'-directory in your chroot jail.
Something like:
mkdir /chroot/bind/proc
mount --bind /proc /chroot/bind/proc
and then in your /etc/fstab add something like this:
/proc /chroot/bind/proc none bind,ro 0 0
Regards,
--
Marco Davids
Technical Advisor
SIDN
__
while BIND 9.7.x returns a SERVFAIL.
dig +trace www.airfrance.fr works as expected.
logging says:
lame-servers: info: lame server resolving 'www.airfrance.fr' (in
'www.airfrance.fr'?): 193.57.219.253#53
Thank you.
Regards,
--
Marco Davids
___
On 12-23-2009 15:33, Marco Davids wrote:
>>> It seems as if my 'dnssec-signzone' runs on one CPU-core only, where as
>>> I would have expected it to run on all four.
>>
>> dnssec-signzone first does a lot of preprocessing on one core, before
>> it f
Op 23-12-2009 15:14, schreef Paul Wouters:
> On Wed, 23 Dec 2009, Marco Davids wrote:
>
>> It seems as if my 'dnssec-signzone' runs on one CPU-core only, where as
>> I would have expected it to run on all four.
>
> dnssec-signzone first does a lot of prep
I tried 'configure' with and without '--enable-threads', but there is no
notable difference.
I also tried 'dnssec-signzone' with and without the '-n' option. No
difference either.
Can anyone point me in the right direction please?
Thank you so much.
--
Ma
projects/ldns/
(sorry, for being a bit off-topic here)
Regards,
--
Marco Davids
SIDN
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
34 matches
Mail list logo
