Negative Caching of DNS Responses for Different RCODES
Hello experts, If a DNS server looks up a record and it's missing, it will often "negatively cache" the fact that this record is missing, and not try to look it up again for a while. >From RFC 2308, Negative Caching of DNS Queries, I understood, the TTL for >NXDOMAIN RCODE responses is taken from SOA Record at the top of the Zone. My Questions 1. How is Negative Caching Applied for other RCODES : FORMERR, SERVFAIL, REFUSED and NOTIMPL? What is the minimum TTL Value for these responses? 2. Are the clients free to re-query the same DNS server if no caching is applied for the above RCODES? Thanks Harshith ___ 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
Re: Negative Caching of DNS Responses for Different RCODES
Harshith Mulky wrote: > > 1. How is Negative Caching Applied for other RCODES : FORMERR, SERVFAIL, > REFUSED and NOTIMPL? What is the minimum TTL Value for these responses? Good question: this isn't well specified. BIND has servfail-ttl (1s by default) and lame-ttl (600s by default). The lame-ttl can take effect in as a result of REFUSED responses amongst other things. NOTIMPL should not normally occur. FORMERR can trigger EDNS downgrade. > 2. Are the clients free to re-query the same DNS server if no caching is > applied for the above RCODES? In general the same question will yield the same answer so a good implementation should avoid and preferably suppress repeat queries. Tony. -- f.anthony.n.finchhttp://dotat.at/ Biscay, Fitzroy: Variable 3 or 4, becoming northerly or northwesterly 5 at times, occasionally 6 later in southeast Fitzroy. Slight or moderate. Showers. Good. ___ 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
dig +trace question
I just recently "upgraded" my old FreeBSD system to the latest, 12.0 release. Now, something that used to work doesn't seem to work anymore, specifically "dig +trace" seems to no longer function at all. Example: % dig +trace -x 195.154.23.103 ; <<>> DiG 9.12.4-P1 <<>> +trace -x 195.154.23.103 ;; global options: +cmd ;; Received 17 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms That's all I get. No more outout. It's probably my fault... somehow. I've revised my firewall rules and also, I'm now using local-unbound on the machine in qquestion, whereas before I was just using 8.8.8.8. I just need to ask: How can I debug this? I need to get back to having this work. Also, on a different machine that I have also recently upgraded to FreeBSD 12.0 I am not getting the following strange and unexpected error when running dig, regadless of options or arguments: Shared object "libdl.so.1" not found, required by "dig" So, I need to ask also: What's the proper for this separate and different error? (Note: On both machines, the particular package I have installed that is providing me with the "dig" command is: bind-tools-9.12.4P1.) ___ 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
Re: dig +trace question
Hi Ronald, You usually need to reinstall packages and ports after you do a major version upgrade to FreeBSD. pkg update && pkg upgrade You should see bind-tools in the list. Version might stay the same but you’ll be getting a different version, compiled against FreeBSD 12. cheers, —Matt > On Jun 20, 2019, at 5:33 PM, Ronald F. Guilmette > wrote: > > I just recently "upgraded" my old FreeBSD system to the latest, 12.0 > release. Now, something that used to work doesn't seem to work anymore, > specifically "dig +trace" seems to no longer function at all. > > Example: > > > % dig +trace -x 195.154.23.103 > > ; <<>> DiG 9.12.4-P1 <<>> +trace -x 195.154.23.103 > ;; global options: +cmd > ;; Received 17 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms > > > > > That's all I get. No more outout. > > It's probably my fault... somehow. I've revised my firewall rules > and also, I'm now using local-unbound on the machine in qquestion, > whereas before I was just using 8.8.8.8. > > I just need to ask: How can I debug this? I need to get back to having > this work. > > Also, on a different machine that I have also recently upgraded to > FreeBSD 12.0 I am not getting the following strange and unexpected > error when running dig, regadless of options or arguments: > > Shared object "libdl.so.1" not found, required by "dig" > > So, I need to ask also: What's the proper for this separate and > different error? > > (Note: On both machines, the particular package I have installed that > is providing me with the "dig" command is: bind-tools-9.12.4P1.) > ___ > 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 ___ 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
Re: dig +trace question
In message <9ba154cc-2272-46ec-a793-47ff31dca...@arin.net>, you wrote: >Hi Ronald, >You usually need to reinstall packages and ports after you do a major >version upgrade to FreeBSD. I guess that I did not make myself clear. Everything on this system is freshly installed, from scratch. I have the FreeBSD package "bind-tools-9.12.4P1" installed the latest, undoubtedly compiled against FreeBSD 12.0. Anyway, it really does appear now that this problem *is* a regression in dig, and that it's not just me. I tried my dig with both +trace -and -x also on *two* different Ubuntu system I have here. On Ubuntu 16.04 LTS it works as expected. On Ubuntu 18.04 LTS it fails as I have reported. It looks to me like somebody broke dig. Where do I file the formal bugreport? Regards, rfg ___ 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
Re: dig +trace question
Are you sure it's not your setup? I have plenty of dig running on FreeBSD (with bind-utils 9.14) and also Debian and they work just fine. -- Nico > On 21 Jun 2019, at 09:14, Ronald F. Guilmette wrote: > > In message <9ba154cc-2272-46ec-a793-47ff31dca...@arin.net>, you wrote: > >> Hi Ronald, >> You usually need to reinstall packages and ports after you do a major >> version upgrade to FreeBSD. > > I guess that I did not make myself clear. Everything on this system is > freshly installed, from scratch. > > I have the FreeBSD package "bind-tools-9.12.4P1" installed the latest, > undoubtedly compiled against FreeBSD 12.0. > > Anyway, it really does appear now that this problem *is* a regression in > dig, and that it's not just me. > > I tried my dig with both +trace -and -x also on *two* different Ubuntu > system I have here. > > On Ubuntu 16.04 LTS it works as expected. > > On Ubuntu 18.04 LTS it fails as I have reported. > > It looks to me like somebody broke dig. > > Where do I file the formal bugreport? > > > Regards, > rfg > ___ > 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 ___ 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
Re: dig +trace question
In message <4e8f2e2c-7571-44dd-b012-57543debd...@ncartron.org>, Nico Cartron wrote: >Are you sure it's not your setup? >I have plenty of dig running on FreeBSD (with bind-utils 9.14) and also >Debian and they work just fine. You know what? I think we may both be right. Checking now, I think I see the problem. There is some sort of a problematic interaction happening -only- between "dig +trace" and either unbound or local-unbound. On my old Ubuntu 16.04 system, /etc/resolv.conf contains only: nameserver 8.8.8.8 nameserver 8.8.4.4 (Those are the public Google name servers, of course.) On that system "dig +trace" works, no problem. On my two newer systems, Ubuntu 18.04 and FreeBSD 12.0 instead of me relying on Google's public name servers, the /etc/resolv.conf files on these two newer systems both contain only: nameserver 127.0.0.1 On one, I'm running a local instance of unbound, and on the other I am running a local instance of local-unbound. On these two systems "dig +trace" DOES NOT just work. In fact it fails essentally immediately in both cases, regardless of whether you're trying to do the +trace on a normal sort of FQDN -or- for some .in-addr.arpa name, where you give the argument as "-x A.B.C.D". HOWEVER I found a trivial way to make the +trace work even on these systems. Apparently, you just have to goose it a bit, and just get it sort-of kick started. And you can do that just by simply giving it a clear idea of where it should begin the whole process. You can do that by simply appending "@a.root-servers.net" to the end of the command line. If you do that, then the trace works as expexcted. (NOTE: It is not necessary to use the "A" root server in particular. Any one of the root servers seems to do just as well.) So now, this all begs the Rodney King question: Can't we all just get along? What is it about unbound/local-unbound that makes it not plug and play well with dig +trace? What is it that Google's public name servers are doing that a local running instance of unbound and/or local-unbound isn't doing? Regards, rfg ___ 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
