On 12/6/24 21:46, Mark Andrews wrote:
Have you read the fine documentation on BIND where it is stated this is not
(currently) possible?
If you want to extend named to support this we would be happy to review a
change request. It is complicated however which is why it has not been done.
Oh,
Have you read the fine documentation on BIND where it is stated this is not
(currently) possible?
If you want to extend named to support this we would be happy to review a
change request. It is complicated however which is why it has not been done.
--
Mark Andrews
> On 13 Jun 2024, at
Excellent, thanks, looks like that very well covers it (and also the
"insecure" policy too).
And
https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/9092/diffs
looks good ... including Suzanne Goldlust's additional suggestions too.
Thanks!
On Fri, Jun 7, 2024 at 1:08 AM Petr Špaček
Thanks everyone for your responses. Obviously I overlooked the most
simple explanation, which turned out to be what actually occurred. In
hindsight, I should have checked the mailing list archive before
assuming that there was something more sinister going on. FYI Here is
the original email on
Hi there,
On Fri, 7 Jun 2024, Marco Moock wrote:
Am 07.06.2024 um 10:58:27 Uhr schrieb G.W. Haywood:
> On the face of your description, this sounds like a spammer who has
> slightly more skill than usual.
The spammer simply used the name in From: after the Nick posted tothe
list) (Nick Tait
Am 2024-06-06 18:35, schrieb Matus UHLAR - fantomas:
if the problem happens again, you can call 'rndc dumpdb' to dump
named's cache and see all records your named remembers about
mallorcazeitung.es and epi.es
perhaps they can help to explain why named can't resolve anything.
Yes, it always
I got one of those mails too, your explanation is correct. Nothing sofisticated
here.
--
Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
> On 7 Jun 2024, at 12.11, Marco Moock wrote:
>
> Am 07.06.2024 um 10:58:27 Uhr schrieb G.W. Haywood:
>
>>
Am 07.06.2024 um 10:58:27 Uhr schrieb G.W. Haywood:
> On the face of your description, this sounds like a spammer who has
> slightly more skill than usual.
The spammer simply used the name in From: after the Nick posted tothe
list) (Nick Tait via bind-users) and the mail address
Hi there,
On Fri, 7 Jun 2024, Nick Tait wrote:
... Happy to share all the mail headers ...
On the face of your description, this sounds like a spammer who has
slightly more skill than usual. Another explanation is that you might
have been targeted specifically, which could be more worrying.
Hello,
and thank you for reaching out. I agree this was poorly documented.
In recent versions you can use command `named -C` which prints out
default configuration, including the default DNSSEC policy.
I'm going to update documentation to reflect that:
Hi Nick,
I did put the user who sent the message on the moderation queue.
Ondřej
--
Ondřej Surý (He/Him)
ond...@isc.org
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
--
Visit
Hi list.
I received the email below, which on the face of it looks pretty bogus
(especially since this supposed 'list' email is personalised with my
name). But the message headers show that this email was relayed to my MX
server from the same MTA that relays legitimate emails from the
Gs will
be ignored.
> A side not on a complication of choosing an algorithm. BIND s/w developers
> have focused more on automatic-everything, so if you don't want to be
> involved in choosing anything, BIND will take care of everything. For those
> of us that want BIND to m
Ah, thanks!
Yeah, that's what I was looking to find:
https://github.com/isc-projects/bind9/blob/main/doc/misc/dnssec-policy.default.conf
https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/misc/dnssec-policy.default.conf
Alas, not in the ISC distribution tarballs,
and the documentation
Am 2024-06-04 15:28, schrieb Greg Choules:
Firstly, I doubt you actually need to kill and restart `named`.
Flushing the cache would probably work, either all of it or just
selected names.
Secondly, take a packet capture of this happening and analyse what
BIND is really doing, in Wireshark.
- If
an algorithm. BIND s/w
developers have focused more on automatic-everything, so if you don't
want to be involved in choosing anything, BIND will take care of
everything. For those of us that want BIND to maintain re-signing RRs
automatically ala version 9.16 but don't want the expanded automatic
Link for the Debian packaged version you mentioned is at
https://bind9.readthedocs.io/en/v9.18.24/reference.html#namedconf-statement-dnssec-policy
On Thu, Jun 6, 2024 at 9:31 AM Andrew Latham wrote:
> I took a quick look
>
> *
>
I took a quick look
*
https://github.com/isc-projects/bind9/blob/main/doc/misc/dnssec-policy.default.conf
*
https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/misc/dnssec-policy.default.conf
On Thu, Jun 6, 2024 at 8:19 AM Michael Paoli via bind-users <
bind-users@lists.isc.org> wrote:
>
you just want ‘port 53’. src throws away half of the transaction.
> On 5 Jun 2024, at 07:32, Michael Batchelder wrote:
>
> Thomas,
>
> I just incorrectly wrote:
>
> > So at minimum add "icmp and arp" to your filter expression.
>
> I did not mean to use the logical "and". Your minimum filter
Hello!
Am 2024-06-04 15:28, schrieb Greg Choules:
Hi Thomas.
Firstly, I doubt you actually need to kill and restart `named`.
Flushing the cache would probably work, either all of it or just
selected names.
Secondly, take a packet capture of this happening and analyse what
BIND is really doing,
Hi Thomas.
Firstly, I doubt you actually need to kill and restart `named`. Flushing
the cache would probably work, either all of it or just selected names.
Secondly, take a packet capture of this happening and analyse what BIND is
really doing, in Wireshark.
- If it shows up that certain NS are
Am 2024-06-04 09:50, schrieb Matus UHLAR - fantomas:
On 03.06.24 18:46, Thomas Barth via bind-users wrote:
Should I perhaps ask the mail user to unsubscribe from this website
due to troubles of bad configuration?
yeah I guess you should, their DNS servers are pretty much messed up:
A
On 03.06.24 18:46, Thomas Barth via bind-users wrote:
I cannot send them an email to inform about a dns problem. The mail
gets stuck in the queue.
postqueue -p
(Host or domain name not found. Name service error for name=mx.renr.es
type=A: Host not found, try again)
On 4/06/2024 12:44 am, Thomas Barth via bind-users wrote:
unfortunately, today I had to restart bind9 for the third time in an
attempt to send a newsletter to get rid the communication error,
although with a query response of 1800 msecs. Is it possible to
configure bind9 so that a public DNS
Could you send the email from another account (which doesn't use your DNS
server)? It's not too hard to set up a free account with services like Outlook,
Yahoo or (if desperate) Gmail.
On Mon, 03 Jun 2024 18:46:40 +0200
Thomas Barth via bind-users wrote:
> Hello,
>
> I cannot send them an
Hello,
I cannot send them an email to inform about a dns problem. The mail gets
stuck in the queue.
postqueue -p
(Host or domain name not found. Name service error for name=mx.renr.es
type=A: Host not found, try again)
r...@mallorcazeitung.es
Bind
Hello,
unfortunately, today I had to restart bind9 for the third time in an
attempt to send a newsletter to get rid the communication error,
although with a query response of 1800 msecs. Is it possible to
configure bind9 so that a public DNS service (e.g. 9.9.9.9) is used for
the particular
Hi Philip,
we'll need more. Ideally fill an issue, follow the bug template and attach
config.log as a bare minimum.
--
Ondřej Surý — ISC (He/Him)
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
> On 1. 6. 2024,
Am 2024-06-01 12:18, schrieb Rainer Duffner:
intodns.com [1] [1]
They have to fix this first, IMHO.
And that doesn’t take into account the problems found by zonemaster.
Zonemaster [2]
zonemaster.net [2] [2]
I wrote to the website, drew their attention to the problem
https://intodns.com/mallorcazeitung.es
They have to fix this first, IMHO.
And that doesn’t take into account the problems found by zonemaster.
https://zonemaster.net/en/result/1041e4ac095c7018
> Am 01.06.2024 um 12:08 schrieb Thomas Barth via bind-users
> :
>
> Am 2024-06-01 04:34,
Am 2024-06-01 04:34, schrieb Michael Batchelder:
Thomas, can you clarify whether all queries to 127.0.0.1/53 result in:
;; communications error to 127.0.0.1#53: timed out
when this problem occurs, or do just queries for
s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es fail (or some level
of
> I use bind9 on my mail server so that Spamassassin can perform the
> necessary DNS blocklist queries. Since it has already happened several
> times that I have to restart bind9 so that a certain domain can still
> be resolved, I wanted to ask if anyone knows where I have to set
> something.
>
>
Sorry did not spend too much time thinking about this but if you are checking
DKIM should that be a TXT query instead of an A record?
John
-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Thomas
Barth via bind-users
Sent: Friday, May 31, 2024
Hi Thomas,
here were results of my local testing. Very quick. Not sure why it is
so slow for you but then I don't know where you are in the world
either. As for why the discrepancy in response times when you restart
BIND, I don't know what that could be
dig mallorcazeitung.es in ns
; <<>>
Am 30.05.2024 um 00:47:56 Uhr schrieb Peter:
> On Wed, May 29, 2024 at 12:20:09PM +0200, Matus UHLAR - fantomas
> wrote: ! > On Tue, May 28, 2024 at 09:09:20PM +0200, Marco Moock
> wrote: ! > > rinetd manages 2 separate connections and should work
> with PMTUD. !
> ! On 28.05.24 22:17, Peter
On Wed, May 29, 2024 at 12:20:09PM +0200, Matus UHLAR - fantomas wrote:
! > On Tue, May 28, 2024 at 09:09:20PM +0200, Marco Moock wrote:
! > > rinetd manages 2 separate connections and should work with PMTUD.
!
! On 28.05.24 22:17, Peter wrote:
! > I'm wondering how it would. The connections are
Hi Brian.
We're going to need some details please, like for starters:
- What's the domain being queried?
- A network diagram showing where your BIND server is and what it's
forwarding to.
- IP addresses of everything.
- A packet capture (binary pcap format, not a snippet or a screenshot) from
your
On 29. 05. 24 11:31, adrien sipasseuth wrote:
Only if KSK has DSState: rumoured. If the DSState is hidden it means
that it is not expected to be in the parent (for example because the
DNSKEY has not yet been fully propagated).
> Do you need to withdraw the old key too immediatly ? anything
On Tue, May 28, 2024 at 09:09:20PM +0200, Marco Moock wrote:
rinetd manages 2 separate connections and should work with PMTUD.
On 28.05.24 22:17, Peter wrote:
I'm wondering how it would. The connections are TCP, the PMTU works
via ICMP6.
No, Path MTU discovery works with TCPv4 using ICMPv4
Only if KSK has DSState: rumoured. If the DSState is hidden it means
that it is not expected to be in the parent (for example because the
DNSKEY has not yet been fully propagated).
> Do you need to withdraw the old key too immediatly ? anything else to do ?
>>> Do you mean withdraw the old DS?
In the dnssec.log file I only found references to normal key rotation.
Adding the section for update_security and running at trace 99 didn't
provide _any_ update_security log output, nor did it provide any extra
output to the update log.
even when running in single combined log format I
On Tue, May 28, 2024 at 09:09:20PM +0200, Marco Moock wrote:
> Am 28.05.2024 um 18:48:38 Uhr schrieb Peter:
>
> > On Tue, May 28, 2024 at 12:25:03PM +0200, Marco Moock wrote:
>
> > > > Now we add an IPv6 address for 'myhost'. But portforwarding
> > > > doesn't work for IPv6. Instead we are
Am 28.05.2024 um 18:48:38 Uhr schrieb Peter:
> On Tue, May 28, 2024 at 12:25:03PM +0200, Marco Moock wrote:
> ! > Now we add an IPv6 address for 'myhost'. But portforwarding
> ! > doesn't work for IPv6. Instead we are required to use different
> ! > addresses all over, like so:
> !
> ! port
On Tue, May 28, 2024 at 12:25:03PM +0200, Marco Moock wrote:
! Am 28.05.2024 um 12:00:09 Uhr schrieb Peter:
!
! > if I understand corrently, the use of CNAME is just a convenience
! > and no technical feature, right?
!
! It is technical because the query is redirected to the domain listed in
!
Am 28.05.2024 um 12:00:09 Uhr schrieb Peter:
> if I understand corrently, the use of CNAME is just a convenience
> and no technical feature, right?
It is technical because the query is redirected to the domain listed in
the CNAME.
> In lots of examples on the net, a zonefile for a domain
Please allow me to refocus this thread to the original question.
I'm asking about the logging facility with respect to the "update"
section of code in ISC's bind9 product.
Yes, I understand update-policy choices/errors will generate the REFUSED
response.
_I'm only asking about the logging
> On 27 May 2024, at 16:06, Erik Edwards via bind-users
> wrote:
>
> Hello Mark & List,
>
> Thank you for responding, I'm running bind-9.18.26-1.fc40.x86_64 and using
> nsupdate 9.16.27-Debian to send the updates, using rndc Version: 9.18.26.
>
> I'm issuing commands through rndc to set the
Hello Mark & List,
Thank you for responding, I'm running bind-9.18.26-1.fc40.x86_64 and
using nsupdate 9.16.27-Debian to send the updates, using rndc Version:
9.18.26.
I'm issuing commands through rndc to set the trace level to 99 -> "rndc
trace 99". rndc seems to work correctly in all
Start from the beginning.
Show the actual configuration (named.conf, K* files, etc.). X out the secret
keys.
Show the actual commands you are running.
Show the actual logs being produced. REFUSED can come from lots of things.
Named emits log messages for almost all of them without needing to
On 2024-05-17 19:37, Nick Tait via bind-users wrote:
On 18/05/2024 09:11, J Doe wrote:
Hello,
When using RPZ with BIND 9.18.27 and rpz-ip, can any CIDR prefix be used
or must they be either: /8, /16, /24, /32 for IPv4 ?
For example, if I want to block records with an A address of
algorithm hmac-sha256;
named-checkconf -p shows the key with the matching name, algo, and secret.
When I mis-configure, change, or typo the secret it returns "BAD SECRET"
The error I'm seeing is "REFUSED" on a config that worked until the upgrade.
It worked on F36-F39, upgrades were seamless.
It doesn't answer your original question, but I suggest looking at the
'algorithm' of that key.
Might it be a hmac-md5 ?
If you 'named-conf -px' does it appear in the list of keys?
--
Do things because you should, not just because you can.
John Thurston907-465-8591
> this has been planned, but unfortunately other stuff got into the way.
>
> It is still on our roadmap though.
OK, thanks, it's reassuring that I hadn't overlooked something
this time around, and it's good to see it's already thought about
and on your roadmap. It's also on my wishlist, FWIW. :)
Hi Havard,
this has been planned, but unfortunately other stuff got into the way.
It is still on our roadmap though.
Ondřej
--
Ondřej Surý (He/Him)
ond...@isc.org
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
-users mailto:bind-users@lists.isc.org>>
> Sent: Wednesday, May 22, 2024 11:47 AM
> To: don.frie...@gov.bc.ca <mailto:don.frie...@gov.bc.ca>
> mailto:don.frie...@gov.bc.ca>>
> Cc: ond...@isc.org <mailto:ond...@isc.org> <mailto:ond...@isc.org>>; bind-u
> I frontend DoH and DoT traffic with nginx and use that for
> analytics/statistics.
Thanks, but I think that violates the KISS principle.
Regards,
- Håvard
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software
-users@lists.isc.org
Subject: Re: Make dig and nslookup DNSSEC aware?
This email originated from outside of TESLA
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
> Doesn't dig already offer DoT using +tls and DoH using +https?
You're right
I frontend DoH and DoT traffic with nginx and use that for
analytics/statistics.
Cheers,
David
On Wed, May 22, 2024 at 11:08 AM Havard Eidnes via bind-users <
bind-users@lists.isc.org> wrote:
> Hi,
>
> I recently had reason to enable BIND 9.18.27 to do DoT and DoH
> (done via unbound earlier),
> Doesn't dig already offer DoT using +tls and DoH using +https?
You're right, it does.
I need to sort out my $PATH...
Regards,
- Håvard
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support
Doesn't dig already offer DoT using +tls and DoH using +https ?
Don Friesen
-Original Message-
From: bind-users On Behalf Of Ondrej Surý
Sent: Wednesday, May 22, 2024 8:09 AM
To: Havard Eidnes
Cc: bind-users@lists.isc.org
Subject: Re: Make dig and nslookup DNSSEC aware?
[EXTERNAL
forget about nslookup. deprecated in my mind. use dig like so:
for DoT:
$dig @1.1.1.1 -tA +dnssec +tls www.google.com
for Doh:
dig @1.1.1.1 -ta +https +dnssec www.google.com
Make sure you have a more recent version of dig to supports this.
If you need programmatic DNSSEC access use a library
> On 22. 5. 2024, at 17:02, Havard Eidnes via bind-users
> wrote:
>
> And, no, I'm not aware of any such plans to incorporate a DNSSEC
> validator in any of those tools. Not sure it makes technical
> sense, as it's a fairly large task. That's what a validating
> recursive resolver does; watch
>> Sorry if this has already been hashed through, but I cannot
>> find anything in the archive. Is there any chance someone can
>> make dig and nslookup DNSSEC aware and force it to use DoT or
>> DoH ports - TCP 443 or 853 only?
>
> Not sure about that. However, the "kdig" utility from the
> Sorry if this has already been hashed through, but I cannot
> find anything in the archive. Is there any chance someone can
> make dig and nslookup DNSSEC aware and force it to use DoT or
> DoH ports - TCP 443 or 853 only?
Not sure about that. However, the "kdig" utility from the "knot"
name
.
From: bind-users On Behalf Of John Thurston
Sent: Tuesday, May 21, 2024 2:15 PM
To: bind-users@lists.isc.org
Subject: Re: named fails to start with bind-9.18.0
ATTENTION: This email came from an external source. Do not open attachments or
click on links from unknown senders or unexpected emails
Assurance you are actually trying to compile current code.
A statement of what your operating system is.
Actual output of your compile steps.
Actual logged output of your attempt to launch.
--
Do things because you should, not just because you can.
John Thurston907-465-8591
As Ondrej said. Upgrade. You compiled BIND 9.18.0. That is 27 release behind
current. Unless you are doing archaeological investigations of old code you
shouldn’t be trying to use old code like that. Running newer code means that
you can avoid all the bugs that have been fixed in the
My Apologies. I was just trying to show the snippet of bind library code
where named was failing.
I am trying to run named after compiling the bind library. The command I
use to run named is as follows:
/bin/named -c /etc/named.conf
It appears that it is failing when it tries to daemonize
And named already handles ANY being used as an reflection amplifier.
This was written for servers using databases where getting the ANY response is
actually hard. Cloudflare was using a response model that most thought was not
really correct but wasn’t broken enough to say “Don’t do that”. If
> Can someone please help what could be the issue here?
Not really. First start by using the latest 9.18 version and not something
that’s two years old and then you need to provide more information than a
screenshot of random code snippet. If you want free help you need to provide
information
I would suggest you to create a feature request in our GitLab. This way it
won't get lost
in the tides of time.
Personally, I actually quite like the idea, but it would have to be an option
to turn off and on,
so it's not going to save us from having a code that supports ANY anyway.
Ondřej
--
Named does not support this. There is no requirement to support this.
--
Mark Andrews
> On 21 May 2024, at 00:04, Amaury Van Pevenaeyge
> wrote:
>
>
> Hello everyone,
>
> How is it possible to set up a resource record of type HINFO so that it is
> returned on every ANY request without
On 18.05.24 07:10, Mark Andrews wrote:
Correct. Later versions use NS queries as that allows named to cache the
non-existence of the NS RRset.
I see this happened since 9.18.17
Luckily Debian 11/backports and Debian 12 have incorporated this version.
Using _.domain doesn’t allow that to
> On 20 May 2024, at 07:37, J Doe wrote:
>
> Hi list,
>
> I run a validating recursive resolver with BIND 9.18.27. Over the
> course of many days, I have noted the following warning about a missing
> cookie from a particular server:
>
>09-May-2024 20:09:22.277 resolver: info: missing
On 18/05/2024 09:11, J Doe wrote:
Hello,
When using RPZ with BIND 9.18.27 and rpz-ip, can any CIDR prefix be used
or must they be either: /8, /16, /24, /32 for IPv4 ?
For example, if I want to block records with an A address of
192.168.10.1, I know I can write:
32.1.10.168.192.rpz-ip
Correct. Later versions use NS queries as that allows named to cache the
non-existence of the NS RRset. Using _.domain doesn’t allow that to happen.
NS queries do however expose broken delegations. Make sure you have working NS
records at the zone apex and at the delegation point. This is
On Fri, May 17, 2024 at 03:25:01PM +0200,
Matus UHLAR - fantomas wrote
a message of 43 lines which said:
> I have noticed that BIND sends strange (for me) queries.
>
> 5 0.198221 192.168.0.1 → 193.108.88.128 DNS 105 Standard query 0x15a4 A
> _.net.akadns.net OPT
QNAME minimisation
Hi,
On 5/16/24 14:02, adrien sipasseuth wrote:
Hello,
I try to set up a testing environment in order to create some scripts
for automated the roll over KSK.
# question 1 #
this is my policy :
dnssec-policy "test" {
keys {
ksk lifetime P3D algorithm
a generic target for all subdomains as each entity
> has its own target for SRV entries.
>
> -Message d'origine-
>
> De : bind-users bind-users-boun...@lists.isc.org De la part de Matus
> UHLAR - fantoms
> Envoyé : mardi 14 mai 2024 15:58
> À : bind-users@lists
-users-boun...@lists.isc.org De la part de Matus
UHLAR - fantoms
Envoyé : mardi 14 mai 2024 15:58
À : bind-users@lists.isc.org
Objet : Re: SRV on multiple subdomains
On 14.05.24 13:08, DEMBLANS Mathieu wrote:
I have a question about configuration simplification for SRV
configuration (maybe it can
On 15. 05. 24 17:21, Peter Carlson wrote:
As I understand it bind_dlz does not support multiple views, I have to
following scenario and am trying to figure out how to configure it:
* Internal (192.168.10.0/24)
o resolve internal domain xyz.com
o resolve internal samba domain
.example.com.
Simply, wildcarding is not for case like this.
-Message d'origine-
De : bind-users De la part de Matus UHLAR -
fantomas
Envoyé : mardi 14 mai 2024 15:58
À : bind-users@lists.isc.org
Objet : Re: SRV on multiple subdomains
On 14.05.24 13:08, DEMBLANS Mathieu wrote:
I have
> On 15 May 2024, at 04:34, John Thurston wrote:
>
> There are several 'special-use' domain names I'm pondering
> • invalid.
> • test.
> • onion.
> My read of the RFCs indicate they should result in NXDOMAIN, and not be
> passed for resolution.
> RFC 6761 (test. Section 6.2.4 /
On Tue, May 14, 2024 at 2:34 PM John Thurston wrote:
>
> There are several 'special-use' domain names I'm pondering
>
> invalid.
> test.
> onion.
>
> My read of the RFCs indicate they should result in NXDOMAIN, and not be
> passed for resolution.
>
> RFC 6761 (test. Section 6.2.4 / invalid.
2024 15:58
À : bind-users@lists.isc.org
Objet : Re: SRV on multiple subdomains
On 14.05.24 13:08, DEMBLANS Mathieu wrote:
>I have a question about configuration simplification for SRV configuration
>(maybe it can be applyed for other entries).
>
>We manage multiple subdomain o
Le 14/05/2024 à 15:08, DEMBLANS Mathieu a écrit :
Hello,
I have a question about configuration simplification for SRV
configuration (maybe it can be applyed for other entries).
We manage multiple subdomain of a main one (server1.example.com,
server2.example.com,…).
For A and MX entries,
On 14.05.24 13:08, DEMBLANS Mathieu wrote:
I have a question about configuration simplification for SRV configuration
(maybe it can be applyed for other entries).
We manage multiple subdomain of a main one (server1.example.com,
server2.example.com,...).
For A and MX entries, we use a general
On 2024-05-05 20:47, Mark Andrews wrote:
On 6 May 2024, at 07:38, J Doe wrote:
Hello,
I run BIND 9.18.26 as a recursive, validating resolver. In my logs, I
noticed the following:
01-May-2024 00:52:49.689 lame-servers: info: truncated TCP response
resolving
every one else who is using the COPR distribution, and package updates
to the base can happen without affecting the installation you care
about. If some update to base does re-enable it, it will behave
substantially differently from your real installation, and you will
notice it.
--
Do
> On 6 May 2024, at 07:38, J Doe wrote:
>
> Hello,
>
> I run BIND 9.18.26 as a recursive, validating resolver. In my logs, I
> noticed the following:
>
>01-May-2024 00:52:49.689 lame-servers: info: truncated TCP response
>resolving 'www.ipfire.org/A/IN': 74.113.60.134#53
>
> I
I used these symlinks to transition from RHEL standard 9.16 to COPR 9.18
ln -s /var/opt/isc/scls/isc-bind/named /var/named
ln -s /etc/opt/isc/scls/isc-bind/named.conf /etc/named.conf
ln -s /var/opt/isc/scls/isc-bind/run/named /run/named
ln -s /opt/isc/isc-bind/root/usr/sbin/rndc /usr/sbin/rndc
On Sun, May 05, 2024 at 06:15:13PM +0200, Luca vom Bruch via bind-users wrote:
! Hello,
!
! I use bind (stock from alma 9.3) as a nameserver for a webhosting server
! with webmin/virtualmin.
!
! If I install BIND via copr (RHEL9 and derivatives only offer 9.16 instead of
! 9.18 - I want to
> On 1 May 2024, at 22:25, Walter H. via bind-users
> wrote:
>
> On 01.05.2024 01:33, Mark Andrews wrote:
>>
>>> On 1 May 2024, at 03:32, Lee wrote:
>>>
>>> On Mon, Apr 29, 2024 at 11:40 PM Walter H. wrote:
On 29.04.2024 22:19, Lee wrote:
> On Sun, Apr 28, 2024 at 2:18 AM Walter
On 01.05.2024 01:33, Mark Andrews wrote:
On 1 May 2024, at 03:32, Lee wrote:
On Mon, Apr 29, 2024 at 11:40 PM Walter H. wrote:
On 29.04.2024 22:19, Lee wrote:
On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users
wrote:
something that I replied to and got this in response:
Error Icon
> On 1 May 2024, at 03:32, Lee wrote:
>
> On Mon, Apr 29, 2024 at 11:40 PM Walter H. wrote:
>>
>> On 29.04.2024 22:19, Lee wrote:
>>> On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users
>>> wrote:
>>>
>>> something that I replied to and got this in response:
>>>
>>> Error Icon
>>>
On Tue, Apr 30, 2024 at 2:40 AM Mark Andrews wrote:
>
> And it has been fixed.
Yay! No more error messages in the log because of them :-)
Thanks for your help
Lee
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this
On Mon, Apr 29, 2024 at 11:40 PM Walter H. wrote:
>
> On 29.04.2024 22:19, Lee wrote:
> > On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users
> > wrote:
> >
> > something that I replied to and got this in response:
> >
> > Error Icon
> > Message blocked
> > Your message to
> BIND 9.18.18-0ubuntu0.22.04.2-Ubuntu (Extended Support Version)
I would start here - ISC provides packages for RedHat, Fedora, Debian and
Ubuntu with latest upstream version.
There's little point in debugging a version that's old and doesn't contain all
the bugfixes.
If you can reproduce
And it has been fixed.
% dig dnssec-analyzer.verisignlabs.com
;; BADCOOKIE, retrying.
; <<>> DiG 9.19.24-dev <<>> dnssec-analyzer.verisignlabs.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9048
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1,
> On 30 Apr 2024, at 13:39, Walter H. via bind-users
> wrote:
>
> On 29.04.2024 22:19, Lee wrote:
>> On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users
>> wrote:
>>
>> something that I replied to and got this in response:
>>
>> Error Icon
>> Message blocked
>> Your message to
1 - 100 of 24530 matches
Mail list logo
