Re: [SOLVED] Re: BIND9 SERVFAIL on some .gov addresses
There was also a message-length client auto or something like that too for some versions of some Cisco HW, but if memory serves, the version that introduced it is broken. :) On 02/23/2011 04:54 PM, Warren Kumari wrote: In PIX versions 6.3.2 and below you had to do: fixup protocol dns maximum-length 4096 In later versions you need: policy-map type inspect dns preset_dns_map parameters message-length maximum 4096 or to increase the response size length: policy-map global_policy class inspection_default inspect dns maximum-length 4096 This is rumor and innuendo, I personally believe that: a: firewalls with ALGs are the devil b: this goes double for PIX / ASA and c: doubled again for putting them in front of servers, especially DNS servers W On Feb 23, 2011, at 1:13 PM, Ryan Novosielski wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A couple more gems: https://www.dnssec-deployment.org/wp-content/uploads/2010/03/DNSSEC-CPE-Report.pdf (really anything at dnssec-deployment.org) There was another table that I found someplace and cannot find now that listed Cisco PIX and mentioned with a * the subtle difference between versions of that firewall firmware. I can't find that table anywhere -- was HTML, not in a PDF. On 02/23/2011 11:39 AM, Ryan Novosielski wrote: Take a look at this. It is somewhat confusing, but it is helpful and should tell you right away if you definitely have a firewall issue (and frankly there's little else it could be). https://www.dns-oarc.net/oarc/services/replysizetest On 02/23/2011 11:15 AM, Shaoquan Lin wrote: Thanks, Mark, Last June I asked our firewall person to make sure our firewall not blocking DNS packets over 512 bytes. He told me our firewall was not blocking. I guess that might be some default setting of the firewall and he does not really know. I did two digs here one with +dnssec and one without. I got the the following: 1) with +dnssec : ; <<>> DiG 9.6.1-P3 <<>> +norec vwall4a.nyc.gov @b.gov-servers.net +dnssec ;; global options: +cmd ;; connection timed out; no servers could be reached 2) without +dnssec : ; <<>> DiG 9.6.1-P3 <<>> +norec vwall4a.nyc.gov @b.gov-servers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2024 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;vwall4a.nyc.gov. IN A ;; AUTHORITY SECTION: nyc.gov. 86400 IN NS vwall1a.nyc.gov. nyc.gov. 86400 IN NS vwall2a.nyc.gov. nyc.gov. 86400 IN NS vwall3a.nyc.gov. nyc.gov. 86400 IN NS vwall4a.nyc.gov. ;; ADDITIONAL SECTION: vwall1a.nyc.gov. 86400 IN A 161.185.1.3 vwall2a.nyc.gov. 86400 IN A 161.185.1.12 vwall3a.nyc.gov. 86400 IN A 167.153.130.12 vwall4a.nyc.gov. 86400 IN A 167.153.130.13 ;; Query time: 31 msec ;; SERVER: 209.112.123.30#53(209.112.123.30) ;; WHEN: Wed Feb 23 11:12:48 2011 ;; MSG SIZE rcvd: 192 Does this show we do have a firewall problem here? Shaoquan Lin Mark Andrews wrote: In message <0539E64AD2B54AD2804C2394F923800B@se179>, "Shaoquan Lin" writes: Mark, Are these bugs (2784 and 1804) fixed by BIND 9.6.1-P3? My problem is that I can not get A records of NSs (like vwall4a.nyc.gov) of nyc.gov from b.gov-servers.net by BIND 9.6.1-P3 but with no problem with older BINDs like 9.3. I don't know if the problem is with the authoritative nameservers for gov or the nameservers for nyc.gov or with the BIND I am using. I noticed the following: Just fix your firewalls to allow EDNS responses through. While this is a bug in the authoritative servers / interpretation of RFC 1034, its only a issue because your firewall configuration is a decade out of date that it is a problem. 1). a.gov-servers.net or b.gov-servers.net does provide A records in the additional records of their responses for other subdomain under gov like treas.gov, just not nyc.gov. So the problem seems with nameservers for nyc.gov. The problem is relatively new and there might be some recent changes on nyc.gov. The gov servers will return glue if you let bigger answers than 512 bytes through your firewall. ; <<>> DiG 9.6.0-APPLE-P2 <<>> +norec vwall4a.nyc.gov @b.gov-servers.net +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50028 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1472 ;; QUESTION SECTION: ;vwall4a.nyc.gov. IN A ;; AUTHORITY SECTION: nyc.gov. 86400 IN NS vwall1a.nyc.gov. nyc.gov. 86400 IN NS vwall2a.nyc.gov. nyc.gov. 86400 IN NS vwall3a.nyc.gov. nyc.gov. 86400 IN NS vwall4a.nyc.gov. rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN NSEC3 1 0 8 4C44934802D3 RQDJO8PKJ2LEUMC30SGU45DDI643G497 NS rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN RRSIG NSEC3 7 2 86400 20110227210022 2011010022 47602 gov. ENl60LTdlJfmyDp9wrwh6bQao8TvqTk8hX4qD6x4bHGBixjsGhOy/si8 JVUl1MbeJ1PaJ3p59/ABFUv7ApOh5v6eflzhsBa6EalBrYCC5HpOabJn Q2r0RFqDvUb1Qo921cnbC+3Bh37i3DVTbK+poYpIkbpJAxOE
Re: [SOLVED] Re: BIND9 SERVFAIL on some .gov addresses
In PIX versions 6.3.2 and below you had to do: fixup protocol dns maximum-length 4096 In later versions you need: policy-map type inspect dns preset_dns_map parameters message-length maximum 4096 or to increase the response size length: policy-map global_policy class inspection_default inspect dns maximum-length 4096 This is rumor and innuendo, I personally believe that: a: firewalls with ALGs are the devil b: this goes double for PIX / ASA and c: doubled again for putting them in front of servers, especially DNS servers W On Feb 23, 2011, at 1:13 PM, Ryan Novosielski wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A couple more gems: https://www.dnssec-deployment.org/wp-content/uploads/2010/03/DNSSEC-CPE-Report.pdf (really anything at dnssec-deployment.org) There was another table that I found someplace and cannot find now that listed Cisco PIX and mentioned with a * the subtle difference between versions of that firewall firmware. I can't find that table anywhere -- was HTML, not in a PDF. On 02/23/2011 11:39 AM, Ryan Novosielski wrote: Take a look at this. It is somewhat confusing, but it is helpful and should tell you right away if you definitely have a firewall issue (and frankly there's little else it could be). https://www.dns-oarc.net/oarc/services/replysizetest On 02/23/2011 11:15 AM, Shaoquan Lin wrote: Thanks, Mark, Last June I asked our firewall person to make sure our firewall not blocking DNS packets over 512 bytes. He told me our firewall was not blocking. I guess that might be some default setting of the firewall and he does not really know. I did two digs here one with +dnssec and one without. I got the the following: 1) with +dnssec : ; <<>> DiG 9.6.1-P3 <<>> +norec vwall4a.nyc.gov @b.gov-servers.net +dnssec ;; global options: +cmd ;; connection timed out; no servers could be reached 2) without +dnssec : ; <<>> DiG 9.6.1-P3 <<>> +norec vwall4a.nyc.gov @b.gov-servers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2024 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;vwall4a.nyc.gov. IN A ;; AUTHORITY SECTION: nyc.gov.86400 IN NS vwall1a.nyc.gov. nyc.gov.86400 IN NS vwall2a.nyc.gov. nyc.gov.86400 IN NS vwall3a.nyc.gov. nyc.gov.86400 IN NS vwall4a.nyc.gov. ;; ADDITIONAL SECTION: vwall1a.nyc.gov.86400 IN A 161.185.1.3 vwall2a.nyc.gov.86400 IN A 161.185.1.12 vwall3a.nyc.gov.86400 IN A 167.153.130.12 vwall4a.nyc.gov.86400 IN A 167.153.130.13 ;; Query time: 31 msec ;; SERVER: 209.112.123.30#53(209.112.123.30) ;; WHEN: Wed Feb 23 11:12:48 2011 ;; MSG SIZE rcvd: 192 Does this show we do have a firewall problem here? Shaoquan Lin Mark Andrews wrote: In message <0539E64AD2B54AD2804C2394F923800B@se179>, "Shaoquan Lin" writes: Mark, Are these bugs (2784 and 1804) fixed by BIND 9.6.1-P3? My problem is that I can not get A records of NSs (like vwall4a.nyc.gov) of nyc.gov from b.gov-servers.net by BIND 9.6.1-P3 but with no problem with older BINDs like 9.3. I don't know if the problem is with the authoritative nameservers for gov or the nameservers for nyc.gov or with the BIND I am using. I noticed the following: Just fix your firewalls to allow EDNS responses through. While this is a bug in the authoritative servers / interpretation of RFC 1034, its only a issue because your firewall configuration is a decade out of date that it is a problem. 1). a.gov-servers.net or b.gov-servers.net does provide A records in the additional records of their responses for other subdomain under gov like treas.gov, just not nyc.gov. So the problem seems with nameservers for nyc.gov. The problem is relatively new and there might be some recent changes on nyc.gov. The gov servers will return glue if you let bigger answers than 512 bytes through your firewall. ; <<>> DiG 9.6.0-APPLE-P2 <<>> +norec vwall4a.nyc.gov @b.gov-servers.net +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50028 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1472 ;; QUESTION SECTION: ;vwall4a.nyc.gov.INA ;; AUTHORITY SECTION: nyc.gov.86400INNSvwall1a.nyc.gov. nyc.gov.86400INNSvwall2a.nyc.gov. nyc.gov.86400INNSvwall3a.nyc.gov. nyc.gov.86400INNSvwall4a.nyc.gov. rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN NSEC3 1 0 8 4C44934802D3 RQDJO8PKJ2LEUMC30SGU45DDI643G497 NS rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN RRSIG NSEC3 7 2 86400 20110227210022 2011010022 47602 gov. ENl60LTdlJfmyDp9wrwh6bQao8TvqTk8hX4qD6x4bHGBixjsGhOy/
Re: [SOLVED] Re: BIND9 SERVFAIL on some .gov addresses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A couple more gems: https://www.dnssec-deployment.org/wp-content/uploads/2010/03/DNSSEC-CPE-Report.pdf (really anything at dnssec-deployment.org) There was another table that I found someplace and cannot find now that listed Cisco PIX and mentioned with a * the subtle difference between versions of that firewall firmware. I can't find that table anywhere -- was HTML, not in a PDF. On 02/23/2011 11:39 AM, Ryan Novosielski wrote: > Take a look at this. It is somewhat confusing, but it is helpful and > should tell you right away if you definitely have a firewall issue (and > frankly there's little else it could be). > > https://www.dns-oarc.net/oarc/services/replysizetest > > On 02/23/2011 11:15 AM, Shaoquan Lin wrote: >> Thanks, Mark, > >> Last June I asked our firewall person to make sure our firewall not >> blocking DNS packets over 512 bytes. He told me our firewall was not >> blocking. I guess that might be some default setting of the firewall >> and he does not really know. I did two digs here one with +dnssec and >> one without. I got the the following: > >> 1) with +dnssec : >> ; <<>> DiG 9.6.1-P3 <<>> +norec vwall4a.nyc.gov @b.gov-servers.net +dnssec >> ;; global options: +cmd >> ;; connection timed out; no servers could be reached > >> 2) without +dnssec : >> ; <<>> DiG 9.6.1-P3 <<>> +norec vwall4a.nyc.gov @b.gov-servers.net >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2024 >> ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4 > >> ;; QUESTION SECTION: >> ;vwall4a.nyc.gov. IN A > >> ;; AUTHORITY SECTION: >> nyc.gov.86400 IN NS vwall1a.nyc.gov. >> nyc.gov.86400 IN NS vwall2a.nyc.gov. >> nyc.gov.86400 IN NS vwall3a.nyc.gov. >> nyc.gov.86400 IN NS vwall4a.nyc.gov. > >> ;; ADDITIONAL SECTION: >> vwall1a.nyc.gov.86400 IN A 161.185.1.3 >> vwall2a.nyc.gov.86400 IN A 161.185.1.12 >> vwall3a.nyc.gov.86400 IN A 167.153.130.12 >> vwall4a.nyc.gov.86400 IN A 167.153.130.13 > >> ;; Query time: 31 msec >> ;; SERVER: 209.112.123.30#53(209.112.123.30) >> ;; WHEN: Wed Feb 23 11:12:48 2011 >> ;; MSG SIZE rcvd: 192 > >> Does this show we do have a firewall problem here? > >> Shaoquan Lin > >> Mark Andrews wrote: >>> In message <0539E64AD2B54AD2804C2394F923800B@se179>, "Shaoquan Lin" >>> writes: >>> Mark, Are these bugs (2784 and 1804) fixed by BIND 9.6.1-P3? My problem is that I can not get A records of NSs (like vwall4a.nyc.gov) of nyc.gov from b.gov-servers.net by BIND 9.6.1-P3 but with no problem with older BINDs like 9.3. I don't know if the problem is with the authoritative nameservers for gov or the nameservers for nyc.gov or with the BIND I am using. I noticed the following: >>> >>> Just fix your firewalls to allow EDNS responses through. While >>> this is a bug in the authoritative servers / interpretation of >>> RFC 1034, its only a issue because your firewall configuration >>> is a decade out of date that it is a problem. >>> >>> 1). a.gov-servers.net or b.gov-servers.net does provide A records in the additional records of their responses for other subdomain under gov like treas.gov, just not nyc.gov. So the problem seems with nameservers for nyc.gov. The problem is relatively new and there might be some recent changes on nyc.gov. >>> >>> The gov servers will return glue if you let bigger answers than 512 bytes >>> through your firewall. >>> >>> ; <<>> DiG 9.6.0-APPLE-P2 <<>> +norec vwall4a.nyc.gov >>> @b.gov-servers.net +dnssec >>> ;; global options: +cmd >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50028 >>> ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 5 >>> >>> ;; OPT PSEUDOSECTION: >>> ; EDNS: version: 0, flags:; udp: 1472 >>> ;; QUESTION SECTION: >>> ;vwall4a.nyc.gov.INA >>> >>> ;; AUTHORITY SECTION: >>> nyc.gov.86400INNSvwall1a.nyc.gov. >>> nyc.gov.86400INNSvwall2a.nyc.gov. >>> nyc.gov.86400INNSvwall3a.nyc.gov. >>> nyc.gov.86400INNSvwall4a.nyc.gov. >>> rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN NSEC3 1 0 8 >>> 4C44934802D3 RQDJO8PKJ2LEUMC30SGU45DDI643G497 NS >>> rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN RRSIG NSEC3 7 2 86400 >>> 20110227210022 2011010022 47602 gov. >>> ENl60LTdlJfmyDp9wrwh6bQao8TvqTk8hX4qD6x4bHGBixjsGhOy/si8 >>> JVUl1MbeJ1PaJ3p59/ABFUv7ApOh5v6eflzhsBa6EalBrYCC5HpOabJn >>> Q2r0RFqDvUb1Qo921cnbC+3Bh37i3DVTbK+poYpIkbpJAxOE+/zp/PrA >>> 1L0v2kuS9t6gHLk+ZzfsQI6Gi9Ezg2VZIhVXGz06a7EzyGy2BZ/Plz4u >>> In2Dj5ncwAlAi9dC6xiQTW2yRmVSQoXzNZKUcZO+E0mPKPR9DcNVotX9 >>> CzTbrOyKNtYrrV6GNslN5qicuHIehriQIMPdXs3/
Re: [SOLVED] Re: BIND9 SERVFAIL on some .gov addresses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Take a look at this. It is somewhat confusing, but it is helpful and should tell you right away if you definitely have a firewall issue (and frankly there's little else it could be). https://www.dns-oarc.net/oarc/services/replysizetest On 02/23/2011 11:15 AM, Shaoquan Lin wrote: > Thanks, Mark, > > Last June I asked our firewall person to make sure our firewall not > blocking DNS packets over 512 bytes. He told me our firewall was not > blocking. I guess that might be some default setting of the firewall > and he does not really know. I did two digs here one with +dnssec and > one without. I got the the following: > > 1) with +dnssec : > ; <<>> DiG 9.6.1-P3 <<>> +norec vwall4a.nyc.gov @b.gov-servers.net +dnssec > ;; global options: +cmd > ;; connection timed out; no servers could be reached > > 2) without +dnssec : > ; <<>> DiG 9.6.1-P3 <<>> +norec vwall4a.nyc.gov @b.gov-servers.net > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2024 > ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4 > > ;; QUESTION SECTION: > ;vwall4a.nyc.gov. IN A > > ;; AUTHORITY SECTION: > nyc.gov.86400 IN NS vwall1a.nyc.gov. > nyc.gov.86400 IN NS vwall2a.nyc.gov. > nyc.gov.86400 IN NS vwall3a.nyc.gov. > nyc.gov.86400 IN NS vwall4a.nyc.gov. > > ;; ADDITIONAL SECTION: > vwall1a.nyc.gov.86400 IN A 161.185.1.3 > vwall2a.nyc.gov.86400 IN A 161.185.1.12 > vwall3a.nyc.gov.86400 IN A 167.153.130.12 > vwall4a.nyc.gov.86400 IN A 167.153.130.13 > > ;; Query time: 31 msec > ;; SERVER: 209.112.123.30#53(209.112.123.30) > ;; WHEN: Wed Feb 23 11:12:48 2011 > ;; MSG SIZE rcvd: 192 > > Does this show we do have a firewall problem here? > > Shaoquan Lin > > Mark Andrews wrote: >> In message <0539E64AD2B54AD2804C2394F923800B@se179>, "Shaoquan Lin" >> writes: >> >>> Mark, >>> >>> Are these bugs (2784 and 1804) fixed by BIND 9.6.1-P3? My problem is >>> that I >>> can not get A records of NSs (like vwall4a.nyc.gov) of nyc.gov from >>> b.gov-servers.net by BIND 9.6.1-P3 but with no problem with older >>> BINDs like >>> 9.3. I don't know if the problem is with the authoritative >>> nameservers for gov or the nameservers for nyc.gov or with the BIND I >>> am using. I noticed the following: >>> >> >> Just fix your firewalls to allow EDNS responses through. While >> this is a bug in the authoritative servers / interpretation of >> RFC 1034, its only a issue because your firewall configuration >> is a decade out of date that it is a problem. >> >> >>> 1). a.gov-servers.net or b.gov-servers.net does provide A records >>> in the additional records of their responses for other subdomain >>> under gov like treas.gov, just not nyc.gov. So the problem seems >>> with nameservers for nyc.gov. The problem is relatively new and >>> there might be some recent changes on nyc.gov. >>> >> >> The gov servers will return glue if you let bigger answers than 512 bytes >> through your firewall. >> >> ; <<>> DiG 9.6.0-APPLE-P2 <<>> +norec vwall4a.nyc.gov >> @b.gov-servers.net +dnssec >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50028 >> ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 5 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 1472 >> ;; QUESTION SECTION: >> ;vwall4a.nyc.gov.INA >> >> ;; AUTHORITY SECTION: >> nyc.gov.86400INNSvwall1a.nyc.gov. >> nyc.gov.86400INNSvwall2a.nyc.gov. >> nyc.gov.86400INNSvwall3a.nyc.gov. >> nyc.gov.86400INNSvwall4a.nyc.gov. >> rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN NSEC3 1 0 8 >> 4C44934802D3 RQDJO8PKJ2LEUMC30SGU45DDI643G497 NS >> rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN RRSIG NSEC3 7 2 86400 >> 20110227210022 2011010022 47602 gov. >> ENl60LTdlJfmyDp9wrwh6bQao8TvqTk8hX4qD6x4bHGBixjsGhOy/si8 >> JVUl1MbeJ1PaJ3p59/ABFUv7ApOh5v6eflzhsBa6EalBrYCC5HpOabJn >> Q2r0RFqDvUb1Qo921cnbC+3Bh37i3DVTbK+poYpIkbpJAxOE+/zp/PrA >> 1L0v2kuS9t6gHLk+ZzfsQI6Gi9Ezg2VZIhVXGz06a7EzyGy2BZ/Plz4u >> In2Dj5ncwAlAi9dC6xiQTW2yRmVSQoXzNZKUcZO+E0mPKPR9DcNVotX9 >> CzTbrOyKNtYrrV6GNslN5qicuHIehriQIMPdXs3/e2ZhB3h944kpymqL ag3tCg== >> >> ;; ADDITIONAL SECTION: >> vwall1a.nyc.gov.86400INA161.185.1.3 >> vwall2a.nyc.gov.86400INA161.185.1.12 >> vwall3a.nyc.gov.86400INA167.153.130.12 >> vwall4a.nyc.gov.86400INA167.153.130.13 >> >> ;; Query time: 187 msec >> ;; SERVER: 209.112.123.30#53(209.112.123.30) >> ;; WHEN: Wed Feb 23 11:54:06 2011 >> ;; MSG SIZE rcvd: 574 >> >> >>> 2) Older version of Binds (like 9.3) seems able to resolve >>> vwall4a.nyc.gov as shown the packets I cap
Re: [SOLVED] Re: BIND9 SERVFAIL on some .gov addresses
Thanks, Mark, Last June I asked our firewall person to make sure our firewall not blocking DNS packets over 512 bytes. He told me our firewall was not blocking. I guess that might be some default setting of the firewall and he does not really know. I did two digs here one with +dnssec and one without. I got the the following: 1) with +dnssec : ; <<>> DiG 9.6.1-P3 <<>> +norec vwall4a.nyc.gov @b.gov-servers.net +dnssec ;; global options: +cmd ;; connection timed out; no servers could be reached 2) without +dnssec : ; <<>> DiG 9.6.1-P3 <<>> +norec vwall4a.nyc.gov @b.gov-servers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2024 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4 ;; QUESTION SECTION: ;vwall4a.nyc.gov. IN A ;; AUTHORITY SECTION: nyc.gov.86400 IN NS vwall1a.nyc.gov. nyc.gov.86400 IN NS vwall2a.nyc.gov. nyc.gov.86400 IN NS vwall3a.nyc.gov. nyc.gov.86400 IN NS vwall4a.nyc.gov. ;; ADDITIONAL SECTION: vwall1a.nyc.gov.86400 IN A 161.185.1.3 vwall2a.nyc.gov.86400 IN A 161.185.1.12 vwall3a.nyc.gov.86400 IN A 167.153.130.12 vwall4a.nyc.gov.86400 IN A 167.153.130.13 ;; Query time: 31 msec ;; SERVER: 209.112.123.30#53(209.112.123.30) ;; WHEN: Wed Feb 23 11:12:48 2011 ;; MSG SIZE rcvd: 192 Does this show we do have a firewall problem here? Shaoquan Lin Mark Andrews wrote: In message <0539E64AD2B54AD2804C2394F923800B@se179>, "Shaoquan Lin" writes: Mark, Are these bugs (2784 and 1804) fixed by BIND 9.6.1-P3? My problem is that I can not get A records of NSs (like vwall4a.nyc.gov) of nyc.gov from b.gov-servers.net by BIND 9.6.1-P3 but with no problem with older BINDs like 9.3. I don't know if the problem is with the authoritative nameservers for gov or the nameservers for nyc.gov or with the BIND I am using. I noticed the following: Just fix your firewalls to allow EDNS responses through. While this is a bug in the authoritative servers / interpretation of RFC 1034, its only a issue because your firewall configuration is a decade out of date that it is a problem. 1). a.gov-servers.net or b.gov-servers.net does provide A records in the additional records of their responses for other subdomain under gov like treas.gov, just not nyc.gov. So the problem seems with nameservers for nyc.gov. The problem is relatively new and there might be some recent changes on nyc.gov. The gov servers will return glue if you let bigger answers than 512 bytes through your firewall. ; <<>> DiG 9.6.0-APPLE-P2 <<>> +norec vwall4a.nyc.gov @b.gov-servers.net +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50028 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1472 ;; QUESTION SECTION: ;vwall4a.nyc.gov. IN A ;; AUTHORITY SECTION: nyc.gov.86400 IN NS vwall1a.nyc.gov. nyc.gov.86400 IN NS vwall2a.nyc.gov. nyc.gov.86400 IN NS vwall3a.nyc.gov. nyc.gov.86400 IN NS vwall4a.nyc.gov. rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN NSEC3 1 0 8 4C44934802D3 RQDJO8PKJ2LEUMC30SGU45DDI643G497 NS rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN RRSIG NSEC3 7 2 86400 20110227210022 2011010022 47602 gov. ENl60LTdlJfmyDp9wrwh6bQao8TvqTk8hX4qD6x4bHGBixjsGhOy/si8 JVUl1MbeJ1PaJ3p59/ABFUv7ApOh5v6eflzhsBa6EalBrYCC5HpOabJn Q2r0RFqDvUb1Qo921cnbC+3Bh37i3DVTbK+poYpIkbpJAxOE+/zp/PrA 1L0v2kuS9t6gHLk+ZzfsQI6Gi9Ezg2VZIhVXGz06a7EzyGy2BZ/Plz4u In2Dj5ncwAlAi9dC6xiQTW2yRmVSQoXzNZKUcZO+E0mPKPR9DcNVotX9 CzTbrOyKNtYrrV6GNslN5qicuHIehriQIMPdXs3/e2ZhB3h944kpymqL ag3tCg== ;; ADDITIONAL SECTION: vwall1a.nyc.gov.86400 IN A 161.185.1.3 vwall2a.nyc.gov.86400 IN A 161.185.1.12 vwall3a.nyc.gov.86400 IN A 167.153.130.12 vwall4a.nyc.gov.86400 IN A 167.153.130.13 ;; Query time: 187 msec ;; SERVER: 209.112.123.30#53(209.112.123.30) ;; WHEN: Wed Feb 23 11:54:06 2011 ;; MSG SIZE rcvd: 574 2) Older version of Binds (like 9.3) seems able to resolve vwall4a.nyc.gov as shown the packets I captured in my previous e-mail. What options in named.conf I can use to set "tc"? Thank you. Shaoquan Lin -- Shaoquan Lin, Computer Systems Manager School of Engineering, City College of New York Phone: (212) 650 6762 Fax: (212) 650 5768 E-mail: l...@ccny.cuny.edu ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [SOLVED] Re: BIND9 SERVFAIL on some .gov addresses
In message <0539E64AD2B54AD2804C2394F923800B@se179>, "Shaoquan Lin" writes: > Mark, > > Are these bugs (2784 and 1804) fixed by BIND 9.6.1-P3? My problem is that I > can not get A records of NSs (like vwall4a.nyc.gov) of nyc.gov from > b.gov-servers.net by BIND 9.6.1-P3 but with no problem with older BINDs like > 9.3. I don't know if the problem is with the authoritative nameservers for > gov or the nameservers for nyc.gov or with the BIND I am using. I noticed > the following: Just fix your firewalls to allow EDNS responses through. While this is a bug in the authoritative servers / interpretation of RFC 1034, its only a issue because your firewall configuration is a decade out of date that it is a problem. > 1). a.gov-servers.net or b.gov-servers.net does provide A records in the > additional records of their responses for other subdomain under gov like > treas.gov, just not nyc.gov. So the problem seems with nameservers for > nyc.gov. The problem is relatively new and there might be some recent > changes on nyc.gov. The gov servers will return glue if you let bigger answers than 512 bytes through your firewall. ; <<>> DiG 9.6.0-APPLE-P2 <<>> +norec vwall4a.nyc.gov @b.gov-servers.net +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50028 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1472 ;; QUESTION SECTION: ;vwall4a.nyc.gov. IN A ;; AUTHORITY SECTION: nyc.gov.86400 IN NS vwall1a.nyc.gov. nyc.gov.86400 IN NS vwall2a.nyc.gov. nyc.gov.86400 IN NS vwall3a.nyc.gov. nyc.gov.86400 IN NS vwall4a.nyc.gov. rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN NSEC3 1 0 8 4C44934802D3 RQDJO8PKJ2LEUMC30SGU45DDI643G497 NS rq2651faaj4nen6tfis8ju5005qccn8j.gov. 86400 IN RRSIG NSEC3 7 2 86400 20110227210022 2011010022 47602 gov. ENl60LTdlJfmyDp9wrwh6bQao8TvqTk8hX4qD6x4bHGBixjsGhOy/si8 JVUl1MbeJ1PaJ3p59/ABFUv7ApOh5v6eflzhsBa6EalBrYCC5HpOabJn Q2r0RFqDvUb1Qo921cnbC+3Bh37i3DVTbK+poYpIkbpJAxOE+/zp/PrA 1L0v2kuS9t6gHLk+ZzfsQI6Gi9Ezg2VZIhVXGz06a7EzyGy2BZ/Plz4u In2Dj5ncwAlAi9dC6xiQTW2yRmVSQoXzNZKUcZO+E0mPKPR9DcNVotX9 CzTbrOyKNtYrrV6GNslN5qicuHIehriQIMPdXs3/e2ZhB3h944kpymqL ag3tCg== ;; ADDITIONAL SECTION: vwall1a.nyc.gov.86400 IN A 161.185.1.3 vwall2a.nyc.gov.86400 IN A 161.185.1.12 vwall3a.nyc.gov.86400 IN A 167.153.130.12 vwall4a.nyc.gov.86400 IN A 167.153.130.13 ;; Query time: 187 msec ;; SERVER: 209.112.123.30#53(209.112.123.30) ;; WHEN: Wed Feb 23 11:54:06 2011 ;; MSG SIZE rcvd: 574 > 2) Older version of Binds (like 9.3) seems able to resolve vwall4a.nyc.gov > as shown the packets I captured in my previous e-mail. > > What options in named.conf I can use to set "tc"? > > Thank you. > > Shaoquan Lin -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [SOLVED] Re: BIND9 SERVFAIL on some .gov addresses
Mark,
Are these bugs (2784 and 1804) fixed by BIND 9.6.1-P3? My problem is that I
can not get A records of NSs (like vwall4a.nyc.gov) of nyc.gov from
b.gov-servers.net by BIND 9.6.1-P3 but with no problem with older BINDs like
9.3. I don't know if the problem is with the authoritative nameservers for
gov or the nameservers for nyc.gov or with the BIND I am using. I noticed
the following:
1). a.gov-servers.net or b.gov-servers.net does provide A records in the
additional records of their responses for other subdomain under gov like
treas.gov, just not nyc.gov. So the problem seems with nameservers for
nyc.gov. The problem is relatively new and there might be some recent
changes on nyc.gov.
2) Older version of Binds (like 9.3) seems able to resolve vwall4a.nyc.gov
as shown the packets I captured in my previous e-mail.
What options in named.conf I can use to set "tc"?
Thank you.
Shaoquan Lin
- Original Message -
From: "Mark Andrews"
To: "Shaoquan Lin"
Cc:
Sent: Saturday, February 19, 2011 6:08 AM
Subject: Re: [SOLVED] Re: BIND9 SERVFAIL on some .gov addresses
In message <17894D6D30484DDFBBE95BEF987FF5D1@se179>, "Shaoquan Lin"
writes:
Ryan,
Have you solved your problem? I have similar problems. I run BIND =
9.6..1-P3 on my Solaris 10 and can not resolve anything in domain =
nyc.gov. One thing I noticed is: BIND 9.3 send query to =
b.gov-servers.net with no Additional records and got a response with A =
records for the nyc.gov NS servers in the Additional records; but BIND =
9.6 send query with type OPT Additional records and got a response with =
also a type OPT but no A in the Additional records. So the BIND 9.6 can
=
not find the IP addresses of the nyc.gov NS servers and therefore can =
not resolve anything in that domain. Using options "max-udp-size 512" =
and "edns-udp-size 512" does not solve the problem.
The following are the what I captured. Anyone have any suggestions to =
solve the problem? =20
Shaoquan Lin
This is really a DNS protocol bug. Glue is not optional when
returning a referral and failure to add glue should result in
"tc" being set.
Note: named should set "tc" in the case to work around this protocol
bug. It's useful to have a real life example rather than a contrived
example.
2784. [bug] TC was not always being set when required glue was
dropped. [RT #20655]
1804. [bug] Ensure that if we are queried for glue that it
fits
in the additional section or TC is set to tell the
client to retry using TCP. [RT #10114]
BIND 9.3 query:
Domain Name System (query)
Transaction ID: 0x94ca
Flags: 0x (Standard query)
0... =3D Response: Message is a query
.000 0... =3D Opcode: Standard query (0)
..0. =3D Truncated: Message is not truncated
...0 =3D Recursion desired: Don't do query recursively
.0.. =3D Z: reserved (0)
...0 =3D Non-authenticated data OK: Non-authenticated =
data is unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
vwall4a.nyc.gov: type A, class IN
Name: vwall4a.nyc.gov
Type: A (Host address)
Class: IN (0x0001)
BIND 9.3 response:
Domain Name System (response)
Transaction ID: 0x94ca
Flags: 0x8000 (Standard query response, No error)
1... =3D Response: Message is a response
.000 0... =3D Opcode: Standard query (0)
.0.. =3D Authoritative: Server is not an authority for =
domain
..0. =3D Truncated: Message is not truncated
...0 =3D Recursion desired: Don't do query recursively
0... =3D Recursion available: Server can't do recursive =
queries
.0.. =3D Z: reserved (0)
..0. =3D Answer authenticated: Answer/authority portion =
was not authenticated by the server
=3D Reply code: No error (0)
Questions: 1
Answer RRs: 0
Authority RRs: 4
Additional RRs: 4
Queries
vwall4a.nyc.gov: type A, class IN
Name: vwall4a.nyc.gov
Type: A (Host address)
Class: IN (0x0001)
Authoritative nameservers
nyc.gov: type NS, class IN, ns vwall1a.nyc.gov
Name: nyc.gov
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 day
Data length: 10
Name server: vwall1a.nyc.gov
nyc.gov: type NS, class IN, ns vwall2a.nyc.gov
Name: nyc.gov
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 day
Data length: 10
Name server: vwall2a.nyc.gov
nyc.gov: type NS, class IN, ns vwall3a.nyc.gov
Name: nyc.gov
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 day
Data length: 10
Name server: vwall3a.nyc.gov
nyc.gov: type NS, class IN, ns vwall4a.nyc.gov
Name: nyc.gov
Type: NS (Authoritative n
Re: [SOLVED] Re: BIND9 SERVFAIL on some .gov addresses
In message <17894D6D30484DDFBBE95BEF987FF5D1@se179>, "Shaoquan Lin" writes: > Ryan, > > Have you solved your problem? I have similar problems. I run BIND = > 9.6..1-P3 on my Solaris 10 and can not resolve anything in domain = > nyc.gov. One thing I noticed is: BIND 9.3 send query to = > b.gov-servers.net with no Additional records and got a response with A = > records for the nyc.gov NS servers in the Additional records; but BIND = > 9.6 send query with type OPT Additional records and got a response with = > also a type OPT but no A in the Additional records. So the BIND 9.6 can = > not find the IP addresses of the nyc.gov NS servers and therefore can = > not resolve anything in that domain. Using options "max-udp-size 512" = > and "edns-udp-size 512" does not solve the problem. > > The following are the what I captured. Anyone have any suggestions to = > solve the problem? =20 > > Shaoquan Lin This is really a DNS protocol bug. Glue is not optional when returning a referral and failure to add glue should result in "tc" being set. Note: named should set "tc" in the case to work around this protocol bug. It's useful to have a real life example rather than a contrived example. 2784. [bug] TC was not always being set when required glue was dropped. [RT #20655] 1804. [bug] Ensure that if we are queried for glue that it fits in the additional section or TC is set to tell the client to retry using TCP. [RT #10114] > BIND 9.3 query: > Domain Name System (query) > > Transaction ID: 0x94ca > > Flags: 0x (Standard query) > > 0... =3D Response: Message is a query > > .000 0... =3D Opcode: Standard query (0) > > ..0. =3D Truncated: Message is not truncated > > ...0 =3D Recursion desired: Don't do query recursively > > .0.. =3D Z: reserved (0) > > ...0 =3D Non-authenticated data OK: Non-authenticated = > data is unacceptable > > Questions: 1 > > Answer RRs: 0 > > Authority RRs: 0 > > Additional RRs: 0 > > Queries > > vwall4a.nyc.gov: type A, class IN > > Name: vwall4a.nyc.gov > > Type: A (Host address) > > Class: IN (0x0001) > > BIND 9.3 response: > > Domain Name System (response) > > Transaction ID: 0x94ca > > Flags: 0x8000 (Standard query response, No error) > > 1... =3D Response: Message is a response > > .000 0... =3D Opcode: Standard query (0) > > .0.. =3D Authoritative: Server is not an authority for = > domain > > ..0. =3D Truncated: Message is not truncated > > ...0 =3D Recursion desired: Don't do query recursively > > 0... =3D Recursion available: Server can't do recursive = > queries > > .0.. =3D Z: reserved (0) > > ..0. =3D Answer authenticated: Answer/authority portion = > was not authenticated by the server > > =3D Reply code: No error (0) > > Questions: 1 > > Answer RRs: 0 > > Authority RRs: 4 > > Additional RRs: 4 > > Queries > > vwall4a.nyc.gov: type A, class IN > > Name: vwall4a.nyc.gov > > Type: A (Host address) > > Class: IN (0x0001) > > Authoritative nameservers > > nyc.gov: type NS, class IN, ns vwall1a.nyc.gov > > Name: nyc.gov > > Type: NS (Authoritative name server) > > Class: IN (0x0001) > > Time to live: 1 day > > Data length: 10 > > Name server: vwall1a.nyc.gov > > nyc.gov: type NS, class IN, ns vwall2a.nyc.gov > > Name: nyc.gov > > Type: NS (Authoritative name server) > > Class: IN (0x0001) > > Time to live: 1 day > > Data length: 10 > > Name server: vwall2a.nyc.gov > > nyc.gov: type NS, class IN, ns vwall3a.nyc.gov > > Name: nyc.gov > > Type: NS (Authoritative name server) > > Class: IN (0x0001) > > Time to live: 1 day > > Data length: 10 > > Name server: vwall3a.nyc.gov > > nyc.gov: type NS, class IN, ns vwall4a.nyc.gov > > Name: nyc.gov > > Type: NS (Authoritative name server) > > Class: IN (0x0001) > > Time to live: 1 day > > Data length: 10 > > Name server: vwall4a.nyc.gov > > Additional records > > vwall1a.nyc.gov: type A, class IN, addr 161.185.1.3 > > Name: vwall1a.nyc.gov > > Type: A (Host address) > > Class: IN (0x0001) > > Time to live: 1 day > > Data length: 4 > > Addr: 161.185.1.3 > > vwall2a.nyc.gov: type A, class IN, addr 161.185.1.12 > > Name: vwall2a.nyc.gov > > Type: A (Host address) > > Class: IN (0x0001) > > Time to live: 1 day > > Data length: 4 > > Addr: 161.185.1.12 > > vwall3a.nyc.gov: type A, class IN, addr 167.153.130.12 > > Name: vwall3a.nyc.gov > > Type: A (Host address) > > Class: IN (0x0001) > > Time to live: 1 day > > Data length: 4 > > Addr: 167.153.130.12 > > vwall4a.nyc.gov: type A, class IN, addr 167.153.130.13 > > Name: vwall4a.nyc.gov > > Type: A (Host address) > > Class: IN (0x0001) > > Time to live: 1 day > > Data
Re: [SOLVED] Re: BIND9 SERVFAIL on some .gov addresses
Ryan,
Have you solved your problem? I have similar problems. I run BIND 9.6..1-P3 on
my Solaris 10 and can not resolve anything in domain nyc.gov. One thing I
noticed is: BIND 9.3 send query to b.gov-servers.net with no Additional
records and got a response with A records for the nyc.gov NS servers in the
Additional records; but BIND 9.6 send query with type OPT Additional records
and got a response with also a type OPT but no A in the Additional records. So
the BIND 9.6 can not find the IP addresses of the nyc.gov NS servers and
therefore can not resolve anything in that domain. Using options "max-udp-size
512" and "edns-udp-size 512" does not solve the problem.
The following are the what I captured. Anyone have any suggestions to solve
the problem?
Shaoquan Lin
BIND 9.3 query:
Domain Name System (query)
Transaction ID: 0x94ca
Flags: 0x (Standard query)
0... = Response: Message is a query
.000 0... = Opcode: Standard query (0)
..0. = Truncated: Message is not truncated
...0 = Recursion desired: Don't do query recursively
.0.. = Z: reserved (0)
...0 = Non-authenticated data OK: Non-authenticated data is
unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
vwall4a.nyc.gov: type A, class IN
Name: vwall4a.nyc.gov
Type: A (Host address)
Class: IN (0x0001)
BIND 9.3 response:
Domain Name System (response)
Transaction ID: 0x94ca
Flags: 0x8000 (Standard query response, No error)
1... = Response: Message is a response
.000 0... = Opcode: Standard query (0)
.0.. = Authoritative: Server is not an authority for domain
..0. = Truncated: Message is not truncated
...0 = Recursion desired: Don't do query recursively
0... = Recursion available: Server can't do recursive queries
.0.. = Z: reserved (0)
..0. = Answer authenticated: Answer/authority portion was not
authenticated by the server
= Reply code: No error (0)
Questions: 1
Answer RRs: 0
Authority RRs: 4
Additional RRs: 4
Queries
vwall4a.nyc.gov: type A, class IN
Name: vwall4a.nyc.gov
Type: A (Host address)
Class: IN (0x0001)
Authoritative nameservers
nyc.gov: type NS, class IN, ns vwall1a.nyc.gov
Name: nyc.gov
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 day
Data length: 10
Name server: vwall1a.nyc.gov
nyc.gov: type NS, class IN, ns vwall2a.nyc.gov
Name: nyc.gov
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 day
Data length: 10
Name server: vwall2a.nyc.gov
nyc.gov: type NS, class IN, ns vwall3a.nyc.gov
Name: nyc.gov
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 day
Data length: 10
Name server: vwall3a.nyc.gov
nyc.gov: type NS, class IN, ns vwall4a.nyc.gov
Name: nyc.gov
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 1 day
Data length: 10
Name server: vwall4a.nyc.gov
Additional records
vwall1a.nyc.gov: type A, class IN, addr 161.185.1.3
Name: vwall1a.nyc.gov
Type: A (Host address)
Class: IN (0x0001)
Time to live: 1 day
Data length: 4
Addr: 161.185.1.3
vwall2a.nyc.gov: type A, class IN, addr 161.185.1.12
Name: vwall2a.nyc.gov
Type: A (Host address)
Class: IN (0x0001)
Time to live: 1 day
Data length: 4
Addr: 161.185.1.12
vwall3a.nyc.gov: type A, class IN, addr 167.153.130.12
Name: vwall3a.nyc.gov
Type: A (Host address)
Class: IN (0x0001)
Time to live: 1 day
Data length: 4
Addr: 167.153.130.12
vwall4a.nyc.gov: type A, class IN, addr 167.153.130.13
Name: vwall4a.nyc.gov
Type: A (Host address)
Class: IN (0x0001)
Time to live: 1 day
Data length: 4
Addr: 167.153.130.13
BIND 9.6 query:
Domain Name System (query)
Transaction ID: 0x6427
Flags: 0x (Standard query)
0... = Response: Message is a query
.000 0... = Opcode: Standard query (0)
..0. = Truncated: Message is not truncated
...0 = Recursion desired: Don't do query recursively
.0.. = Z: reserved (0)
...0 = Non-authenticated data OK: Non-authenticated data is
unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 1
Queries
vwall4a.nyc.gov: type A, class IN
Name: vwall4a.nyc.gov
Type: A (Host address)
Class: IN (0x0001)
Additional records
: type OPT
Name:
Type: OPT (EDNS0 option)
UDP payload size: 512
Higher bits in extended RCODE: 0x0
EDNS0 version: 0
Z: 0x8000
Bit 0 (DO bit): 1 (Accepts DNSSEC security RRs)
Bits 1-15: 0x0 (reserved)
Data length: 0
BIND 9.6 response:
Domain Name System (response)
Transaction ID: 0x6427
Flags: 0x8000 (Standard query response, No error)
1... = Response: Message is a response
.000 0... = Opcode: Standard query (0)
.0.. = Authoritative:
Re: [SOLVED] Re: BIND9 SERVFAIL on some .gov addresses
max-udp-size controls what you send. MAX(512, MIN(max-udp-size, client's UDP size)) edns-udp-size controls what you advertise you can receive. MAX(512, MIN(edns-udp-size, server's UDP size)) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
