[dns-operations] Odd resolver/cache behavor or normal operation?

[Mohamed Lrhazi]

Thanks Joe.

I was kind of hoping someone would have had similar experience with this
very record, imap.gmail.com.

Our caching resolver uses yet another caching resolver.... which did return
the odd response, according to our query log, The logs from our upper
stream resolver show that at the time to the odd response, it was handling
too many recursive queries:

Aug 24 05:13:40 [daemon.warning] named: client 141.161.200.25#63990: view
3: no more recursive clients (1000/0/1000): quota reached

It did answer  imap.gmail.com with zero number of records in the answer
section, but always with status of SRVERROR, but once, and only once, it
answered with zero records and with NOERROR status. It seems our caching
server somehow liked this latter answer so much it hang on to it for the
rest of the day!

Not quite sure what to make of all this, searching 30 days worth of query
logs, it seems this record has always been answered with a count of 3, for
answers.... only during this outage was that 0.

Thanks,
Mohamed.


On Mon, Aug 26, 2013 at 11:14 AM, Joe Abley <jabley at hopcount.ca> wrote:

> Hi Mohamed,
>
> I don't imagine that anybody is going to be able to give you a root cause
> based on just that information. It could be a bug in your resolver, it
> could be a transient problem at google, it could be a sign of successful
> cache poisoning attack, or it could be something else.
>
> I recommend keeping a rolling tcpdump running on all nameservers, and
> aging out the resulting compressed pcaps from cron to avoid filling your
> local disks. It's much better to be able to look for answers with data than
> to look for answers with no data.
>
>
> Joe
>
> On 2013-08-26, at 10:27, Mohamed Lrhazi <ml623 at georgetown.edu> wrote:
>
> > Hello,
> >
> > We had mail outage which was caused by one of our three recursive
> caching DNS servers to be answering a query like seen bellow.
> >
> > What could explain the fact that this record had zero answers? and why
> would the cache server, apparently, cache this answer for over 10 hours
> (until I manually cleared the cache)? A user reported that the cache server
> was returning AAAA records, but no IPv4, though we dont have an example of
> such query/response saved. I guess the fact that the server had AAAA record
> would explain why the bellow response is a NOERROR?
> >
> > ➜  ~  dig imap.gmail.com @141.161.200.201
> >
> > ; <<>> DiG 9.9.2-P1 <<>> imap.gmail.com @141.161.200.201
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34151
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 5
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ;; QUESTION SECTION:
> > ;imap.gmail.com.                      IN      A
> >
> > ;; AUTHORITY SECTION:
> > gmail.com.            94747   IN      NS      ns3.google.com.
> > gmail.com.            94747   IN      NS      ns2.google.com.
> > gmail.com.            94747   IN      NS      ns4.google.com.
> > gmail.com.            94747   IN      NS      ns1.google.com.
> >
> > ;; ADDITIONAL SECTION:
> > ns2.google.com.               269064  IN      A       216.239.34.10
> > ns1.google.com.               269064  IN      A       216.239.32.10
> > ns3.google.com.               269064  IN      A       216.239.36.10
> > ns4.google.com.               269064  IN      A       216.239.38.10
> >
> > ;; Query time: 56 msec
> > ;; SERVER: 141.161.200.201#53(141.161.200.201)
> > ;; WHEN: Sat Aug 24 16:21:17 2013
> > ;; MSG SIZE  rcvd: 186
> >
> > Thanks a lot,
> > Mohamed.
> >
> > _______________________________________________
> > dns-operations mailing list
> > dns-operations at lists.dns-oarc.net
> > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> > dns-jobs mailing list
> > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20130826/a6fd5992/attachment.html>