.18 has been in use for quite a while and is still
widely used today (without such major issues), I very much doubt
your issues are caused by Bind.
Danilo
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
at with 'resolvectl dns'.
Then check what is listening on port 53 (netstat -anp | egrep
":53.*LISTEN") on the server.
And also check what DNS servers your DHCP sets.
Danilo
--
Visit https://lists.isc.org/
ssential (MX, A, ...)
records, but since a _domainkey subzone is quite specific and unlikely
to be used for anything else, this should still work, right?
Or should I consider this an absolute 'no-no' and have my 'customers'
add the complete TXT record?
Re
; QUESTION SECTION:
;send.dom24.si. IN NS
I thought that's neat and started digging (pun intended) in docs if Bind
could be configured to provide something like that (ideally just for my
'inside' view), but I couldn't find anything.
Is there a way
caused by one of the OpenSuSE package updates
(glibc, maybe?) and has probably nothing to do with Bind itself, but I
thought someone else might run into it.
Danilo
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this softwa
time: 40 msec
;; SERVER: 54.229.229.105#53(dns4.elasticbox.eu) (UDP)
;; WHEN: Fri Dec 13 15:40:38 CET 2024
;; MSG SIZE rcvd: 582
That implies that this might be a network problem, but since all servers
have a public IP and no NAT, I really cant's imagine why or how.
What diagnostic steps
If nothing else works, you can always 'include' a file that contains
configuration stanzas of those zones and then use a script to add new
zone stanzas to the file.
# Include config file with thousands of domains
include "/etc/named.d/1000s_domains.conf";
The script could either recreate the
Thanks,
now that I know what to look for, I found the docs for it.
Maybe worth mentioning that /cds-digest-types/ is not available in
9.18.x, as it has been introduced in 9.19.11.
Danilo
On 16. 10. 24 23:24, Mark Andrews wrote:
On 16 Oct 2024, at 23:00, Danilo Godec via bind
| 4 | SHA-384 | MAY | RECOMMENDED |
++-+---+---+
Are there any newer RFCs or guidelines regarding DNSSEC algorithms?
Danilo
On 16. 10. 24 14:15, Robert Wagner wrote:
Our preference would be to at least
ypes
as CDS records?
Regards,
Danilo
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mai
mber in my source text zone file still relevant? If it
is, I suppose increasing it by one is no longer good enough - I probably
need to check the actual SOA and then use that as 'base' and increase
that by 1, right?
Regards,
Danilo
On 2. 10. 24 15:13, Matthijs Mekking wro
change to sociopat.si.
Should the change be immediate or is it also TTL dependent?
Regards,
Danilo
On 2. 10. 24 13:10, Matthijs Mekking wrote:
Hi Danilo,
When you enable DNSSEC for the first time, first the DNSKEY and the
signatures need to be introduced in the zone, and propaga
exist or is
in some way different.
Regards,
Danilo
On 2. 10. 24 12:19, Greg Choules wrote:
Hi Danilo.
The CDS and CDNSKEY are published in your own zone, not anywhere else.
You can confirm this by doing a dig for them directly, or AXFR if you
permit transfers on your server.
t.si. IN DS
;; ANSWER SECTION:
psihopat.si.7200IN DS 7162 13 2
3C5A5625F848DBCF99A0B85017AFE04FD1F681037B61BE970D57AE9F 90F21CD8
Also, as far as I know, .si DNS servers don't support CDS / CDNSKEY, so
publishing them might be futile.
R
Hello,
I think
chmod ug+x /etc/bind/zonas/
should solve the issue by giving the
owner (bind) and the group (bind) permissions to enter the
directory.
Danilo
On
ds at the registrar level as they
don't provide a 'self-service' interface for managing them, so I have to
go though their support and that's usually tedious.
If that is necessary, why?
Thanks, Danilo
PS: If it matters, this is (still) a manually DNSSEC'd domain.-
em by hand.
Thanks for your thoughts,
Danilo
On 6.4.2022 13:18, Petr Menšík wrote:
Hi Danilo,
I think the way you have describe should work. But can I ask
what source this recipe has? I have see
On 6.4.2022 8:52, Daniel Stirnimann wrote:
Hello Danilo,
A simple schema to change DNSSEC algorithms is as follows:
1. Add new KSK/ZSK and double sign DNSKEY and all zone RRs
with both the new and old algorithm
2. Replace DS at parent
3. Remove old DNSKEY and all RRSIGs from the old
te remember
why, but I had two)
7. wait another TTL period
8. remove old keys from zone
9. re-sign the zone
Will that be OK?
Best regards,
Danilo
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software
bad in some way? Should I change that?
Thanks,
Danilo
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at http
On 29. 12. 21 19:24, tale wrote:
On Wed, Dec 29, 2021 at 5:31 AM Danilo Godec via bind-users
wrote:
I have an authoritative DNS server for a domain, but I was also going to
use the same server as a recursive DNS for my internal network, limiting
recursion by the IP. Apparently, this is a bad
and if someone
guessed my internal network IPs and spoofed the IP, my DNS server would
happily accept their requests? Or is it even wider than that?
Danilo
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this
urity: info: client @0x7f96180b3fe0
45.145.227.33#11092 (.): view outside: query (cache) './ANY/IN' denied
I'm guessing this is some sort of an reflection attack attempt, but I
don't quite understand if these are the perpetrators or victims?
Would I be doing a
ITY SECTION:
example.com. 600 IN SOA mydns.example.com.
hostmaster.mydns.example.com. 2020042504 86400 3600 604800 604800
;; Query time: 0 msec
;; SERVER: mydns#53(mydns)
;; WHEN: thu sep 23 13:50:00 CEST 2021
;; MSG SIZE rcvd: 100
Obviously I replaced my real domain w
.com -- invalid response
However, if I point the system resolver (or nslookup) to some other DNS
(my ISP's DNS, for examle), neither ping or nslookup fail.
Is there anything I can do on my BIND to make musl libc happy and not
fail in such a case?
k? Evan?)
I just tested it, it doesn't seem to work.
My bind version:
> BIND 9.9.5-9+deb8u6-Debian (Extended Support Version)
Best,
Danilo
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this
to get Bind to automatically include config files in a
directory? If not, might it make sense to place a feature request for
this with the Bind developers? If yes, what would the process be for
such a request? Or is there a better alternative to this approach?
Best,
Danilo
[0] https://en.wikipedi
statements in this example say that 'localhost' will use the
'localhost_resolver' and everything else will use the 'viewx' view - but
you don't have the 'domainx.zone' in your 'localhost_resolver' view.
Try adding 'include "domainx.zo
x.zones', but according to your 'cat
var/domainx.zones' it's in some 'var/' subdirectory.
Either use the full path for the include or move the domainx.zones file
into the /var/named and use a relative path from there.
Danilo
If I understand correctly, the connection between the scanner PC and
your DNS server is not really the issue here.
What can cause problems is a firewall between your DNS server and the
Internet.
Danilo
On 07/28/2011 10:08 AM, Pete Fong wrote:
Hi, Matus UHLAR
No, The scanner PC and
On 07/27/2011 10:31 AM, Stephane Bortzmeyer wrote:
On Wed, Jul 27, 2011 at 09:59:32AM +0200,
Danilo Godec wrote
a message of 247 lines which said:
Weirdness number 2 - using dig directly with their servers works:
Nothing weird here: dig does not behave like the BIND resolver. It
does not
32401 MX? rabobank.com. (30) (ttl 63, id 22317, len 58)
If I try to resolve 'rabobank.nl', I only see these packets:
09:54:40.319835 178.79.70.66.53 > 193.78.240.1.53: [udp sum ok] 31758
[1au] MX? rabobank.nl. ar: . OPT UDPsize=512 (40) (ttl 63, id 3129,
len 68)
09:54:40.353814
32 matches
Mail list logo
