Re: negative caching ttl question
Thank you, Tony. You're right. I do see a difference in behavior when querying other authoritative, non-AWS servers. I didn't realize it was the job of the authoritative server to do the math and present the proper ttl. Thanks for the pointer to the relevant section in the rfc. Slava On Tue, Oct 13, 2020 at 1:34 PM Tony Finch wrote: > > Veaceslav Revutchi wrote: > > > Given this soa: > > > > fe80.info. 3600 IN SOA ns-538.awsdns-03.net. > > awsdns-hostmaster.amazon.com. 1 7200 900 1209600 60 > > > > I see bind caching negative answers for 3600 instead of 60. The rfc > > and my google searches suggest that it should pick the MIN(soa ttl, > > soa min ttl) for that purpose. What am I missing? > > I think what RFC 2308 says (sections 3 and 5) the authoritative server for > the zone is responsible for calculating the negative TTL from the minimum > of the SOA TTL and MINIMUM fields. Sections 5 and 6 say that resolvers and > caches propagate the negative TTL using just the TTL field of the SOA in > the AUTHORITY section of the response (though the RFC could be a little > more explicit about this). > > What's happening for fe80.info is the AWS DNS authoritative servers are > setting the wrong TTL in the negative response, and your BIND cache is > doing what it is told to do. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Ardnamurchan Point to Cape Wrath: Northeast 5 or 6, veering east 3 or 4 later. > Rough becoming moderate. Showers. Good, occasionally moderate. ___ 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 https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: unable to delzone
Well, if it works for other zones, it's unlikely to be an OS problem unless
that zone was built in the system using an older version that did things
slightly differently and now it can't be removed because of that difference.
Have you tried comparing a working zone that can be deleted from the problem
zone with rndc zonestatus and rndc showzone? Maybe something will stand out
there. But at this point, all I have to suggest is theoretical. Sorry, I
don't know how to manually remove / rebuild the zone database. If you're stuck
after this and no one has any further suggestions, I'd recommend turning up the
logging level on named and comparing operations or doing them under strace and
seeing where success and failure diverge.
Best of luck,
Scott
From: BÖSCH Christian
Sent: Tuesday, October 13, 2020 2:23 AM
To: Scott A. Wozny
Cc: bind-users@lists.isc.org
Subject: Re: unable to delzone
OS running is FreeBSD 12.1 with bind version 9.16.7.
I'm running rndc commands as root user.
Yes, the zone was created with rndc addzone. And it's also possible to add and
delete other zones this way.
Only the one particular zone throws this error.
Is there a way to manually clean or rebuild the nzd database?
Thanks, Christian
From: "Scott A. Wozny"
Date: Monday, 12. October 2020 at 20:42
To: "boe...@fhv.at" , "bind-users@lists.isc.org"
Subject: Re: unable to delzone
There are a LOT of possibilities why this isn't working. The first two things
I'd check is trying this action again as root (if you're not already) to make
sure this action isn't trying something that's DAC prohibited and checking the
SELinux / AppArmor log (if you're running them) to see if this particular
action (it doesn't sound like it's something you do often) is making a system
call that's forbidden by the MAC.
These are suggestions to see if the issue is at the OS level, of course. I'm
assuming what you're doing is permitted in the application (i.e. the zone
you're trying to delete was created with rndc addzone) but you haven't provided
enough detail to determine that.
HTH,
Scott
From: bind-users on behalf of BÖSCH
Christian
Sent: October 12, 2020 4:35 AM
To: bind-users@lists.isc.org
Subject: unable to delzone
Hi,
I want to delete a zone with:
rndc delzone domain.org
In the logfile I get:
Oct 12 10:16:30 nsmaster named[669]: general: received control channel command
'delzone domain.org'
Oct 12 10:16:30 nsmaster named[669]: general: zone domain.org scheduled for
removal via delzone
Oct 12 10:16:30 nsmaster named[669]: general: deleting zone domain.org in view
_default via delzone
Oct 12 10:16:30 nsmaster named[669]: general: mdb_txn_begin: Invalid argument
Oct 12 10:16:30 nsmaster named[669]: general: unable to open NZD database for
'_default.nzd'
Oct 12 10:16:30 nsmaster named[669]: general: unable to delete zone
configuration: failure
And so in the nzd db the config remains active:
named-nzd2nzf _default.nzd | grep domain.org
zone "domain.org" { type master; file "../dynamic/domain.org"; };
So why can the nzd db not be opened? And how can that be solved?
Thanks in advance,
Christian
___
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 https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: negative caching ttl question
Veaceslav Revutchi wrote: > Given this soa: > > fe80.info. 3600 IN SOA ns-538.awsdns-03.net. > awsdns-hostmaster.amazon.com. 1 7200 900 1209600 60 > > I see bind caching negative answers for 3600 instead of 60. The rfc > and my google searches suggest that it should pick the MIN(soa ttl, > soa min ttl) for that purpose. What am I missing? I think what RFC 2308 says (sections 3 and 5) the authoritative server for the zone is responsible for calculating the negative TTL from the minimum of the SOA TTL and MINIMUM fields. Sections 5 and 6 say that resolvers and caches propagate the negative TTL using just the TTL field of the SOA in the AUTHORITY section of the response (though the RFC could be a little more explicit about this). What's happening for fe80.info is the AWS DNS authoritative servers are setting the wrong TTL in the negative response, and your BIND cache is doing what it is told to do. Tony. -- f.anthony.n.finchhttp://dotat.at/ Ardnamurchan Point to Cape Wrath: Northeast 5 or 6, veering east 3 or 4 later. Rough becoming moderate. Showers. Good, occasionally moderate. ___ 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 https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
