Re: rndc flushname not working
On Mon, Apr 13, 2015 at 11:10 AM, Evan Hunt e...@isc.org wrote: On Mon, Apr 13, 2015 at 11:05:05AM -0700, Frank Even wrote: ...and where could I find info on what is stored in ADB and any other particular items that flushname might not deal with? That's where my frustration largely is, that I can't find clear documentation on this point. I believe rndc dumpdb -all will give you that. Note, rndc flushname always took care of the ADB and the bad cache for a given name. rndc flushtree is the one that used to be a problem -- it would recursively clear all the names below the specified one from the DNS cache, but it wasn't touching the ADB or the bad cache. Ah...it does appear I was confusing flushtree and flushname in the most specific doc I could find - https://kb.isc.org/article/AA-01002/0/How-do-I-flush-or-delete-incorrect-records-from-my-recursive-server-cache.html I have to apologize for that. I'd still definitely be curious to know what info is stored in the ADB though since according to the docs ADB was never intended to be flushed with a flushtree (although that has now apparently been addressed in a new version as stated earlier in the thread). Thanks. ___ 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: rndc flushname not working
On Sat, Apr 11, 2015 at 6:49 AM, Tony Finch d...@dotat.at wrote: There was a bug in 9.9 and earlier that rndc flushtree only flushed the main cache, not adb or bad cache. This was fixed in 9.10 - see item 3606 in the CHANGES file. ...and where could I find info on what is stored in ADB and any other particular items that flushname might not deal with? That's where my frustration largely is, that I can't find clear documentation on this point. ___ 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: rndc flushname not working
On Mon, Apr 13, 2015 at 11:05:05AM -0700, Frank Even wrote: ...and where could I find info on what is stored in ADB and any other particular items that flushname might not deal with? That's where my frustration largely is, that I can't find clear documentation on this point. I believe rndc dumpdb -all will give you that. Note, rndc flushname always took care of the ADB and the bad cache for a given name. rndc flushtree is the one that used to be a problem -- it would recursively clear all the names below the specified one from the DNS cache, but it wasn't touching the ADB or the bad cache. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: rndc flushname not working
On Mon, Apr 13, 2015 at 11:17:41AM -0700, Frank Even wrote: I have to apologize for that. I'd still definitely be curious to know what info is stored in the ADB though since according to the docs ADB was never intended to be flushed with a flushtree (although that has now apparently been addressed in a new version as stated earlier in the thread). The ADB is the address database; it holds the addresses of previously encountered authoritative name servers and information about them such as whether they support EDNS and the largest packet size they're known to be able to accommodate. The bad cache is a separate collection of name server addresses that have been found to be irretrievably broken within the last several minutes. It prevents named from wasting too much of its time trying to get answers from broken servers. (The reason flushtree didn't originally clear those, if your curiousity extends this far, is that they're implemented as hash tables instead of trees like the DNS cache, so deleting all records below a given name is inefficient - it requires a linear search through the entire hash table. It turned out to be a useful thing to do, though, so we eventually decided to go ahead and put up with the inefficiency.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: on TTL expiry BIND sends 'ANY' query, gets back 'NOANSWER'
In message 552bb1d3.10...@imperial.ac.uk, Phil Mayers writes: On 11/04/15 14:03, Chuck Anderson wrote: I can't stop clients from making certain kinds of queries (unless BIND has a feature to refuse such queries or not recurse for them?). Whenever a client makes the 'ANY' query, it effectively causes a DoS on that name. Luckily the MinTTL is only 30 seconds, so the problem goes away after 30 seconds. This is a fair point. TBH I wonder if bind mightn't be better caching ANY as a separate pseudo-type, if I'm understanding the problem correctly. No. Named caches NXDOMAIN and NOERROR NODATA to ANY queries indendently of qtype (with the exception of DS/NXDOMAIN). Working around bugs in authoritative servers has made recursive servers more complicated than they need to be and removes any presure for authoritative server vendors and their operators to fix broken servers. Today, 16 years after its introduction, we still see authoritative servers that do not respond to EDNS queries. Trying to work around this leads to other servers being mis-classified as not supporting EDNS which in turn leads to validation failures when the zone is signed. I'm getting tempted to remove the work around code for non response to EDNS queries. I'm also tempted to remove the ability to say that EDNS is not supported in named.conf. Named will still fallback to plain DNS on FORMERR and NOTIMP. Yes, this will break lookups to certain zones. Using EDNS extensions will be the next battle field. There are lots of servers that fail to handle unknown EDNS options, flags and versions correctly despite there being specified behaviour for all of these events in RFC 6891 (RFC 2671, its predecessor, failed to specify unknown EDNS option behaviour). Only around 60% of server correctly handle all three extension methods http://users.isc.org/~marka/summary.html. Some of that is due to poorly configured firewalls in front of the nameservers rather than the nameservers themselves. Mark ___ 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
Refresh failure - operation cancelled
Can anyone from ISC comment on what Linux kernel version(s) they are seeing the issue described at https://deepthought.isc.org/article/AA-01213/0/What-causes-refresh%3A-failure-trying-master-...%3A-operation-canceled-error-messages.html on and whether there is any new info on this issue that might not have made it into the article yet? Thanks. -Tim ___ 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: Suppress log entry...
For me, it’s in the interest of keeping clean easy to read log files. Seems like this info should be available to turn on and off when needed for debugging, not every time the config is changed. Jeff On Apr 13, 2015, at 9:10 AM, Alan Clegg a...@clegg.com wrote: On 4/13/15 2:08 AM, SH Development wrote: Is there a way to suppress the build information in the log every time BIND restarts/reloads? I’m getting: built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--enable-filter-' '--with-pic' '--disable-static' '--disable-openssl-version-check' '--with-dlopen=yes' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--enable-fixed-rrset' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexce ptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' 'CPPFLAGS= -DDIG_SIGCHASE’ It's a single line that is generated and actually gives a significantly important amount of information. I'm curious as to why you feel it should be suppressed... I was teaching the class in which the addition of this line was brought up and find it extremely useful. AlanC ___ 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: Suppress log entry...
I think showing this line on start is a good thing. I'm updating our DNS servers regularly and debugging a problem and checking the old logs it's useful to find which version was running at the time and how it was built. Emil On Mon, Apr 13, 2015 at 8:19 PM, Alan Clegg a...@clegg.com wrote: On 4/13/15 1:18 PM, Reindl Harald wrote: Am 13.04.2015 um 19:14 schrieb SH Development: For me, it’s in the interest of keeping clean easy to read log files. Seems like this info should be available to turn on and off when needed for debugging, not every time the config is changed. this line appears only when named is started in other words: if you everytime you change the config hard restart named instead a reload you are doing it terrible wrong with a ton of bad side effects Yep. rndc reconfig does the loading of configuration changes and does not put the how this binary was built message into the log file. AlanC ___ 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: Suppress log entry...
Am 13.04.2015 um 08:08 schrieb SH Development: Is there a way to suppress the build information in the log every time BIND restarts/reloads? I’m getting: to filter that out is the job of the syslog daemon rsyslog.conf: :msg, contains, host=x86_64-redhat-linux-gnu stop built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' signature.asc Description: OpenPGP digital signature ___ 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: deny-answer-addresses in log-only mode?
Hi Phil, You can use RPZ for that with a zone record of: 32.1.0.0.127.rpz-ip CNAME rpz-passthru. See Response Policy Zone (RPZ) Rewriting http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.html Daniel ___ 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: on TTL expiry BIND sends 'ANY' query, gets back 'NOANSWER'
On 11/04/15 14:03, Chuck Anderson wrote: I can't stop clients from making certain kinds of queries (unless BIND has a feature to refuse such queries or not recurse for them?). Whenever a client makes the 'ANY' query, it effectively causes a DoS on that name. Luckily the MinTTL is only 30 seconds, so the problem goes away after 30 seconds. This is a fair point. TBH I wonder if bind mightn't be better caching ANY as a separate pseudo-type, if I'm understanding the problem correctly. ___ 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: Suppress log entry...
On 4/13/15 2:08 AM, SH Development wrote: Is there a way to suppress the build information in the log every time BIND restarts/reloads? I’m getting: built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--enable-filter-' '--with-pic' '--disable-static' '--disable-openssl-version-check' '--with-dlopen=yes' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--enable-fixed-rrset' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexce ptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' 'CPPFLAGS= -DDIG_SIGCHASE’ It's a single line that is generated and actually gives a significantly important amount of information. I'm curious as to why you feel it should be suppressed... I was teaching the class in which the addition of this line was brought up and find it extremely useful. AlanC signature.asc Description: OpenPGP digital signature ___ 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: on TTL expiry BIND sends 'ANY' query, gets back 'NOANSWER'
Phil Mayers p.may...@imperial.ac.uk wrote: TBH I wonder if bind mightn't be better caching ANY as a separate pseudo-type, if I'm understanding the problem correctly. Actually I think you are asking for BIND not to treat ANY specially :-) If BIND gets a positive answer to an ANY query, it caches each RRset from the response individually. There is no separate positive ANY cache entry. This means that if you query for a type which was not present in the ANY response, BIND will pursue that query upstream. This is necessary because ANY responses can be incomplete. When BIND gets a NODATA response to an ANY query it creates a special cache entry which matches any query type, so subsequent queries for the same name will get a cached negative response regardless of the type. You are asking for these negative cache entries to match only ANY queries, not queries for other types, so they behave like normal NODATA cache entries. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Fisher, German Bight: Northwest 6 to gale 8, decreasing 4, backing southwest 5 or 6 later. Moderate or rough. 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
Re: on TTL expiry BIND sends 'ANY' query, gets back 'NOANSWER'
Phil Mayers p.may...@imperial.ac.uk wrote: Ah ha. This is interesting. If you like that you'll loathe this: http://www.ietf.org/mail-archive/web/dnsop/current/msg13667.html There has been a fair amount of discussion about taming ANY queries on the dnsop list in recent weeks, though it has mostly focussed on positive answers rather than negative ones. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Viking: South 4 or 5, increasing 6 to gale 8, veering west 5 to 7 later. Moderate or rough. Rain at times. Good, occasionally poor. ___ 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: on TTL expiry BIND sends 'ANY' query, gets back 'NOANSWER'
On 13/04/15 14:28, Tony Finch wrote: Phil Mayers p.may...@imperial.ac.uk wrote: Be interesting to see what happens. I like the NSEC/TYPExxx idea for simplicity. The best suggestion so far is http://www.ietf.org/mail-archive/web/dnsop/current/msg13945.html Nice, didn't spot that one. ___ 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: on TTL expiry BIND sends 'ANY' query, gets back 'NOANSWER'
On 13/04/15 13:48, Tony Finch wrote: Phil Mayers p.may...@imperial.ac.uk wrote: TBH I wonder if bind mightn't be better caching ANY as a separate pseudo-type, if I'm understanding the problem correctly. Actually I think you are asking for BIND not to treat ANY specially :-) Maybe. I don't have ANY (ha! ha! oh my sides...) idea how it treats it now, it seems... If BIND gets a positive answer to an ANY query, it caches each RRset from the response individually. There is no separate positive ANY cache entry. This means that if you query for a type which was not present in the ANY response, BIND will pursue that query upstream. This is necessary because ANY responses can be incomplete. When BIND gets a NODATA response to an ANY query it creates a special cache entry which matches any query type, so subsequent queries for the same name will get a cached negative response regardless of the type. Ah ha. This is interesting. You are asking for these negative cache entries to match only ANY queries, not queries for other types, so they behave like normal NODATA cache entries. Well, I personally am not seeing problems so I'm not really asking ;o) But it does seem the current behaviour is maybe a little dangerous, even if the upstream server is buggy. One wonders if a spoofed negative reply could be triggered more easily with it. ___ 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: on TTL expiry BIND sends 'ANY' query, gets back 'NOANSWER'
Phil Mayers p.may...@imperial.ac.uk wrote: Be interesting to see what happens. I like the NSEC/TYPExxx idea for simplicity. The best suggestion so far is http://www.ietf.org/mail-archive/web/dnsop/current/msg13945.html Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Tyne, Dogger: Variable 3 or 4, becoming southwest 5 or 6. Moderate, occasionally slight in Tyne. Fair at first, then occasional rain. Moderate or 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
