Fred,
Most of the details are in RFC 2308 (Negative Caching of DNS Queries).
On Sat, Apr 6, 2024 at 9:16 AM Fred Morris wrote:
> So the answer is in two parts.
>
> 1) An SOA record is required in the AUTHORITY section. The TTL on the
> negative answer is established by the TTL on this record.
>
On Thu, Jul 9, 2020 at 6:44 AM Daniel Stirnimann <
daniel.stirnim...@switch.ch> wrote:
>
> On 09.07.20 11:51, Klaus Darilion wrote:
> >>> So, how is the correct process to add an additional DNSKEY (only the
> public
> >> key is known).
> >>
> >> I think you are looking for `dnssec-importkey`.
> >
ne), I
assume you can stitch together the DNSKEY RRset with the imported ZSK
manually or with some scripting.
Shumon Huque
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of t
On Tue, Jul 7, 2020 at 2:21 PM Brett Delmage wrote:
> On Tue, 7 Jul 2020, Tony Finch wrote:
>
> > Reduce the size of responses to ANY queries, which are a favourite tool
> of
> > amplification attacks. There's basically no downside to this one, in my
> > opinion, but I'm biased because I implemen
Update: I've now filed this bug/issue:
https://gitlab.isc.org/isc-projects/bind9/-/issues/1745
On Tue, Apr 7, 2020 at 8:11 AM Shumon Huque wrote:
> Hi folks,
>
> I thought I'd check here before filing a bug in the gitlab repo -- in case
> there is something I
ms
The last response is above is a referral, but dig doesn't bother to follow
it and just terminates there.
Shumon Huque
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-u
On Wed, Apr 1, 2020 at 8:36 AM Tony Finch wrote:
>
> This error behaviour is mostly specified by the UPDATE protocol (RFC
> 2136). It's worth reading the RFC becasue (as you have found) some of the
> behaviour is a bit surprising. For instance, adding a record that already
> exists is not an erro
de: foo.test/NS
next resign time: Sat, 28 Mar 2020 08:40:06 GMT
dynamic: yes
frozen: no
reconfigurable via modzone: no
Shumon Huque
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
uot;origfile.signed"). UPDATEs continue to go to the orig file
and ("inline?") signed deltas go into the signed file (well journal first
and synced later). It would probably be helpful to have the mechanics of
this new feature written up in
t;
> You are right that at this moment dnssec-policy is not yet suitable for
> your use case. We will implement NSEC3 for dnssec-policy in 9.17 and
> backport it to 9.16.
>
> Best regards,
>
> Matthijs
>
> On 3/25/20 8:50 PM, Shumon Huque wrote:
> > On Wed, Mar 25, 2020
signed zone with an NSEC3 param
using dynamic update or "rndc signing -nsec3param", and also use
dnssec-policy to allow for maintenance of the DNSSEC keys? Our requirement
though is that the signed zone needs to be NSEC3 out of the gate. At first
glance, if I'm understanding the new
equest about a year ago on this topic, and why BIND
should spread out the jitter:
https://gitlab.isc.org/isc-projects/bind9/issues/418
The changes first appeared in BIND 9.12.3 I believe.
Shumon Huque
___
Please visit https://lists.isc.org/mail
On Fri, Mar 13, 2015 at 8:33 AM, Alan Clegg wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Are you interested in seeing a nice graph of what your BIND server is
> doing when you aren't live-streaming the query log?
>
> Shumon Huque released (quite a w
rithm=dns.name.from_text(TSIGALG))
update.add(QNAME, 3600, 61, GEN_RDATA)
response = dns.query.tcp(update, SERVER)
print response.rcode() # should be zero
Shumon Huque
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
On 12/5/13 11:49 AM, Jay Ford wrote:
I'm testing BIND 9.9.4-P1 on a RHEL6 system & am getting this log message:
/etc/named.conf:56: couldn't add command channel 127.0.0.1#953:
address in use
That's with an rndc.key file in place & no "controls" config, which implies
TCP 953 on 127.0.0.1 & :
the journal file will get large pretty fast ..
I agree with Chris that a better mechanism for cleanup would be
useful.
--
Shumon Huque
University of Pennsylvania.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from thi
no owner name is called 'RRSIG' et. al. ;-)
>
> -JP
How about something like:
dig axfr zone | awk '$4 !~ "^NSEC$|^NSEC3$|^RRSIG$" {print}'
awk requires a tiny bit more typing, but the result is much
.error:
raise ValueError("%s isn't an IPv6 address" % address)
hexstring = ''.join(["%02x" % ord(x) for x in packed])
ptrowner = "%s.ip6.arpa" % \
'.'.join([x for x in hexstring[::-1]])
return ptrowner
if
My guess: as many as can fit
into a DNS message and stay under 64K bytes (DNS message length
in TCP is a 16-bit field).
(Note that we use dynamic update, NOTIFY, and IXFR, so we rarely
do full zone transfers).
--
Shumon Huque
University of Pennsylvania.
__
roblem because we're planning
to phase out that platform, but maybe this thread will prompt me
to collect some debug info and send it out ..
--
Shumon Huque
University of Pennsylvania.
On Thu, Jul 08, 2010 at 10:43:47AM +0200, Niklas Jakobsson wrote:
> Hello,
>
> This was my first
R.
> --Pj.
>
> Peter Janssen
> Technical Manager
The EDNS0 record is a pseudo RR that appears in the additional
section. dig reports that separately rather than in the additional
section, but the count of records in the header is correct.
--
On Mon, Feb 15, 2010 at 06:47:45PM +0100, sth...@nethelp.no wrote:
> > > Have you *measured* the hit rate of your current BIND resolvers
> > > with different cache sizes? How many queries per second are you
> > > trying to support?
> >
> > We do about 3,000 queries/second typically. I haven't meas
On Mon, Feb 15, 2010 at 05:46:25PM +0100, sth...@nethelp.no wrote:
> > I've recompiled the nameserver as a 64-bit program and confirmed
> > that they can now exceed 2GB. But I'd like to be able support
> > much larger cache sizes. We have some CS researchers on campus
> > that are making heavy use
I'm trying to support large caches with BIND on our campus
resolvers, but have run into several constraints. The
machines in question are Solaris 10/ultrasparc, running
BIND 9.6.1-P3.
It appears that 32-bit versions of BIND on Solaris 10 can't
exceed 2GB without crashing. I see other reports of th
On Mon, Jan 04, 2010 at 01:43:52PM -0500, Kevin Darcy wrote:
>
> named seems to use, by default, the OS hard limit on file descriptors,
> even though the ARM says "The default is |unlimited|. ". When it starts
> up as superuser, in theory it should be able to set both the hard and
> soft limit
On Wed, Jul 08, 2009 at 09:20:29PM +, Evan Hunt wrote:
> > Is there any reason these flags should not be set by default?
>
> Yes, there is: the code as written uses the NSEC3PARAM record in a
> way that, debatably, could be an RFC violation. We're planning to
> correct this, and turn the fea
Upgrading from 9.6.0-P1 to 9.6.1 on my master server
unexpectedly changed DNSKEY dynamic update behavior. My
tools to secure zones rely on insertion of DNSKEY
records via dynamic update. This stopped working when
I upgraded to 9.6.1.
The culprit seems to be:
*** bind-9.6.0-P1/bin/named/update.c
I'm testing BIND 9.6 with dynamically updated zones.
I'm trying to figure out if I can maintain the zone entirely via
dynamic update, even including key rollover tasks.
Or is key rollover better performed outside the nameserver process,
eg. by freezing the zone, moving in new key files into th
28 matches
Mail list logo
