Re: Minimal responses and speeding up queries
Mark Andrews wrote: > > Both of these are on my to do list. Yay! Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Rockall: South 5 to 7, occasionally gale 8 later. Moderate or rough, becoming very rough later in west. Rain or showers. Moderate or 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: Minimal responses and speeding up queries
In message , Tony Finch writes: > Reindl Harald wrote: > > > > just because without additional responses are part of the inital question > > and > > may save asking for that information - in case the additional info is not > > needed by the client it saves traffic > > There are a few situations in which additional data is useful in theory, > but it's surprisingly poorly used in practice. > > End-user clients are generally looking up address records, and the > additional and authority records aren't of any use to them. > > For MX and SRV records, additional data can reduce the need for extra A > and records - but only if both A and are present in the > response. If either RRset is missing the client still has to make another > query to find out if it doesn't exist or wouldn't fit. Some code I am > familiar with ignores additional sections in MX responses and always does > separate A and lookups, because it's simpler. > > The other important case is for queries from recursive servers to > authoritative servers, where you might hope that the recursive server > would cache the additional data to avoid queries to the authoritative > servers. > > However, in practice BIND is not very good at this. For example, > let's query for an MX record, then the address of one of the MX target > hosts. We expect to get the address in the response to the first query, so > the second query doesn't need another round trip to the authority. > > Here's some log, heavily pruned for relevance. > > 2016-09-23.10:55:13.316 queries: info: client @0x7f9d380311b0 ::1#55658 > (isc.org): view rec: query: isc.org IN MX +E(0)K (::1) > 2016-09-23.10:55:13.318 resolver: debug 11: sending packet to > 2001:500:60::30#53 > ;; QUESTION SECTION: > ;isc.org. IN MX > 2016-09-23.10:55:13.330 resolver: debug 10: received packet from > 2001:500:60::30#53 > ;; ANSWER SECTION: > ;isc.org. 7200IN MX 10 mx.pao1.isc.org. > ;isc.org. 7200IN MX 20 mx.ams1.isc.org. > ;; ADDITIONAL SECTION: > ;mx.pao1.isc.org. 3600IN A 149.20.64.53 > ;mx.pao1.isc.org. 3600IN 2001:4f8:0:2::2b > 2016-09-23.10:56:13.150 queries: info: client @0x7f9d300609e0 ::1#49485 > (mx.pao1.isc.org): view rec: query: mx.pao1.isc.org IN A +E(0)K (::1) > 2016-09-23.10:56:13.151 resolver: debug 11: sending packet to > 2001:500:60::30#53 > ;; QUESTION SECTION: > ;mx.pao1.isc.org. IN A > > Hmf, well that's disappointing. > > Now, there's a rule in RFC 2181 about ranking the trustworthiness of data: > > 5.4.1. Ranking data > >[ snip ] > >Unauthenticated RRs received and cached from the least trustworthy of >those groupings, that is data from the additional data section, and >data from the authority section of a non-authoritative answer, should >not be cached in such a way that they would ever be returned as >answers to a received query. They may be returned as additional >information where appropriate. Ignoring this would allow the >trustworthiness of relatively untrustworthy data to be increased >without cause or excuse. > > Since my recursive server is validating, and isc.org is signed, it should > be able to authenticate the MX target address from the MX response, and > promote its trustworthiness, instead of making another query. But BIND > doesn't do that. > > There are other situations where BIND fails to make good use of all the > records in a response, e.g. when you get a referral for a signed zone, the > response includes the DS records as well as the NS records. But BIND > doesn't cache the DS records properly, so when it comes to validate the > answer, it re-fetches them. Both of these are on my to do list. There is also the no DS available in the delegation to be validated at the transition from signed to unsigned zones. > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode > Northwest Fitzroy, West Sole: Southerly, veering westerly later, 6 to gale 8. > Rough or very rough. Fair then rain. 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 -- 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
R: Minimal responses and speeding up queries
Hi Tony, excellent answer, thank you very much. My first goal, since i use Bind 9.10 in conjunction with DLZ (old driver), is limiting additional queries to reduc load into backend database system. By tuning the minimal-responses i have few database queries less than before; it is a good step, to begin. I will try different parameters and configurations in order to limit, at possible, the number of additional queries! Thank you, Cheers from Italy! Francesco Da: bind-users [bind-users-boun...@lists.isc.org] per conto di Tony Finch [d...@dotat.at] Inviato: venerdì 23 settembre 2016 13.21 A: Reindl Harald Cc: bind-users@lists.isc.org Oggetto: Re: Minimal responses and speeding up queries Reindl Harald wrote: > > just because without additional responses are part of the inital question and > may save asking for that information - in case the additional info is not > needed by the client it saves traffic There are a few situations in which additional data is useful in theory, but it's surprisingly poorly used in practice. End-user clients are generally looking up address records, and the additional and authority records aren't of any use to them. For MX and SRV records, additional data can reduce the need for extra A and records - but only if both A and are present in the response. If either RRset is missing the client still has to make another query to find out if it doesn't exist or wouldn't fit. Some code I am familiar with ignores additional sections in MX responses and always does separate A and lookups, because it's simpler. The other important case is for queries from recursive servers to authoritative servers, where you might hope that the recursive server would cache the additional data to avoid queries to the authoritative servers. However, in practice BIND is not very good at this. For example, let's query for an MX record, then the address of one of the MX target hosts. We expect to get the address in the response to the first query, so the second query doesn't need another round trip to the authority. Here's some log, heavily pruned for relevance. 2016-09-23.10:55:13.316 queries: info: client @0x7f9d380311b0 ::1#55658 (isc.org): view rec: query: isc.org IN MX +E(0)K (::1) 2016-09-23.10:55:13.318 resolver: debug 11: sending packet to 2001:500:60::30#53 ;; QUESTION SECTION: ;isc.org. IN MX 2016-09-23.10:55:13.330 resolver: debug 10: received packet from 2001:500:60::30#53 ;; ANSWER SECTION: ;isc.org. 7200IN MX 10 mx.pao1.isc.org. ;isc.org. 7200IN MX 20 mx.ams1.isc.org. ;; ADDITIONAL SECTION: ;mx.pao1.isc.org. 3600IN A 149.20.64.53 ;mx.pao1.isc.org. 3600IN 2001:4f8:0:2::2b 2016-09-23.10:56:13.150 queries: info: client @0x7f9d300609e0 ::1#49485 (mx.pao1.isc.org): view rec: query: mx.pao1.isc.org IN A +E(0)K (::1) 2016-09-23.10:56:13.151 resolver: debug 11: sending packet to 2001:500:60::30#53 ;; QUESTION SECTION: ;mx.pao1.isc.org. IN A Hmf, well that's disappointing. Now, there's a rule in RFC 2181 about ranking the trustworthiness of data: 5.4.1. Ranking data [ snip ] Unauthenticated RRs received and cached from the least trustworthy of those groupings, that is data from the additional data section, and data from the authority section of a non-authoritative answer, should not be cached in such a way that they would ever be returned as answers to a received query. They may be returned as additional information where appropriate. Ignoring this would allow the trustworthiness of relatively untrustworthy data to be increased without cause or excuse. Since my recursive server is validating, and isc.org is signed, it should be able to authenticate the MX target address from the MX response, and promote its trustworthiness, instead of making another query. But BIND doesn't do that. There are other situations where BIND fails to make good use of all the records in a response, e.g. when you get a referral for a signed zone, the response includes the DS records as well as the NS records. But BIND doesn't cache the DS records properly, so when it comes to validate the answer, it re-fetches them. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Northwest Fitzroy, West Sole: Southerly, veering westerly later, 6 to gale 8. Rough or very rough. Fair then rain. 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 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
Re: Minimal responses and speeding up queries
Reindl Harald wrote: > > just because without additional responses are part of the inital question and > may save asking for that information - in case the additional info is not > needed by the client it saves traffic There are a few situations in which additional data is useful in theory, but it's surprisingly poorly used in practice. End-user clients are generally looking up address records, and the additional and authority records aren't of any use to them. For MX and SRV records, additional data can reduce the need for extra A and records - but only if both A and are present in the response. If either RRset is missing the client still has to make another query to find out if it doesn't exist or wouldn't fit. Some code I am familiar with ignores additional sections in MX responses and always does separate A and lookups, because it's simpler. The other important case is for queries from recursive servers to authoritative servers, where you might hope that the recursive server would cache the additional data to avoid queries to the authoritative servers. However, in practice BIND is not very good at this. For example, let's query for an MX record, then the address of one of the MX target hosts. We expect to get the address in the response to the first query, so the second query doesn't need another round trip to the authority. Here's some log, heavily pruned for relevance. 2016-09-23.10:55:13.316 queries: info: client @0x7f9d380311b0 ::1#55658 (isc.org): view rec: query: isc.org IN MX +E(0)K (::1) 2016-09-23.10:55:13.318 resolver: debug 11: sending packet to 2001:500:60::30#53 ;; QUESTION SECTION: ;isc.org. IN MX 2016-09-23.10:55:13.330 resolver: debug 10: received packet from 2001:500:60::30#53 ;; ANSWER SECTION: ;isc.org. 7200IN MX 10 mx.pao1.isc.org. ;isc.org. 7200IN MX 20 mx.ams1.isc.org. ;; ADDITIONAL SECTION: ;mx.pao1.isc.org. 3600IN A 149.20.64.53 ;mx.pao1.isc.org. 3600IN 2001:4f8:0:2::2b 2016-09-23.10:56:13.150 queries: info: client @0x7f9d300609e0 ::1#49485 (mx.pao1.isc.org): view rec: query: mx.pao1.isc.org IN A +E(0)K (::1) 2016-09-23.10:56:13.151 resolver: debug 11: sending packet to 2001:500:60::30#53 ;; QUESTION SECTION: ;mx.pao1.isc.org. IN A Hmf, well that's disappointing. Now, there's a rule in RFC 2181 about ranking the trustworthiness of data: 5.4.1. Ranking data [ snip ] Unauthenticated RRs received and cached from the least trustworthy of those groupings, that is data from the additional data section, and data from the authority section of a non-authoritative answer, should not be cached in such a way that they would ever be returned as answers to a received query. They may be returned as additional information where appropriate. Ignoring this would allow the trustworthiness of relatively untrustworthy data to be increased without cause or excuse. Since my recursive server is validating, and isc.org is signed, it should be able to authenticate the MX target address from the MX response, and promote its trustworthiness, instead of making another query. But BIND doesn't do that. There are other situations where BIND fails to make good use of all the records in a response, e.g. when you get a referral for a signed zone, the response includes the DS records as well as the NS records. But BIND doesn't cache the DS records properly, so when it comes to validate the answer, it re-fetches them. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Northwest Fitzroy, West Sole: Southerly, veering westerly later, 6 to gale 8. Rough or very rough. Fair then rain. 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: R: Minimal responses and speeding up queries
On 23.09.16 09:33, Job wrote: Very interesting answers, thank you first of all. Regarding: BIND 9.11 adds two more stops on the knob There will be an option to add these stops or, by default, bind-9.11 will care about this? care about what? DNS client will fetch data it needs to resolve a query. If you turn mimimal-responses on, the required data may not be in the answer. That will result into another query send, which means number of queries increases. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Posli tento mail 100 svojim znamim - nech vidia aky si idiot Send this email to 100 your friends - let them see what an idiot you are ___ 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
R: Minimal responses and speeding up queries
Very interesting answers, thank you first of all. Regarding: >>BIND 9.11 adds two more stops on the knob There will be an option to add these stops or, by default, bind-9.11 will care about this? Thank you Francesco Da: bind-users [bind-users-boun...@lists.isc.org] per conto di Mark Andrews [ma...@isc.org] Inviato: venerdì 23 settembre 2016 1.21 A: Reindl Harald Cc: bind-us...@isc.org Oggetto: Re: Minimal responses and speeding up queries In message <218818d8-5ab8-40b0-fbc2-27c8966bb...@thelounge.net>, Reindl Harald writes: > Am 22.09.2016 um 22:41 schrieb Job: > >>> If you want to avoid additional queries, turn minimal_responses off. > > > > I thought setting minimal_responses = yes should lower the number of querie > s > > Do you think it is the opposite? > > it's not about thinking - it's a fact > > just because without additional responses are part of the inital > question and may save asking for that information - in case the > additional info is not needed by the client it saves traffic > > just read what that option does and you know it It's a response size vs number of queries trade off. What is "better" depends on how the clients process the answers returned, the contents of the answers and what you want to achieve. There are lots of variables to this and they change over time. In the end it is a knob. BIND 9.11 adds two more stops on the knob. Mark -- 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 ___ 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: R: Minimal responses and speeding up queries
In article , Job wrote: > I thought setting minimal_responses = yes should lower the number of queries > Do you think it is the opposite? Yes. With minimal_response = no, it doesn't fill in the Additional section with records related to the ones in the Answer section. If the client doesn't already have those records cached, it will need to make an additional query to get them. So instead of one query that returns everything the client needs, it needs to make two queries. -- Barry Margolin Arlington, MA ___ 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: Minimal responses and speeding up queries
In message <218818d8-5ab8-40b0-fbc2-27c8966bb...@thelounge.net>, Reindl Harald writes: > Am 22.09.2016 um 22:41 schrieb Job: > >>> If you want to avoid additional queries, turn minimal_responses off. > > > > I thought setting minimal_responses = yes should lower the number of querie > s > > Do you think it is the opposite? > > it's not about thinking - it's a fact > > just because without additional responses are part of the inital > question and may save asking for that information - in case the > additional info is not needed by the client it saves traffic > > just read what that option does and you know it It's a response size vs number of queries trade off. What is "better" depends on how the clients process the answers returned, the contents of the answers and what you want to achieve. There are lots of variables to this and they change over time. In the end it is a knob. BIND 9.11 adds two more stops on the knob. Mark -- 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
Re: Minimal responses and speeding up queries
Am 22.09.2016 um 22:41 schrieb Job: If you want to avoid additional queries, turn minimal_responses off. I thought setting minimal_responses = yes should lower the number of queries Do you think it is the opposite? it's not about thinking - it's a fact just because without additional responses are part of the inital question and may save asking for that information - in case the additional info is not needed by the client it saves traffic just read what that option does and you know 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: R: Minimal responses and speeding up queries
minimal-responses affects the size and not the number of responses. On Sep 22, 2016 23:44, "Job" wrote: > Hi Matus, > > >>If you want to avoid additional queries, turn minimal_responses off. > > I thought setting minimal_responses = yes should lower the number of > queries > Do you think it is the opposite? > > Thank you again! > Francesco > > > Da: bind-users [bind-users-boun...@lists.isc.org] per conto di Matus > UHLAR - fantomas [uh...@fantomas.sk] > Inviato: giovedì 22 settembre 2016 17.07 > A: bind-users@lists.isc.org > Oggetto: Re: Minimal responses and speeding up queries > > On 22.09.16 16:41, Job wrote: > >in Bind 9.10 we tried minimal-responses = yes to limit "additional > queries" when resolving. > > > >I notice that resolution is faster. > >Actually, dig @host some_url still shows an additional query, maybe not > needed for a caching-only resolver: > > > >; (1 server found) > >;; global options: +cmd > >;; Got answer: > >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54581 > >;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > > > >Is there a way to improve limiting of "additional queries" after > minimal-responses = yes? > > using minimal responses often results into additional queries needed, by > definition. If you want to avoid additional queries, turn > minimal_responses > off. > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > "Two words: Windows survives." - Craig Mundie, Microsoft senior strategist > "So does syphillis. Good thing we have penicillin." - Matthew Alton > ___ > 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 > ___ 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
R: Minimal responses and speeding up queries
Hi Tony, >>it's a record in the additional section of the response - specifically the OPT record which includes the EDNS buffer size, DNSSEC flag, and other extensions Is there an option to disable completely the OPT record information provided from Bind? Thank you! Francesco Da: Tony Finch [d...@dotat.at] Inviato: giovedì 22 settembre 2016 16.52 A: Job Cc: bind-users@lists.isc.org Oggetto: Re: Minimal responses and speeding up queries Job wrote: > > Actually, dig @host some_url still shows an additional query, maybe not > needed for a caching-only resolver: > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 That isn't an additional query, it's a record in the additional section of the response - specifically the OPT record which includes the EDNS buffer size, DNSSEC flag, and other extensions. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Malin, Hebrides: South or southwest 5 to 7, occasionally gale 8 later. Rough, occasionally very rough. Squally showers, rain later. Good becoming moderate or poor later. ___ 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
R: Minimal responses and speeding up queries
Hi Matus, >>If you want to avoid additional queries, turn minimal_responses off. I thought setting minimal_responses = yes should lower the number of queries Do you think it is the opposite? Thank you again! Francesco Da: bind-users [bind-users-boun...@lists.isc.org] per conto di Matus UHLAR - fantomas [uh...@fantomas.sk] Inviato: giovedì 22 settembre 2016 17.07 A: bind-users@lists.isc.org Oggetto: Re: Minimal responses and speeding up queries On 22.09.16 16:41, Job wrote: >in Bind 9.10 we tried minimal-responses = yes to limit "additional queries" >when resolving. > >I notice that resolution is faster. >Actually, dig @host some_url still shows an additional query, maybe not needed >for a caching-only resolver: > >; (1 server found) >;; global options: +cmd >;; Got answer: >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54581 >;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > >Is there a way to improve limiting of "additional queries" after >minimal-responses = yes? using minimal responses often results into additional queries needed, by definition. If you want to avoid additional queries, turn minimal_responses off. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "Two words: Windows survives." - Craig Mundie, Microsoft senior strategist "So does syphillis. Good thing we have penicillin." - Matthew Alton ___ 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: Minimal responses and speeding up queries
On 22.09.16 16:41, Job wrote: in Bind 9.10 we tried minimal-responses = yes to limit "additional queries" when resolving. I notice that resolution is faster. Actually, dig @host some_url still shows an additional query, maybe not needed for a caching-only resolver: ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54581 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 Is there a way to improve limiting of "additional queries" after minimal-responses = yes? using minimal responses often results into additional queries needed, by definition. If you want to avoid additional queries, turn minimal_responses off. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "Two words: Windows survives." - Craig Mundie, Microsoft senior strategist "So does syphillis. Good thing we have penicillin." - Matthew Alton ___ 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: Minimal responses and speeding up queries
Job wrote: > > Actually, dig @host some_url still shows an additional query, maybe not > needed for a caching-only resolver: > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 That isn't an additional query, it's a record in the additional section of the response - specifically the OPT record which includes the EDNS buffer size, DNSSEC flag, and other extensions. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Malin, Hebrides: South or southwest 5 to 7, occasionally gale 8 later. Rough, occasionally very rough. Squally showers, rain later. Good becoming moderate or poor later. ___ 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
Minimal responses and speeding up queries
Hello, in Bind 9.10 we tried minimal-responses = yes to limit "additional queries" when resolving. I notice that resolution is faster. Actually, dig @host some_url still shows an additional query, maybe not needed for a caching-only resolver: ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54581 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 Is there a way to improve limiting of "additional queries" after minimal-responses = yes? Thank you Francesco ___ 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
