wildcard not working after record deleted
bind-lists at iano.org
Tue Jun 20 14:51:16 UTC 2017
On Tue, Jun 20, 2017 at 09:29:59AM -0500, /dev/rob0 wrote:
> On Tue, Jun 20, 2017 at 09:17:58AM -0400, Maria Iano wrote:
> > Thanks for your answer. There are no other records with that name
> > in the zone, and an ANY query comes back empty but still with
> > status of NOERROR. Unfortunately, I can't provide the query and
> > zone data, and I do understand that prevents you from helping.
> > I was hoping someone else had come across this at some point.
> I can continue to waste our time with guesses, however. :)
I really appreciate that! :)
> Have you tried directed queries to an authoritative nameserver?
> Today's guess is that you might be seeing some kind of caching issue.
> A directed query like this:
> $ dig sample.example.com. any @<auth-ns-IP-addr>
> should return the wildcard if all records at "sample.example.com"
> have been removed.
The queries are being directed at an authoritative server, exactly as
you describe above.
This issue applies to some records that were deleted on
June 18th. I can't recreate it. I have deleted other records and
found that the wildcard immediately takes over. As far as I can tell
this only applies to the particular set of records deleted on the 18th.
I'm told they were deleted in the same way we always do.
We also pay for a secondary dns provider who pulls our zones from the
same authoritative servers of ours which have this issue.
The wildcard works when we send the query to one of our secondary
provider's name servers.
Here is the answer from one of the secondary provider's servers:
; <<>> DiG 9.10.2-P3 <<>> @<providers-server> <name> any
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13930
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;<name> IN ANY
;; ANSWER SECTION:
<name> 300 IN CNAME <data-in-wilcard-record>
;; Query time: 29 msec
;; SERVER: <providers-server>
;; WHEN: Tue Jun 20 10:40:18 EDT 2017
;; MSG SIZE rcvd: 82
> If in fact you were querying a caching resolver, is that BIND? Is
> the authoritative nameserver BIND?
Our servers are running bind.
More information about the bind-users