Re: Problems in views in a zone transfer
Hi all,
I have this configuration in the zone.conf:
view "VIEW1" {
match-clients {
10.112.25.184; // IPs you want to access this view
10.112.25.185; // Note: you must include the IP of
// the master to receive notifications.
};
server 10.112.25.184 {keys view1-resolver.; }; // master
zone "test.domain.pt" IN {
type slave;
notify no;
masters {10.112.25.184 port 40001;};
};
};
view "VIEW2" {
match-clients {
10.112.25.184; // IPs you want to access this view
10.112.25.186; // Note: you must include the IP of
// the master to receive notifications.
};
server 10.112.25.184 {keys view2-resolver.; }; // master
zone "test.domain.pt" IN {
type slave;
notify no;
masters {10.112.25.184 port 40001;};
};
};
And I sent a notify request to this element, with a TSIG key associated with
View2, but apparently it didn't work since it was View 1 o requested the
zone transfer. Checking the logs I've discovered this:
26-May-2011 15:24:09.506 notify: info: client 10.112.25.184#47627: view
VIEW1: received notify for zone 'test.domain.pt': TSIG 'view2-resolver'
Am I doing something wrong?
Many thanks,
Luis
On Tue, May 24, 2011 at 3:13 AM, Mark Andrews wrote:
>
> In message , Luis
> Silva wri
> tes:
> > Hi Steve,
> >
> > Many thanks for the answer. Just one question, when the master sends the
> > notification, does the slave checks all views and see if the tsig
> matches?
> >
> > Br,
> > Ls
>
> NOTIFY, UPDATE and QUERY messages are treated indentically in terms of
> view selection. i.e. first match.
>
> --
> 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
ISC BIND 9.8.1b1 is now available
__ Introduction BIND 9.8.1b1 is the first beta release of BIND 9.8.1, a maintenance release for BIND 9.8. Please see the CHANGES file in the source code release for a complete list of all changes. See below for a list of changes since 9.8.0. Download The latest versions of BIND 9 software can always be found on our web site at http://www.isc.org/downloads/all. There you will find additional information about each release, source code, and pre-compiled versions for certain operating systems. Support Product support information is available on http://www.isc.org/services/support for paid support options. Free support is provided by our user community via a mailing list. Information on all public email lists is available at https://lists.isc.org/mailman/listinfo. Thank You Thank you to everyone who assisted us in making this release possible. If you would like to contribute to ISC to assist us in continuing to make quality open source software, please visit our donations page at http://www.isc.org/supportisc. Known issues in this release: * Named can fail to return a complete CNAME chain when the CNAME record and its target are both within zones for which the server is authoritative. This only happens when named is configured to be recursive as well as authoritative, and only effects recursive clients. The failure happens infrequently, but once it has started happening the only fix is to restart named. The bug was fixed too late for inclusion in this beta release, but it will be included in the next release. All changes since 9.8.0: 3112. [doc] Add missing descriptions of the update policy name types "ms-self", "ms-subdomain", "krb5-self" and "krb5-subdomain", which allow machines to update their own records, to the BIND 9 ARM. 3111. [bug] Improved consistency checks for dnssec-enable and dnssec-validation, added test cases to the checkconf system test. [RT #24398] 3110. [bug] dnssec-signzone: Wrong error message could appear when attempting to sign with no KSK. [RT #24369] 3107. [bug] dnssec-signzone: Report the correct number of ZSKs when using -x. [RT #20852] 3105. [bug] GOST support can be suppressed by "configure --without-gost" [RT #24367] 3104. [bug] Better support for cross-compiling. [RT #24367] 3103. [bug] Configuring 'dnssec-validation auto' in a view instead of in the options statement could trigger an assertion failure in named-checkconf. [RT #24382] 3101. [bug] Zones using automatic key maintenance could fail to check the key repository for updates. [RT #23744] 3100. [security] Certain response policy zone configurations could trigger an INSIST when receiving a query of type RRSIG. [RT #24280] 3099. [test] "dlz" system test now runs but gives R:SKIPPED if not compiled with --with-dlz-filesystem. [RT #24146] 3098. [bug] DLZ zones were answering without setting the AA bit. [RT #24146] 3097. [test] Add a tool to test handling of malformed packets. [RT #24096] 3096. [bug] Set KRB5_KTNAME before calling log_cred() in dst_gssapi_acceptctx(). [RT #24004] 3095. [bug] Handle isolated reserved ports in the port range. [RT #23957] 3094. [doc] Expand dns64 documentation. 3093. [bug] Fix gssapi/kerberos dependencies [RT #23836] 3092. [bug] Signatures for records at the zone apex could go stale due to an incorrect timer setting. [RT #23769] 3091. [bug] Fixed a bug in which zone keys that were published and then subsequently activated could fail to trigger automatic signing. [RT #22911] 3090. [func] Make --with-gssapi default [RT #23738] 3088. [bug] Remove bin/tests/system/logfileconfig/ns1/named.conf and add setup.sh in order to resolve changing named.conf issue. [RT #23687] 3087. [bug] DDNS updates using SIG(0) with update-policy match type "external" could cause a crash. [RT #23735] 3086. [bug] Running dnssec-settime -f on an old-style key will now force an update to the new key format even if no other change
Re: Problems in views in a zone transfer
Hi all,
I think I have found a solution. Don't know if it is the best one:
For example, for view1 i added "!key view2-resolver;" to the match-clients.
view "VIEW1" {
match-clients {
!key view2-resolver.;
10.112.25.184; // IPs you want to access this view
10.112.25.185; // Note: you must include the IP of
// the master to receive notifications.
};
server 10.112.25.184 {keys view1-resolver.; }; // master
zone "test.domain.pt" IN {
type slave;
notify no;
masters {10.112.25.184 port 40001;};
};
};
Is there a best way?
Regards and thanks,
Luis
On Thu, May 26, 2011 at 3:32 PM, Luis Silva wrote:
> Hi all,
>
> I have this configuration in the zone.conf:
>
> view "VIEW1" {
>
>match-clients {
> 10.112.25.184; // IPs you want to access this view
> 10.112.25.185; // Note: you must include the IP of
> // the master to receive notifications.
> };
>
> server 10.112.25.184 {keys view1-resolver.; }; // master
>
> zone "test.domain.pt" IN {
> type slave;
> notify no;
> masters {10.112.25.184 port 40001;};
>};
> };
>
> view "VIEW2" {
>
>match-clients {
> 10.112.25.184; // IPs you want to access this view
> 10.112.25.186; // Note: you must include the IP of
> // the master to receive notifications.
> };
>
> server 10.112.25.184 {keys view2-resolver.; }; // master
>
> zone "test.domain.pt" IN {
> type slave;
> notify no;
> masters {10.112.25.184 port 40001;};
> };
> };
>
>
> And I sent a notify request to this element, with a TSIG key associated
> with View2, but apparently it didn't work since it was View 1 o requested
> the zone transfer. Checking the logs I've discovered this:
>
> 26-May-2011 15:24:09.506 notify: info: client 10.112.25.184#47627: view
> VIEW1: received notify for zone 'test.domain.pt': TSIG 'view2-resolver'
>
> Am I doing something wrong?
>
> Many thanks,
> Luis
>
>
> On Tue, May 24, 2011 at 3:13 AM, Mark Andrews wrote:
>
>>
>> In message , Luis
>> Silva wri
>> tes:
>> > Hi Steve,
>> >
>> > Many thanks for the answer. Just one question, when the master sends the
>> > notification, does the slave checks all views and see if the tsig
>> matches?
>> >
>> > Br,
>> > Ls
>>
>> NOTIFY, UPDATE and QUERY messages are treated indentically in terms of
>> view selection. i.e. first match.
>>
>> --
>> 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
Bug in bind 9.7.3?
Hi, I using bind 9.7.3 as resolver in a slightly larger server farm with some mail servers that use domain key validation. If a try # host -t TXT _adsp._domainkey.federalreserve.gov bind dies with May 26 19:59:02 resolv04 named[8237]: buffer.c:285: REQUIRE(b->used + 1 <= b->length) failed May 26 19:59:02 resolv04 named[8237]: exiting (due to assertion failure) This is reproducible and should only affected in 9.7.3. Can this be possible? kind regards Frank -- ++ Frank Kloeker Operations and Optimization of Internet Solutions (TZO) Vodafone D2 GmbH / Main Office Eschborn / Terminal B ++ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problems in views in a zone transfer
> server 10.112.25.184 {keys view1-resolver.; }; // master
>
> Is there a best way?
Your way is fine. You can also specify a key in the masters
statement, e.g:
view internal {
match-clients { !key external-key; internal-acl; };
zone example.com {
type slave;
masters { localhost key external-key; };
};
};
view external {
match-clients { any; };
zone example.com {
type master;
};
};
(Currently you can't specify a key in an also-notify statement but
that's being fixed in 9.9.)
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
recursive server querying authoritative - timeout before trying next server?
Hi, A question regarding BIND defaults. I'd love the same answer for other nameserver software if anyone cares to share. I am a recursive nameserver. I am looking for foo.bar.com. i've learned from bar.com that foo.bar.com has four NS records. I've never tried to talk to these servers before. I send a query to the address listed in the first NS record. I never get an answer? How long do I wait before trying the next one? I looked through several RFCs but couldn't find anything specific in the spec. RFC1035 mentions that choosing this timeout would be up to nameserver implementors and suggests 5-10 seconds as a reasonable default. my google-fu is failing me on this one. I found something at Microsoft that suggests that their DNS server waits 3 seconds although i may have interpreted that wrong. I found a reference to a nameserver called "deadwood" that defaults to 2 seconds. But, I couldn't find anything on BIND. thanks, danno -- Dan Pritts, Sr. Systems Engineer Internet2 office: +1-734-352-4953 | mobile: +1-734-834-7224 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bug in bind 9.7.3?
On Thu, 26 May 2011, Frank Kloeker wrote: Hi, I using bind 9.7.3 as resolver in a slightly larger server farm with some mail servers that use domain key validation. If a try # host -t TXT _adsp._domainkey.federalreserve.gov bind dies with May 26 19:59:02 resolv04 named[8237]: buffer.c:285: REQUIRE(b->used + 1 <= b->length) failed May 26 19:59:02 resolv04 named[8237]: exiting (due to assertion failure) This is reproducible and should only affected in 9.7.3. Can this be possible? Yes, UC Berkeley had 7 of 8 anycast servers die in the same way, and I do recall seeing exactly that query earlier in the stream. I think you're on to something, and I am looking into it further. michael ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bug in bind 9.7.3 [ and 9.8.0]
> # host -t TXT _adsp._domainkey.federalreserve.gov > > bind dies with > > May 26 19:59:02 resolv04 named[8237]: buffer.c:285: REQUIRE(b->used + 1 > <= b->length) failed > May 26 19:59:02 resolv04 named[8237]: exiting (due to assertion failure) > > This is reproducible and should only affected in 9.7.3. Can this be > possible? I've just reproduced the crash with the same query on 9.8.0 (on Mac OS/X, where BIND in fact took down the whole machine :-| As I'm sitting in a hotel room I'm only trying this once more...) I'm attaching my debug output, and Cc-ing this to bind-bugs. Best regards [ & bis bald :-], -JP 26-May-2011 20:57:29.882 starting BIND 9.8.0 -g 26-May-2011 20:57:29.882 built with '--prefix=/usr/local' '--with-libxml2' '--disable-threads' '--with-dlz-dlopen' '--with-gssapi' '--with-openssl=/usr/local/stow/openssl-1.0.0c/' '--with-pic' 26-May-2011 20:57:29.882 using up to 4096 sockets 26-May-2011 20:57:29.888 loading configuration from '/usr/local/etc/named.conf' 26-May-2011 20:57:29.890 reading built-in trusted keys from file '/usr/local/etc/bind.keys' 26-May-2011 20:57:29.890 statistics channel listening on 0.0.0.0#8053 26-May-2011 20:57:29.890 using default UDP/IPv4 port range: [49152, 65535] 26-May-2011 20:57:29.890 using default UDP/IPv6 port range: [49152, 65535] 26-May-2011 20:57:29.891 listening on IPv4 interface lo0, 127.0.0.1#53 26-May-2011 20:57:29.900 generating session key for dynamic DNS 26-May-2011 20:57:29.902 loading additional zones for view 'internal' 26-May-2011 20:57:29.902 none:0: open: 3bed2cb3a3acf7b6.nzf: file not found 26-May-2011 20:57:29.903 using built-in DLV key for view internal 26-May-2011 20:57:29.904 set up managed keys zone for view internal, file 'managed-keys/3bed2cb3a3acf7b6a8ef408420cc682d5520e26976d354254f528c965612054f.mkeys' 26-May-2011 20:57:29.904 automatic empty zone: view internal: 0.IN-ADDR.ARPA 26-May-2011 20:57:29.904 automatic empty zone: view internal: 127.IN-ADDR.ARPA 26-May-2011 20:57:29.904 automatic empty zone: view internal: 254.169.IN-ADDR.ARPA 26-May-2011 20:57:29.904 automatic empty zone: view internal: 2.0.192.IN-ADDR.ARPA 26-May-2011 20:57:29.904 automatic empty zone: view internal: 100.51.198.IN-ADDR.ARPA 26-May-2011 20:57:29.904 automatic empty zone: view internal: 113.0.203.IN-ADDR.ARPA 26-May-2011 20:57:29.904 automatic empty zone: view internal: 255.255.255.255.IN-ADDR.ARPA 26-May-2011 20:57:29.904 automatic empty zone: view internal: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA 26-May-2011 20:57:29.904 automatic empty zone: view internal: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA 26-May-2011 20:57:29.904 automatic empty zone: view internal: D.F.IP6.ARPA 26-May-2011 20:57:29.904 automatic empty zone: view internal: 8.E.F.IP6.ARPA 26-May-2011 20:57:29.904 automatic empty zone: view internal: 9.E.F.IP6.ARPA 26-May-2011 20:57:29.904 automatic empty zone: view internal: A.E.F.IP6.ARPA 26-May-2011 20:57:29.904 automatic empty zone: view internal: B.E.F.IP6.ARPA 26-May-2011 20:57:29.904 automatic empty zone: view internal: 8.B.D.0.1.0.0.2.IP6.ARPA 26-May-2011 20:57:29.905 loading additional zones for view 'external' 26-May-2011 20:57:29.905 none:0: open: 3c4623849a49a539.nzf: file not found 26-May-2011 20:57:29.906 set up managed keys zone for view external, file 'managed-keys/3c4623849a49a53911c4a3e48d8cead8a1858960bccdea7a1b978d73ec2f06d7.mkeys' 26-May-2011 20:57:29.907 loading additional zones for view 'extern-chaos' 26-May-2011 20:57:29.907 none:0: open: 2c25c0432e291924.nzf: file not found 26-May-2011 20:57:29.908 set up managed keys zone for view extern-chaos, file 'managed-keys/2c25c0432e2919242e3fb4d511858dde3a6b0a5efdbdf2a79a228d5e00e08d74.mkeys' 26-May-2011 20:57:29.909 command channel listening on 127.0.0.1#953 26-May-2011 20:57:29.909 ignoring config file logging statement due to -g option 26-May-2011 20:57:29.910 zone a.aa/IN/internal: loaded serial 20083 26-May-2011 20:57:29.913 zone b.aa/IN/internal: loaded serial 5178 26-May-2011 20:57:29.913 zone sig0.aa/IN/internal: loaded serial 19 26-May-2011 20:57:29.914 zone temp.aa/IN/internal: loaded serial 42478 26-May-2011 20:57:29.914 master/sec.temp.aa/sec.temp.aa.zone.signed:10: signature has expired 26-May-2011 20:57:29.914 zone sec.temp.aa/IN/internal: loaded serial 2 (DNSSEC signed) 26-May-2011 20:57:29.915 zone test1.aa/IN/internal: sig-re-signing-interval less than 3 * refresh. 26-May-2011 20:57:29.915 zone test1.aa/IN/internal: loaded serial 2010100561 (DNSSEC signed) 26-May-2011 20:57:29.915 zone 1.168.192.in-addr.arpa/IN/internal: loaded serial 201011030 26-May-2011 20:57:29.916 zone bzl/IN/internal: loaded serial 1287682762 26-May-2011 20:57:29.916 zone mens.de/IN/internal: loaded serial 201101201 26-May-2011 20:57:29.917 zone keys/IN/internal: loaded serial 4 26-May-2011 20:57:29.917 zone rpz/IN/internal: loaded serial 4 26-May-2011 20:57:29.917 managed-keys-zone ./IN/intern
Re: Bug in bind 9.7.3?
> I using bind 9.7.3 as resolver in a slightly larger server farm with > some mail servers that use domain key validation. > If a try > > # host -t TXT _adsp._domainkey.federalreserve.gov > > bind dies with > > May 26 19:59:02 resolv04 named[8237]: buffer.c:285: REQUIRE(b->used + 1 > <= b->length) failed > May 26 19:59:02 resolv04 named[8237]: exiting (due to assertion failure) > > This is reproducible and should only affected in 9.7.3. Can this be > possible? Also fails using 9.8.1b1: May 26 12:25:33 lpans2 named[2425]: dnssec: info: validating @0x2a0f740: federalreserve.gov SOA: no valid signature found May 26 12:25:33 lpans2 named[2425]: dnssec: info: validating @0x7f087808a0d0: 9811cuitspl6a9216q7e07en9sejpgst.federalreserve.gov NSEC3: no valid signature found May 26 12:25:33 lpans2 named[2425]: dnssec: info: validating @0x7f087808a0d0: m2n0plcd7rkj15ehs9s21ufd2bppkhcp.federalreserve.gov NSEC3: no valid signature found May 26 12:25:33 lpans2 named[2425]: dnssec: info: validating @0x7f087808a0d0: k3i91guqugukqor9ui8f0u5hvk0ijo84.federalreserve.gov NSEC3: no valid signature found May 26 12:25:33 lpans2 named[2425]: general: critical: buffer.c:285: REQUIRE(b->used + 1 <= b->length) failed, back trace May 26 12:25:33 lpans2 named[2425]: general: critical: #0 0x41649b in assertion_failed()+0x4b May 26 12:25:33 lpans2 named[2425]: general: critical: #1 0x5ab8ea in isc_assertion_failed()+0xa May 26 12:25:33 lpans2 named[2425]: general: critical: #2 0x5ad159 in isc__buffer_putuint8()+0x59 May 26 12:25:33 lpans2 named[2425]: general: critical: #3 0x4ad48f in dns_ncache_addoptout()+0x20f May 26 12:25:33 lpans2 named[2425]: general: critical: #4 0x52b168 in validated()+0x688 May 26 12:25:33 lpans2 named[2425]: general: critical: #5 0x5ccac8 in run()+0x1c8 May 26 12:25:33 lpans2 named[2425]: general: critical: #6 0x7f088bfdc8ba in _fini()+0x7f088b9f92f2 May 26 12:25:33 lpans2 named[2425]: general: critical: #7 0x7f088b9f402d in _fini()+0x7f088b410a65 May 26 12:25:33 lpans2 named[2425]: general: critical: exiting (due to assertion failure) -- Andris ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bug in bind 9.7.3?
> I using bind 9.7.3 as resolver in a slightly larger server farm with > some mail servers that use domain key validation. We're investigating the problem. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bug in bind 9.7.3?
Hi Frank, At 11:33 26-05-2011, Frank Kloeker wrote: I using bind 9.7.3 as resolver in a slightly larger server farm with some mail servers that use domain key validation. If a try # host -t TXT _adsp._domainkey.federalreserve.gov This occurs with BIND 9.8.0: buffer.c:285: REQUIRE(b->used + 1 <= b->length) failed, back trace #0 0x1c012a92 in assertion_failed()+0x42 #1 0x1c186957 in isc_assertion_failed()+0x27 #2 0x1c187e6d in isc__buffer_putuint8()+0x7d #3 0x1c09f3e5 in dns_ncache_addoptout()+0x2e5 #4 0x1c10fce9 in ncache_adderesult()+0x69 #5 0x1c1102e5 in validated()+0x3a5 #6 0x1c1a2af0 in isc__taskmgr_dispatch()+0x1c0 #7 0x1c1a5f23 in evloop()+0x73 #8 0x1c1a619a in isc__app_ctxrun()+0x13a #9 0x1c1a6242 in isc__app_run()+0x12 #10 0x1c013add in main()+0xbbd #11 0x1c003917 in ___start()+0x77 #12 0x1c003897 in __start()+0x17 #13 0xcfbde8bc in __fini()+0xb3a2874c exiting (due to assertion failure) Regards, -sm ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bug in bind 9.7.3?
On 5/26/2011 2:33 PM, Frank Kloeker wrote: Hi, I using bind 9.7.3 as resolver in a slightly larger server farm with some mail servers that use domain key validation. If a try # host -t TXT _adsp._domainkey.federalreserve.gov bind dies with May 26 19:59:02 resolv04 named[8237]: buffer.c:285: REQUIRE(b->used + 1 <= b->length) failed May 26 19:59:02 resolv04 named[8237]: exiting (due to assertion failure) This is reproducible and should only affected in 9.7.3. Can this be possible? kind regards Frank I had some of my 9.7.2-P3 boxes die the same way as well. dig txt _policy._domainkey.federalreserve.gov will trigger the crash as well. Not all of my systems seem to be affected, though. Those that are seem to be 100% reproducible. -- Dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursive server querying authoritative - timeout before trying next server?
Zitat von Dan Pritts : Hi, A question regarding BIND defaults. I'd love the same answer for other nameserver software if anyone cares to share. http://www.unbound.net/documentation/info_timeout.html For sure Bind is doing something similar. Regards Andreas ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bug in bind 9.7.3?
I can't get my 9.8.0-P1 resolvers to crash. The response from the federalreserve.gov servers looks strange, though: dig +dnssec +ignore +norec federalreserve.gov soa @ns5.frb.gov ;; Warning: Message parser reports malformed message packet. ;; WARNING: Messages has 57 extra bytes at end Hauke. signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bug in bind 9.7.3?
David Sparro wrote: > I had some of my 9.7.2-P3 boxes die the same way as well. > dig txt _policy._domainkey.federalreserve.gov > will trigger the crash as well. > Not all of my systems seem to be affected, though. Those that are seem > to be 100% reproducible. Just out of curiosity - are anyone seeing these crashes with a BIND that isn't doing DNSSEC validation? (I've not been able to reproduce this on any non-validating server yet, and my validating servers are running some other software at the moment - I'll enable validation on my test systems and check if I can get them to crash). Regards Eivind Olsen eiv...@aminor.no ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursive server querying authoritative - timeout before trying next server?
On 5/26/2011 2:51 PM, Dan Pritts wrote: Hi, A question regarding BIND defaults. I'd love the same answer for other nameserver software if anyone cares to share. I am a recursive nameserver. I am looking for foo.bar.com. i've learned from bar.com that foo.bar.com has four NS records. I've never tried to talk to these servers before. I send a query to the address listed in the first NS record. I never get an answer? How long do I wait before trying the next one? I looked through several RFCs but couldn't find anything specific in the spec. RFC1035 mentions that choosing this timeout would be up to nameserver implementors and suggests 5-10 seconds as a reasonable default. my google-fu is failing me on this one. I found something at Microsoft that suggests that their DNS server waits 3 seconds although i may have interpreted that wrong. I found a reference to a nameserver called "deadwood" that defaults to 2 seconds. But, I couldn't find anything on BIND. Dan, I don't know the exact timing, but with BIND it's on the order of tenths of a seconds (or 100s of milliseconds, if you prefer). 2 seconds would be way too slow. It shouldn't be hard to set up a test delegation with one "dead" nameserver and restart/query named a few times to see how long the failover takes... - Kevin P.S. You guys are practically next door to where I live (Pitt Twp), let me know if you need any help with this :-) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bug in bind 9.7.3?
> Just out of curiosity - are anyone seeing these crashes with a BIND that > isn't doing DNSSEC validation? Yes. But the problem domain has been corrected, so you won't be able to reproduce it now. In the interest of preventing this happening again, either by accident (as it was in this case) or due to someone crafting a bad zone maliciously, we will be releasing a patch to all affected versions of BIND 9 as soon as I finish turning the crank. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bug in bind 9.7.3?
I wrote: > (I've not been able to reproduce this on any non-validating server yet, > and my validating servers are running some other software at the moment - > I'll enable validation on my test systems and check if I can get them to > crash). I've so far not been able to reproduce it on a DNSSEC-validating BIND either. I'm not saying there's no bug, only that I can't reproduce it myself (probably, I'm doing something wrong). Regards Eivind Olsen eiv...@aminor.no ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bug in bind 9.7.3?
> Date: Fri, 27 May 2011 01:32:05 +0200 > From: "Eivind Olsen" > Sender: bind-users-bounces+oberman=es@lists.isc.org > > I wrote: > > > (I've not been able to reproduce this on any non-validating server yet, > > and my validating servers are running some other software at the moment - > > I'll enable validation on my test systems and check if I can get them to > > crash). > > I've so far not been able to reproduce it on a DNSSEC-validating BIND either. > I'm not saying there's no bug, only that I can't reproduce it myself > (probably, I'm doing something wrong). You can't trigger it any longer. The .gov people imposed a work-around that prevented the bug from being triggered. This was done quite a few hours ago. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
