Re: Question when testing Caching Server with resperf
> run with query 100-thousand -> maximum throughput ~ 9000 -> named process ~ 450 MB > run with query 100-thousand -> "ran out query data" errors > run with query 3-millions -> maximum throughput ~ 9000 -> named process ~ 400 MB > run with query 3-millions -> maximum throughput ~ 16000 -> named process ~ 500 MB First, I know it's not what you asked for, but why only run with 100-thousand queries in the input? If I remember correctly, resperf builds up gradually in speed towards 100.000 queries per second, unless you override that speed-limit. Now, on to what might be your issue. What kind of data do you query for? Is it real external data, or data you ensure is already in the cache? Are all the queries unique, or are there duplicates meaning the 1st query for a specific name will have an empty cache and need to go external and the 2nd query for the same name will get a faster answer from the cache? Did you flush the cache between tests? Regards Eivind Olsen ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
TTL of NSEC3PARAM RR
Hi, Why does BIND 9 set the TTL of NSEC3PARAM RR to zero ? dnssec-signzone sets TTL of NSEC3PARAM RR to 0. "update add zone 3600 IN NSEC3PARAM 1 1 10 001122334455" adds NSEC3PARAM RR with TTL 0. # I know that the TTL of NSEC3PARAM RR is trivial. # # RFC 5155 describes NSEC3PARAM RR is not used for validation. # But RFC 5155 does not describe the TTL of NSEC3PARAM RR. I don't have any opinion and request for TTL of NSEC3PARAM. I only want to know the reason. LDNS and OpenDNSSEC seem to set TTL of NSEC3PARAM to 3600. Regards, -- Kazunori Fujiwara, JPRS ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.7.3rc1 is now available.
Introduction BIND 9.7.3rc1 is the first release candidate of BIND 9.7.3. This document summarizes changes from BIND 9.7.1 to BIND 9.7.3. Please see the CHANGES file in the source code release for a complete list of all changes. Download The latest development version of BIND 9 software can always be found on our web site at http://www.isc.org/downloads/development. There you will find additional information about each release, source code, and some 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. New Features 9.7.2 * Zones may be dynamically added and removed with the "rndc addzone" and "rndc delzone" commands. These dynamically added zones are written to a per-view configuration file. Do not rely on the configuration file name nor contents as this will change in a future release. This is an experimental feature at this time. * Added new "filter--on-v4" access control list to select which IPv4 clients have record filtering applied. * A new command "rndc secroots" was added to dump a combined summary of the currently managed keys combined with statically configured trust anchors. * Added support to load new keys into managed zones without signing immediately with "rndc loadkeys". Added support to link keys with "dnssec-keygen -S" and "dnssec-settime -S". Feature Changes 9.7.2 * Documentation improvements * ORCHID prefixes were removed from the automatic empty zone list. * Improved handling of GSSAPI security contexts. Specifically, better memory management of cached contexts, limited lifetime of a context to 1 hour, and added a "realm" command to nsupdate to allow selection of a non-default realm name. * The contributed tool "zkt" was updated to version 1.0. Security Fixes 9.7.2-P3 * Adding a NO DATA signed negative response to cache failed to clear any matching RRSIG records already in cache. A subsequent lookup of the cached NO DATA entry could crash named (INSIST) when the unexpected RRSIG was also returned with the NO DATA cache entry. [RT #22288] [CVE-2010-3613] [VU#706148] * BIND, acting as a DNSSEC validator, was determining if the NS RRset is insecure based on a value that could mean either that the RRset is actually insecure or that there wasn't a matching key for the RRSIG in the DNSKEY RRset when resuming from validating the DNSKEY RRset. This can happen when in the middle of a DNSKEY algorithm rollover, when two different algorithms were used to sign a zone but only the new set of keys are in the zone DNSKEY RRset. [RT #22309] [CVE-2010-3614] [VU#837744] * When BIND is running as an authoritative server for a zone and receives a query for that zone data, it first checks for allow-query acls in the zone statement, then in that view, then in global options. If none of these exist, it defaults to allowing any query (allow-query {"any"};). With this bug, if the allow-query is not set in the zone statement, it failed to check in view or global options and fell back to the default of allowing any query. This means that queries that the zone owner did not wish to allow were incorrectly allowed. [RT #22418] [CVE-2010-3615] [VU#510208] 9.7.2-P2 * A flaw where the wrong ACL was applied was fixed. This flaw allowed access to a cache via recursion even though the ACL disallowed it. 9.7.2-P1 * If BIND, acting as a DNSSEC validating server, has two or more trust anchors configured in named.conf for the same zone (such as example.com) and the response for a record in that zone from the authoritative server includes a bad signature, the validating server will crash while trying to validate that query. Bug Fixes 9.7.3 * BIND now builds with threads disabled in versions of NetBSD earlier than 5.0 and with pthreads enabled by default in NetBSD versions 5.0 and higher. Also removes support for unproven-pthreads, mit-pthreads and ptl2. [RT #19203] * Added a regression test for fix 2896/RT #21045 ("rndc sign" failed to properly update the zone when adding a DNSKEY for publication only). [RT #21324] * "nsupdate -l" now gives error message if "session.key" file is not found. [RT #21670] * HPUX now correctly defaults to using /dev/poll, which should increase performance. [RT #21919] * If named is running as a threaded application, after an "rndc stop" command has been issued, oth
BIND 9.6.3rc1 is now available
Introduction BIND 9.6.3rc1 is the first release candidate for BIND 9.6.3. This document summarizes changes from BIND 9.6.2-P2 to BIND 9.6.3. Please see the CHANGES file in the source code release for a complete list of all changes. Download The latest development version of BIND 9 software can always be found on our web site at http://www.isc.org/downloads/development. There you will find additional information about each release, source code, and some 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. New Features 9.6.3 None. Feature Changes 9.6.3 None. Security Fixes 9.6.2-P3 * Adding a NO DATA signed negative response to cache failed to clear any matching RRSIG records already in cache. A subsequent lookup of the cached NO DATA entry could crash named (INSIST) when the unexpected RRSIG was also returned with the NO DATA cache entry. [RT #22288] [CVE-2010-3613] [VU#706148] * BIND, acting as a DNSSEC validator, was determining if the NS RRset is insecure based on a value that could mean either that the RRset is actually insecure or that there wasn't a matching key for the RRSIG in the DNSKEY RRset when resuming from validating the DNSKEY RRset. This can happen when in the middle of a DNSKEY algorithm rollover, when two different algorithms were used to sign a zone but only the new set of keys are in the zone DNSKEY RRset. [RT #22309] [CVE-2010-3614] [VU#837744] Bug Fixes 9.6.3 * BIND now builds with threads disabled in versions of NetBSD earlier than 5.0 and with pthreads enabled by default in NetBSD versions 5.0 and higher. Also removes support for unproven-pthreads, mit-pthreads and ptl2. [RT #19203] * HPUX now correctly defaults to using /dev/poll, which should increase performance. [RT #21919] * If named is running as a threaded application, after an "rndc stop" command has been issued, other inbound TCP requests can cause named to hang and never complete shutdown. [RT #22108] * When performing a GSS-TSIG signed dynamic zone update, memory could be leaked. This causes an unclean shutdown and may affect long-running servers. [RT #22573] * A bug in NetBSD and FreeBSD kernels with SO_ACCEPTFILTER enabled allows for a TCP DoS attack. Until there is a kernel fix, ISC is disabling SO_ACCEPTFILTER support in BIND. [RT #22589] * Corrected a defect where a combination of dynamic updates and zone transfers incorrectly locked the in-memory zone database, causing named to freeze. [RT #22614] * Don't run MX checks (check-mx) when the MX record points to ".". [RT #22645] * DST key reference counts can now be incremented via dst_key_attach. [RT #22672] * isc_mutex_init_errcheck() in phtreads/mutex.c failed to destroy attr. [RT #22766] * The Kerberos realm was being truncated when being pulled from the the host prinicipal, make krb5-self updates fail. [RT #22770] * named failed to preserve the case of domain names in RDATA which is not compressible when writing master files. [RT #22863] 9.6.2-P3 * Worked around a race condition in the cache database memory handling. Without this fix a DNS cache DB or ADB could incorrectly stay in an over memory state, effectively refusing further caching, which subsequently made a BIND 9 caching server unworkable. [RT #21818] * Microsoft changed the behavior of sockets between NT/XP based stacks vs Vista/windows7 stacks. Server 2003/2008 have the older behavior, 2008r2 has the new behavior. With the change, different error results are possible, so ISC adapted BIND to handle the new error results. This resolves an issue where sockets would shut down on Windows servers causing named to stop responding to queries. [RT #21906] * Windows has non-POSIX compliant behavior in its rename() and unlink() calls. This caused journal compaction to fail on Windows BIND servers with the log error: "dns_journal_compact failed: failure". [RT #22434] 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. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mai
Question when testing Caching Server with resperf
Hi, My bind version is bind-9.7.2-P3, resperf is dnsperf-1.0.1.0-1-solaris-10-sparc. On sparc 10u8 Solaris Normally, resperf tool measures maximum throughput of caching server. So i did a test follow : run with query 100-thousand -> maximum throughput ~ 9000 -> named process ~ 450 MB run with query 100-thousand -> "ran out query data" errors run with query 3-millions -> maximum throughput ~ 9000 -> named process ~ 400 MB run with query 3-millions -> maximum throughput ~ 16000 -> named process ~ 500 MB . . . run with query 3-millions -> maximum throughput ~ 16000 -> named process ~ 600 MB run with query 3-millions -> maximum throughput ~ 16000 -> named process ~ 600 MB So named cache ramains ~ 600 Mb. although many times i run the testing command. *** Now, what i want to know is, does resperf tool use the query which was used in previous command. For Example: If query 1 run 65000 first line, does the query 2 run the same query or it will run next 65000 line below. Or it ran query in file randomly. If it does not ran the same, why the cache remains 600M. But i think it have to cache, because the maximum throughput is increase from 9000 to 16000. If u have my answer please note me where it is in the document from Nominum. Thank men. Tien86. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind with publicly routable DDNS mappings for IPv6 but not IPv4
In message <7bc44907-7c33-4f7c-9868-92798b7ef...@gmail.com>, Chris Buxton write s: > Can't be done with just BIND. You need some kind of solution to strip = > out the private IPv4 address space before publishing data to the outside = > world. (Are you sure your workstations really need to have their = > routable addresses published to the outside world? Sounds dangerous to = > me.) > > For example, you could write a script that would grab a copy of the = > internal zone, strip out what you don't want, and republish on an = > external-facing name server, and then run that script on a 5 minute cron = > job. Or use dig and ixfr to get the recent changes to the internal zone and apply the ones that match your filter the external zones. e.g. % dig +noall +answer ixfr=2007104570 dv.isc.org | awk -f ixfr2nsupdate update delete sapphire.dv.isc.org. 1200IN A 192.168.1.2 update add sapphire.dv.isc.org. 1200IN A 192.168.1.2 update delete sapphire.dv.isc.org. 1200IN A 192.168.1.2 update add sapphire.dv.isc.org. 1200IN A 192.168.1.5 % ixfr2nsupdateupdate: BEGIN { mode="none"; } $4 == "SOA" { if (mode == "none") { mode = "add"; } else if (mode == "delete") { mode = "add" } else { mode = "delete" }; next; } $4 == "RRSIG" || $4 == "NSEC" || $4 == "NSEC3" || $4 == "NSEC3PARAM" { next } { print "update", mode, $0 } Mark > Chris Buxton > BlueCat Networks > > On Jan 24, 2011, at 7:28 AM, Michael Himbeault wrote: > > > So I appear to have fallen into the cracks of "stuff the internet is = > completely useless for looking up". I can't come up with any useful set = > of keywords, so here I am. > >=20 > > I'm attempting to configure DDNS between ISC DHCPD and BIND. I want = > DDNS for both IPv4 and IPv6. I have this. Cool. Now, I want to publish = > the IPv6 DDNS mappings out to the internet at large so every host can = > have a publicly routable IP address and no one has to remember any 32 = > character addresses. I would like this to be accomplished by everyone = > hanging off of the domain. > >=20 > > For example a computer (hostname: pinky) connects to the network, and = > now everyone on the internal network can ping either pinky or = > pinky.example.com. If they are IPv4 only, they will get pinky's IPv4 = > leased address, and if they are dual-stack or IPv6 they will get pinky's = > IPv6 address since pinky.riebart.ca will have both A and records. I = > also want anyone on the internet at large to be able to ping = > pinky.example.com and, if they are IPv6 enabled, will get replies since = > pinky's IPv6 address is publicly routable. Attempts to get an A record = > for pinky.example.com should fail. > >=20 > > Problem is, how do I do this without polluting the internet with my = > private IPv4 DDNS mappings and without requiring an extra subdomain? The = > inside clients need to see both the IPv6 and IPv4 mappings, but the = > external queries should never see the IPv4 mappings. I can't just = > copy-past the zone files since they are both being dynamicly updated = > through DDNS. Additionally, since the DHCP client support for DHCP = > option 119 (DNS domain search list) is pretty abysmal I would really = > like to not have to put ipv4 mappings onto .ipv4.example.com. > >=20 > > Any suggestions? > >=20 > > Thanks, > > Mike ___ > > bind-users mailing list > > bind-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users > > > --Apple-Mail-64--231457544 > Content-Transfer-Encoding: 7bit > Content-Type: text/html; > charset=us-ascii > > Can't be done with just BIN > D. You need some kind of solution to strip out the private IPv4 address space > before publishing data to the outside world. (Are you sure your workstations > really need to have their routable addresses published to the outside world? > Sounds dangerous to me.)For example, you could wri > te a script that would grab a copy of the internal zone, strip out what you d > on't want, and republish on an external-facing name server, and then run that > script on a 5 minute cron job.Chris Buxton iv>BlueCat NetworksOn Jan 24, 2011, at 7:28 AM, Michael H > imbeault wrote:So I appear to have fallen into the cracks of "stuff the internet is > completely useless for looking up". I can't come up with any useful set > of keywords, so here I am. > > I'm attempting to configure DDNS between ISC DHCPD and BIND. I want DDNS > for both IPv4 and IPv6. I have this. Cool. Now, I want to publish the > IPv6 DDNS mappings out to the internet at large so every host can have a publ > icly routable IP > address and no one has to remember any 32 character addresses. I would like t > his to be accomplished by everyone hanging off > of the domain. > > For example a computer (hostname: pinky) connects to the network, and > now everyone on the internal network can ping either pinky or pinky.example.
Re: service if s/up/down/g ipv6
In message <201101241636.57884.fake...@fakessh.eu>, fakessh writes: > > Le lundi 24 janvier 2011 00:04, vous avez =C3=A9crit=C2 : > > At this stage I think you will need to post the zone so we can see > > what you have done. Also the named.conf zone clause for ovh.net. > > Marc thank you for your attention as you bear me, thank you very humbly > > i paste my named.conf and the zone whitout signatures , work for me > > http://pastebin.com/7Be9FavZ This is the zone for "fakessh.eu". I requested the zone for "ovh.net" because you asked if r13151.ovh.net was reachable over IPv6. To do that we needed r13151.ovh.net's IPv6 address just like we need its IPv4 address to test if we can reach it over IPv4. If you are just worried that the address are being published in the fakessh.eu then they are. % dig www.fakessh.eu +short 2001:41d0:2:3dd6:1234:5678:9abc:def0 % > http://pastebin.com/XFuc45tM > > nb : if I create a new thread in the list Excuse me Mark has bothered to=20 > answer me personally in my INBOX from the list, so I think my answer will n= > ot=20 > be synchronized with the list > > =2D-=20 > http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x092164A7 > gpg --keyserver pgp.mit.edu --recv-key 092164A7 > > --nextPart4788602.X930IZQvoN > Content-Type: application/pgp-signature > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.5 (GNU/Linux) > > iD8DBQBNPZyZtXI/OwkhZKcRAlMRAJ95rVtknVtShDdm9IqlzRGD/MjhiQCggZkB > D5NsZ1Pevuw6mBHkX2SmMcc= > =TBXv > -END PGP SIGNATURE- > > --nextPart4788602.X930IZQvoN-- -- 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: service if s/up/down/g ipv6
In message <1295898474.4615.5.camel@localhost.localdomain>, "fakessh @" writes: > thank you for this very constructive reflection. I just changed the zone > r13151.ovh.net it contained only fields ptr ns and I just added a field > and . I increment the serial then all and apply rndc reload flush > reconfig sign all zone > > dig answer now seems > r13151 ~]# dig +short r13151.ovh.net > 2001:41d0:2:3dd6:1234:5678:9abc:def0 That address in not reachable. It's also not published to the world. ; <<>> DiG 9.6.0-APPLE-P2 <<>> r13151.ovh.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53882 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;r13151.ovh.net.IN ;; AUTHORITY SECTION: ovh.net.223 IN SOA dns10.ovh.net. tech.ovh.net. 2011012410 86400 3600 360 600 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Jan 25 08:58:35 2011 ;; MSG SIZE rcvd: 79 ; <<>> DiG 9.6.0-APPLE-P2 <<>> fakessh.eu +norec @2001:41d0:2:3dd6:1234:5678:9abc:def0 ;; global options: +cmd ;; connection timed out; no servers could be reached % traceroute6 -I 2001:41d0:2:3dd6:1234:5678:9abc:def0 traceroute6 to 2001:41d0:2:3dd6:1234:5678:9abc:def0 (2001:41d0:2:3dd6:1234:5678:9abc:def0) from 2001:470:1f00:820:ea06:88ff:fef3:4f9c, 64 hops max, 16 byte packets 1 bsdi 4.294 ms 4.414 ms 4.348 ms 2 tunnel820.tserv1.fmt.ipv6.he.net 184.739 ms 184.951 ms 184.252 ms 3 v702.core1.fmt1.he.net 190.944 ms 185.803 ms 205.290 ms 4 gige-g4-8.core1.fmt2.he.net 193.800 ms 185.499 ms 188.133 ms 5 10gigabitethernet6-4.core1.lax1.he.net 195.345 ms 192.132 ms 195.376 ms 6 10gigabitethernet4-3.core1.nyc4.he.net 253.409 ms 258.000 ms 253.955 ms 7 10gigabitethernet1-2.core1.lon1.he.net 321.876 ms 328.994 ms 324.858 ms 8 10gigabitethernet1-1.core1.ams1.he.net 339.823 ms 329.418 ms 344.208 ms 9 10gigabitethernet1-1.core1.fra1.he.net 336.818 ms 344.800 ms 336.734 ms 10 decix.routers.ovh.net 338.047 ms 337.641 ms 348.496 ms 11 vss-2-6k.fr.eu 345.997 ms 363.553 ms 348.756 ms 12 vss-2-6k.fr.eu 3342.128 ms !A 3349.602 ms !A 3348.035 ms !A % > > Le lundi 24 janvier 2011 =C3=A0 17:57 +0100, Eivind Olsen a =C3=A9crit : > > > http://pastebin.com/7Be9FavZ > >=20 > > That zonefile seems to be for fakessh.eu, and not for ovh.net. > > Your initial problem was regarding IPv6 towards r13151.ovh.net ? If so, > > that's the zonefile we'll need to look at. > >=20 > > Regards > > Eivind Olsen > >=20 > >=20 > > ___ > > bind-users mailing list > > bind-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users > --=20 > gpg --keyserver pgp.mit.edu --recv-key 092164A7 > http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0x092164A7 > > --=-J0981zr9QuD4DtkUiCpt > Content-Type: application/pgp-signature; name=signature.asc > Content-Description: Ceci est une partie de message > =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.5 (GNU/Linux) > > iD8DBQBNPddqtXI/OwkhZKcRAvDFAKCGFNDi6UQYWEY3gfHCNBUM92g9lACeJFtK > 4ryX8hpFeWol1ikygzAGHsk= > =FDkY > -END PGP SIGNATURE- > > --=-J0981zr9QuD4DtkUiCpt-- > > > --===0053086760583786854== > Content-Type: text/plain; charset="us-ascii" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > --===0053086760583786854==-- > -- 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: BIND 9.8.0b1 Released Today
On Jan 24, 2011, at 5:59 AM, Cathy Almond wrote: >> I wonder, what are expected usages for this kinds of zones? >> Maybe blacklists, if we have local mirrors and traffic so high that we'd get >> blocked imediately? > > It's subtle. > > One use case is for testing new servers that aren't yet part of the main > Internet name space. You can force queries for that zone to go to your > test servers (maybe they're running new software, maybe they're testing > DNSSEC, maybe... ) instead of the servers that would be located the via > delegation from the parent zone. In this instance the test servers > might well need to respond with the 'real' nameserver information (for > returning to clients) - but you don't want that to override the fact > that you still want to send future queries to the servers you have on test. Another use is to separate recursion from internal authoritative name servers. You could put this on the recursing name servers, telling them explicitly which auth servers to hit rather than relying on a traditional stub zone. This might be useful if the zone is hosted on some nearby servers and also some remote servers, to avoid having the RTT algorithm cause the recursing server to query the remote servers. Chris Buxton BlueCat Networks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind with publicly routable DDNS mappings for IPv6 but not IPv4
Can't be done with just BIND. You need some kind of solution to strip out the private IPv4 address space before publishing data to the outside world. (Are you sure your workstations really need to have their routable addresses published to the outside world? Sounds dangerous to me.) For example, you could write a script that would grab a copy of the internal zone, strip out what you don't want, and republish on an external-facing name server, and then run that script on a 5 minute cron job. Chris Buxton BlueCat Networks On Jan 24, 2011, at 7:28 AM, Michael Himbeault wrote: > So I appear to have fallen into the cracks of "stuff the internet is > completely useless for looking up". I can't come up with any useful set of > keywords, so here I am. > > I'm attempting to configure DDNS between ISC DHCPD and BIND. I want DDNS for > both IPv4 and IPv6. I have this. Cool. Now, I want to publish the IPv6 DDNS > mappings out to the internet at large so every host can have a publicly > routable IP address and no one has to remember any 32 character addresses. I > would like this to be accomplished by everyone hanging off of the domain. > > For example a computer (hostname: pinky) connects to the network, and now > everyone on the internal network can ping either pinky or pinky.example.com. > If they are IPv4 only, they will get pinky's IPv4 leased address, and if they > are dual-stack or IPv6 they will get pinky's IPv6 address since > pinky.riebart.ca will have both A and records. I also want anyone on the > internet at large to be able to ping pinky.example.com and, if they are IPv6 > enabled, will get replies since pinky's IPv6 address is publicly routable. > Attempts to get an A record for pinky.example.com should fail. > > Problem is, how do I do this without polluting the internet with my private > IPv4 DDNS mappings and without requiring an extra subdomain? The inside > clients need to see both the IPv6 and IPv4 mappings, but the external queries > should never see the IPv4 mappings. I can't just copy-past the zone files > since they are both being dynamicly updated through DDNS. Additionally, since > the DHCP client support for DHCP option 119 (DNS domain search list) is > pretty abysmal I would really like to not have to put ipv4 mappings onto > .ipv4.example.com. > > Any suggestions? > > Thanks, > Mike ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: service if s/up/down/g ipv6
thank you for this very constructive reflection. I just changed the zone r13151.ovh.net it contained only fields ptr ns and I just added a field and . I increment the serial then all and apply rndc reload flush reconfig sign all zone dig answer now seems r13151 ~]# dig +short r13151.ovh.net 2001:41d0:2:3dd6:1234:5678:9abc:def0 Le lundi 24 janvier 2011 à 17:57 +0100, Eivind Olsen a écrit : > > http://pastebin.com/7Be9FavZ > > That zonefile seems to be for fakessh.eu, and not for ovh.net. > Your initial problem was regarding IPv6 towards r13151.ovh.net ? If so, > that's the zonefile we'll need to look at. > > Regards > Eivind Olsen > > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x092164A7 signature.asc Description: Ceci est une partie de message numériquement signée ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: service if s/up/down/g ipv6
> http://pastebin.com/7Be9FavZ That zonefile seems to be for fakessh.eu, and not for ovh.net. Your initial problem was regarding IPv6 towards r13151.ovh.net ? If so, that's the zonefile we'll need to look at. Regards Eivind Olsen ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
On 24/01/11 4:08 PM, "Zbigniew Jasiński" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > W dniu 2011-01-24 14:34, Kalman Feher pisze: >> I assume you did add the nsec3param record via nsupdate after adding the >> zone? I note that there is an NSEC entry there, which is not right. >> > > Yes, with nsupdate. and lack of NSEC3PARAM was very odd. > >> Are you following this same workflow? >> FWIW I use a script to add all my test zones from a zone template file. That >> script automatically adds the nsec3param as soon as the zone is loaded, but >> before it signs. That way I keep things simple and never forget to update >> that zone before signing. > > I made few more tests and what I've understand you have to have at least > one key in 'Activate' state. > > for example: > > the same example zone, generated keys with future Prepublish and > Activate event, adding NSEC3PARAM via nsupdate: > > Jan 24 15:28:36 named[15837]: update: client 127.0.0.1#8917: updating > zone 'example/IN': adding an RR at 'example' NSEC3PARAM > Jan 24 15:28:36 named[15837]: general: zone example/IN: > dns_zone_addnsec3chain(hash=1, iterations=12, salt=19CC44675CFB020065B1) > Jan 24 15:28:36 named[15837]: general: zone example/IN: > zone_addnsec3chain(1,CREATE,12,19CC44675CFB020065B1) > > now I want named to read the key timings from key files so I make 'rndc > sign example': > > Jan 24 15:28:37 named[15837]: general: received control channel command > 'sign example' > Jan 24 15:28:37 named[15837]: general: zone example/IN: reconfiguring > zone keys > Jan 24 15:28:37 named[15837]: general: zone example/IN: > zone_addnsec3chain(1,REMOVE|NONSEC,12,19CC44675CFB020065B1) This appears to be the problem. I copied your NSEC3PARAM (opt out clear, 12 iterations) details but could not replicate it. Try turning up the logging to get more information about why the nsec3param is removed. Make sure also that your keys are nsec3 compatible and you don't have any old non nsec3 keys in the directory that could be used to sign. > Jan 24 15:28:37 named[15837]: general: zone example/IN: next key event: > 24-Jan-2011 15:29:36.860 > Jan 24 15:29:36 named[15837]: general: zone example/IN: reconfiguring > zone keys > Jan 24 15:29:36 named[15837]: general: zone example/IN: next key event: > 24-Jan-2011 16:29:36.886 > > and my NSEC3PARAM record is removed! and my question is why? why can't I > have NSEC3PARAM record in my zone before signing it?? > > If I wait until 'Activate' event (16:29:36.886 - for this particular > test) I will get strangely looking signed zone (which I attached in my > previous emails) without my NSEC3PARAM record. > > - -- > regards > > zbigniew jasinski > [SYStem OPerator] > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJNPZXVAAoJEH26UYiRhe/gPDwP/2kxlk5ct9hpffP94tAUgx/F > R61tr9IA1mSAkHkN6zJh7GYRgNSxllI4s+h41FXYBhlknpARdcobfm2ybdkReojm > llaTIQtqcgh+7vRq/MK9zH3MwWglhatuQFENUwTpy38zccRwSAQhtN+XDUi2TpVq > VS0tjpAqZb0/hpz9pb4Bxu1uNzpRUehiRcjhg0l2ocsBg/32FQ4xSDr3ViMNHgeA > 0a+xIRkp9gK5DsUUCPlpkQBBr7ICyvl/M4t3RPUOr3zf7tzUX81TrNLF1PeHC/kh > gR8Hz+94MceVdgVIaRNWUpj5wvYVRuz9DEdp9li124kk4hyATh+Qo1Bk1ZrreoNa > AxqO/qVqtRz7xpRSdjvOcsNrJ7/5dJltfp/Mv7wC0xXgz/DR84xiFvpy21JAEJIa > W0D7lCSixF3B8WV90vKevJGSCWSi0ipLANuckO4oHzhTyVk0RQmV/iGZjneWwJpV > KJWuTSa1sffk2QXI3ikwH5WKLyKaXmOCG5ZkEmLc8OO70WSkuWlsbt2oGGRAgGVd > b8uYtr6NrJdJBhAU5KgcEHiOY6g9Wv6ffC63XS1LMC9b/Tnp5DXHnK8VG5og6NwO > vjgJu5SwyuijAl+VIWlnnenxNBy4vB4OSrht0sC+JvzN360/sSSLE3fzHpFwMTGq > D1zWmxkyD645F6od2RJ/ > =iWfG > -END PGP SIGNATURE- > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.8.0b1 Released Today
On 24.01.2011 15:54, Paul Wouters wrote: > I meant, if you have a zone example.tld. And tld. is not signed, but > you have a testbed for a signed tld. at IP 1.2.3.4, if static-stub > would allow you to configure a resolving bind to perform DNSSEC on > 1.2.3.4 with a loaded trusted-key. So yes, the "de" (or "ca") testbed > hook. Yes, it works. No more "DNS format error [...] non-improving referral". See the attached diff to DeNIC's testbed configuration https://www.secure.denic.de/fileadmin/public/events/DNSSEC_testbed/dnssec-testbed-muster-bind.txt Hauke. --- dnssec-testbed-muster-bind.txt.old 2010-10-01 09:05:49.0 +0200 +++ dnssec-testbed-muster-bind.txt 2011-01-24 16:37:06.0 +0100 @@ -12,16 +12,15 @@ // ``zone Statement Definition and Usage'' zone "de" { - type forward; + type static-stub; // Die Reihenfolge der beiden Adressen kann beliebig gewaehlt // werden - forwarders { + server-addresses { 81.91.161.228; // auth-fra.dnssec.denic.de 87.233.175.25; // auth-ams.dnssec.denic.de // IPv6 nur bei geeigneter Konnektivität aktivieren // 2A02:568:0:1::53; // auth-fra.dnssec.denic.de }; - forward first; }; // WICHTIG: Diese Liste muss regelmaessig gepflegt werden und signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: service if s/up/down/g ipv6
Le lundi 24 janvier 2011 00:04, vous avez écrit : > At this stage I think you will need to post the zone so we can see > what you have done. Also the named.conf zone clause for ovh.net. Marc thank you for your attention as you bear me, thank you very humbly i paste my named.conf and the zone whitout signatures , work for me http://pastebin.com/7Be9FavZ http://pastebin.com/XFuc45tM nb : if I create a new thread in the list Excuse me Mark has bothered to answer me personally in my INBOX from the list, so I think my answer will not be synchronized with the list -- http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x092164A7 gpg --keyserver pgp.mit.edu --recv-key 092164A7 pgpdoLshF59Un.pgp Description: PGP signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Bind with publicly routable DDNS mappings for IPv6 but not IPv4
So I appear to have fallen into the cracks of "stuff the internet is completely useless for looking up". I can't come up with any useful set of keywords, so here I am. I'm attempting to configure DDNS between ISC DHCPD and BIND. I want DDNS for both IPv4 and IPv6. I have this. Cool. Now, I want to publish the IPv6 DDNS mappings out to the internet at large so every host can have a publicly routable IP address and no one has to remember any 32 character addresses. I would like this to be accomplished by everyone hanging off of the domain. For example a computer (hostname: pinky) connects to the network, and now everyone on the internal network can ping either pinky or pinky.example.com. If they are IPv4 only, they will get pinky's IPv4 leased address, and if they are dual-stack or IPv6 they will get pinky's IPv6 address since pinky.riebart.ca will have both A and records. I also want anyone on the internet at large to be able to ping pinky.example.com and, if they are IPv6 enabled, will get replies since pinky's IPv6 address is publicly routable. Attempts to get an A record for pinky.example.com should fail. Problem is, how do I do this without polluting the internet with my private IPv4 DDNS mappings and without requiring an extra subdomain? The inside clients need to see both the IPv6 and IPv4 mappings, but the external queries should never see the IPv4 mappings. I can't just copy-past the zone files since they are both being dynamicly updated through DDNS. Additionally, since the DHCP client support for DHCP option 119 (DNS domain search list) is pretty abysmal I would really like to not have to put ipv4 mappings onto .ipv4.example.com. Any suggestions? Thanks, Mike ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.8.0b1 Released Today
On Sat, 22 Jan 2011, JINMEI Tatuya / 神明達哉 wrote: Does this work with DNSSEC if one loads an explicit trust anchor, even if in the "world view" the trust anchor is missing? I'm afraid I don't understand the question. Could you be more specific, e.g., by using the above example.com example? I think Paul is wondering if it works with the DENIC testbed. 8-) The forward hack does not work reliable for DNSSEC islands, IIRC. (I still don't understand what exactly "it works with the DENIC testbed" means in the context of the original question of Paul, but) If so, I believe the answer is yes. static-stub was developed specifically for that purpose (although the feature itself is generic and would be useful for other purposes) :-) I meant, if you have a zone example.tld. And tld. is not signed, but you have a testbed for a signed tld. at IP 1.2.3.4, if static-stub would allow you to configure a resolving bind to perform DNSSEC on 1.2.3.4 with a loaded trusted-key. So yes, the "de" (or "ca") testbed hook. Paul ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 2011-01-24 14:34, Kalman Feher pisze: > I assume you did add the nsec3param record via nsupdate after adding the > zone? I note that there is an NSEC entry there, which is not right. > Yes, with nsupdate. and lack of NSEC3PARAM was very odd. > Are you following this same workflow? > FWIW I use a script to add all my test zones from a zone template file. That > script automatically adds the nsec3param as soon as the zone is loaded, but > before it signs. That way I keep things simple and never forget to update > that zone before signing. I made few more tests and what I've understand you have to have at least one key in 'Activate' state. for example: the same example zone, generated keys with future Prepublish and Activate event, adding NSEC3PARAM via nsupdate: Jan 24 15:28:36 named[15837]: update: client 127.0.0.1#8917: updating zone 'example/IN': adding an RR at 'example' NSEC3PARAM Jan 24 15:28:36 named[15837]: general: zone example/IN: dns_zone_addnsec3chain(hash=1, iterations=12, salt=19CC44675CFB020065B1) Jan 24 15:28:36 named[15837]: general: zone example/IN: zone_addnsec3chain(1,CREATE,12,19CC44675CFB020065B1) now I want named to read the key timings from key files so I make 'rndc sign example': Jan 24 15:28:37 named[15837]: general: received control channel command 'sign example' Jan 24 15:28:37 named[15837]: general: zone example/IN: reconfiguring zone keys Jan 24 15:28:37 named[15837]: general: zone example/IN: zone_addnsec3chain(1,REMOVE|NONSEC,12,19CC44675CFB020065B1) Jan 24 15:28:37 named[15837]: general: zone example/IN: next key event: 24-Jan-2011 15:29:36.860 Jan 24 15:29:36 named[15837]: general: zone example/IN: reconfiguring zone keys Jan 24 15:29:36 named[15837]: general: zone example/IN: next key event: 24-Jan-2011 16:29:36.886 and my NSEC3PARAM record is removed! and my question is why? why can't I have NSEC3PARAM record in my zone before signing it?? If I wait until 'Activate' event (16:29:36.886 - for this particular test) I will get strangely looking signed zone (which I attached in my previous emails) without my NSEC3PARAM record. - -- regards zbigniew jasinski [SYStem OPerator] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNPZXVAAoJEH26UYiRhe/gPDwP/2kxlk5ct9hpffP94tAUgx/F R61tr9IA1mSAkHkN6zJh7GYRgNSxllI4s+h41FXYBhlknpARdcobfm2ybdkReojm llaTIQtqcgh+7vRq/MK9zH3MwWglhatuQFENUwTpy38zccRwSAQhtN+XDUi2TpVq VS0tjpAqZb0/hpz9pb4Bxu1uNzpRUehiRcjhg0l2ocsBg/32FQ4xSDr3ViMNHgeA 0a+xIRkp9gK5DsUUCPlpkQBBr7ICyvl/M4t3RPUOr3zf7tzUX81TrNLF1PeHC/kh gR8Hz+94MceVdgVIaRNWUpj5wvYVRuz9DEdp9li124kk4hyATh+Qo1Bk1ZrreoNa AxqO/qVqtRz7xpRSdjvOcsNrJ7/5dJltfp/Mv7wC0xXgz/DR84xiFvpy21JAEJIa W0D7lCSixF3B8WV90vKevJGSCWSi0ipLANuckO4oHzhTyVk0RQmV/iGZjneWwJpV KJWuTSa1sffk2QXI3ikwH5WKLyKaXmOCG5ZkEmLc8OO70WSkuWlsbt2oGGRAgGVd b8uYtr6NrJdJBhAU5KgcEHiOY6g9Wv6ffC63XS1LMC9b/Tnp5DXHnK8VG5og6NwO vjgJu5SwyuijAl+VIWlnnenxNBy4vB4OSrht0sC+JvzN360/sSSLE3fzHpFwMTGq D1zWmxkyD645F6od2RJ/ =iWfG -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.8.0b1 Released Today
> so, iiuc, the difference is that "type forward" sends queries with RD bit > set, while "type static-stub" sends them with RD cleared... and > the "forward first" option appears to be applicable only in forward zones. > > did I get it right? Yes > > I use forward zones for blacklists - while I mirror some locally, but when my > mirror fails, the usual resolution takes place. > > If I'm right, this is not possible with "type static-stub" zones. Yes > I wonder, what are expected usages for this kinds of zones? > Maybe blacklists, if we have local mirrors and traffic so high that we'd get > blocked imediately? It's subtle. One use case is for testing new servers that aren't yet part of the main Internet name space. You can force queries for that zone to go to your test servers (maybe they're running new software, maybe they're testing DNSSEC, maybe... ) instead of the servers that would be located the via delegation from the parent zone. In this instance the test servers might well need to respond with the 'real' nameserver information (for returning to clients) - but you don't want that to override the fact that you still want to send future queries to the servers you have on test. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
On 24/01/11 10:53 AM, "Zbigniew Jasiński" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > W dniu 2011-01-21 15:17, Kalman Feher pisze: >>> Perhaps we are getting close to the problem then. >>> Can you show the content of the key files? Specifically the metadata which >>> the "maintain" option wants. >> >>> Since "allow" works I'm assuming that key file permissions (and directory >>> permissions) are ok, but it couldn't hurt to check them. > > I've made new instalation without SoftHSM support to be sure that this > is not an issue, and of course 'allow' works and 'maintain' the same odd > things. > > permissions are ok, double-checked, and with 'allow' it works. > > key metadata, same for ZSK and KSK: > > ; Created: 20110121145849 (Fri Jan 21 15:58:49 2011) > ; Publish: 20110121145937 (Fri Jan 21 15:59:37 2011) > ; Activate: 20110121170117 (Fri Jan 21 18:01:17 2011) > ; Inactive: 20110121220937 (Fri Jan 21 23:09:37 2011) > ; Delete: 20110122001117 (Sat Jan 22 01:11:17 2011) > > and of course I'm waiting until Activate key event to be sure I will get > RRSIG in response but there's now signatures. > > strange thing, that after signing zone with 'maintain' and after named > dumps zone into plain file, file differs from this dumped with 'allow' > option, much. for example don't have NSEC3PARAM in file from 'maintain' > and DS record (authoritative) doesn't have even it's signature! I assume you did add the nsec3param record via nsupdate after adding the zone? I note that there is an NSEC entry there, which is not right. > > zone with 'maintain' option: > > $ORIGIN . > $TTL 3600 ; 1 hour > example IN SOA ns1.example. bugs.x.w.example. ( > 1292481918 ; serial > 7200 ; refresh (2 hours) > 3600 ; retry (1 hour) > 734400 ; expire (1 week 1 day 12 hours) > 600; minimum (10 minutes) > ) > RRSIG SOA 10 1 3600 20110223093216 ( > 20110124083216 41870 example. > SbFalU9K5yroRNtENT7nQHovxOXhl8ROOi90D77qFEXc > > NS ns1.example. > NS ns2.example. > TXT "dnssec test" > $TTL 600; 10 minutes > NSECa.example. NS SOA TXT RRSIG NSEC DNSKEY > TYPE65534 > $TTL 3600 ; 1 hour > DNSKEY 256 3 10 ( > AwEAAdByffBxPaxGFxfnf10TKUIwUKvq79vfMJ9wGW6s > ) ; key id = 41870 > DNSKEY 257 3 10 ( > AwEAAdFituIkCms1lVbht+ykmwRUoBQJjHW9qep2GS1O > ) ; key id = 996 > RRSIG DNSKEY 10 1 3600 20110223093216 ( > 20110124083216 996 example. > LXfYVMI7BuQEEvYKpiadeboBHlv1RYv1vaaUoZLwnhC6 > RRSIG DNSKEY 10 1 3600 20110223093216 ( > 20110124083216 41870 example. > $TTL 0 ; 0 seconds > TYPE65534 \# 5 ( 0A03E40001 ) > TYPE65534 \# 5 ( 0AA38E0001 ) > $ORIGIN example. > $TTL 3600 ; 1 hour > a NS ns1.a > NS ns2.a > DS 23344 5 1 ( > CECDDBFFD6A0C01F8D7E96C4BE31CB577433DD56 ) > $ORIGIN a.example. > ns1 A 127.0.0.1 > ns2 A 127.0.0.1 > $ORIGIN example. > ai A 127.0.0.1 > ::1 > c NS ns1.c > NS ns2.c > $ORIGIN c.example. > ns1 A 127.0.0.5 > ns2 A 127.0.0.6 > $ORIGIN example. > ns1 A 127.0.0.3 > ns2 A 127.0.0.4 > w A 127.0.0.1 > $ORIGIN w.example. > * MX 10 ai.example. > x MX 10 xx.example. > x.y MX 10 xx.example. > $ORIGIN example. > xx A 127.0.0.1 > ::1 > - -- I cut and paste the zone (except for DS) and loaded it, added nsec3param, then signed and it went perfectly. I then added an a.example zone and did the same thing. I took the resulting dsset and added it into example using nsupdate and it was signed within moments. Are you following this same workflow? FWIW I use a script to add all my test zones from a zone template file. That script automatically adds the nsec3param as soon as the zone is loaded, but before it signs. That way
Re: BIND 9.8.0b1 Released Today
> > On 21.01.11 10:45, Sue Graves wrote: > >> * BIND now supports a new zone type, static-stub. This allows the > >> administrator of a recursive nameserver to force queries for a > >> particular zone to go to IP addresses of the administrator's choosing, > >> on a per zone basis, both globally or per view. I.e. if the > >> administrator wishes to have their recursive server query 192.0.2.1 and > >> 192.0.2.2 for zone example.com rather than the servers listed by the > >> .com gTLDs, they would configure example.com as a static-stub zone in > >> their recursive server. [RT #21474] > On 24/01/11 10:56, Matus UHLAR - fantomas wrote: > > what's the difference between these and "type forward" zones?" On 24.01.11 11:58, Cathy Almond wrote: > With forward zones, the server sends a recursive query and expects 'the > answer' in return. Other queries are handled iteratively by sending > non-recursive queries to authoritative nameservers - that includes those > for both stub and static-stub zones. > > (Conceptually, it's an explicit 'override' for the published nameserver > information for when named needs to send queries to the authoritative > nameservers for that zone). so, iiuc, the difference is that "type forward" sends queries with RD bit set, while "type static-stub" sends them with RD cleared... and the "forward first" option appears to be applicable only in forward zones. did I get it right? I use forward zones for blacklists - while I mirror some locally, but when my mirror fails, the usual resolution takes place. If I'm right, this is not possible with "type static-stub" zones. I wonder, what are expected usages for this kinds of zones? Maybe blacklists, if we have local mirrors and traffic so high that we'd get blocked imediately? -- 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. The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Clarification on CNAME
On 24.01.11 17:13, rams wrote: > y resolver is returning multiple CNAMEs for same hostname. But I believe > CNAME should not return same hostname with multiple values. correct. > Is this behavior is correct. Could you please clarify me. it's not. CNAME may be the only record type for a domain, only its signature may appear on it... the server that returns multiple cnames is broken. -- 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. Linux IS user friendly, it's just selective who its friends are... ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: lost records in a view
On 01/24/2011 12:23 PM, p...@mail.nsbeta.info wrote: I want the result that, when clients matching vb query for s2.example.com, they will get the answer from default view vc, since s2.example.com doesn't exist in vb. How to setup bind for this purpose? Copy the records from vc to vb. You cannot "fall back" with views. Each view is independent and complete. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
lost records in a view
Hello, Given I have 3 views, va,vb and vc, vc is the default (matches any client). There are three records in va and vc: s1.example.com. IN A 11.22.33.44 s2.example.com. IN A 22.33.44.55 s3.example.com. IN A 33.44.55.66 But there is a record lost in vb, say it's s2.example.com. I want the result that, when clients matching vb query for s2.example.com, they will get the answer from default view vc, since s2.example.com doesn't exist in vb. How to setup bind for this purpose? Thanks a lot. Regards. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.8.0b1 Released Today
On 24/01/11 10:56, Matus UHLAR - fantomas wrote: > On 21.01.11 10:45, Sue Graves wrote: >> * BIND now supports a new zone type, static-stub. This allows the >> administrator of a recursive nameserver to force queries for a >> particular zone to go to IP addresses of the administrator's choosing, >> on a per zone basis, both globally or per view. I.e. if the >> administrator wishes to have their recursive server query 192.0.2.1 and >> 192.0.2.2 for zone example.com rather than the servers listed by the >> .com gTLDs, they would configure example.com as a static-stub zone in >> their recursive server. [RT #21474] > > what's the difference between these and "type forward" zones?" With forward zones, the server sends a recursive query and expects 'the answer' in return. Other queries are handled iteratively by sending non-recursive queries to authoritative nameservers - that includes those for both stub and static-stub zones. (Conceptually, it's an explicit 'override' for the published nameserver information for when named needs to send queries to the authoritative nameservers for that zone). ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Clarification on CNAME
y resolver is returning multiple CNAMEs for same hostname. But I believe CNAME should not return same hostname with multiple values. Ex: Configured GEOIP records as follows: ramesh.com CNAME a.ramesh.com. ramesh.com CNAME az.ramesh.com. Arizone configured ramesh.com CNAME va.ramesh.com. Virginia configured ramesh.com CNAME others.ramesh.com. Others configured Queried “ramesh.com” from AZ,VA and OTHERS regions against my resolver. My resolver is returning same hostname with mutliple CNAME's. >From AZ i am getting: ramesh.com CNAME a.ramesh.com. ramesh.com CNAME az.ramesh.com. >From VA i am getting: ramesh.com CNAME a.ramesh.com. ramesh.com CNAME va.ramesh.com. Is this behavior is correct. Could you please clarify me. Thanks & regards, Ramesh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.8.0b1 Released Today
On 21.01.11 10:45, Sue Graves wrote: > * BIND now supports a new zone type, static-stub. This allows the > administrator of a recursive nameserver to force queries for a > particular zone to go to IP addresses of the administrator's choosing, > on a per zone basis, both globally or per view. I.e. if the > administrator wishes to have their recursive server query 192.0.2.1 and > 192.0.2.2 for zone example.com rather than the servers listed by the > .com gTLDs, they would configure example.com as a static-stub zone in > their recursive server. [RT #21474] what's the difference between these and "type forward" zones?" -- 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. M$ Win's are shit, do not use it ! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 2011-01-21 15:17, Kalman Feher pisze: >> Perhaps we are getting close to the problem then. >> Can you show the content of the key files? Specifically the metadata which >> the "maintain" option wants. > >> Since "allow" works I'm assuming that key file permissions (and directory >> permissions) are ok, but it couldn't hurt to check them. I've made new instalation without SoftHSM support to be sure that this is not an issue, and of course 'allow' works and 'maintain' the same odd things. permissions are ok, double-checked, and with 'allow' it works. key metadata, same for ZSK and KSK: ; Created: 20110121145849 (Fri Jan 21 15:58:49 2011) ; Publish: 20110121145937 (Fri Jan 21 15:59:37 2011) ; Activate: 20110121170117 (Fri Jan 21 18:01:17 2011) ; Inactive: 20110121220937 (Fri Jan 21 23:09:37 2011) ; Delete: 20110122001117 (Sat Jan 22 01:11:17 2011) and of course I'm waiting until Activate key event to be sure I will get RRSIG in response but there's now signatures. strange thing, that after signing zone with 'maintain' and after named dumps zone into plain file, file differs from this dumped with 'allow' option, much. for example don't have NSEC3PARAM in file from 'maintain' and DS record (authoritative) doesn't have even it's signature! zone with 'maintain' option: $ORIGIN . $TTL 3600 ; 1 hour example IN SOA ns1.example. bugs.x.w.example. ( 1292481918 ; serial 7200 ; refresh (2 hours) 3600 ; retry (1 hour) 734400 ; expire (1 week 1 day 12 hours) 600; minimum (10 minutes) ) RRSIG SOA 10 1 3600 20110223093216 ( 20110124083216 41870 example. SbFalU9K5yroRNtENT7nQHovxOXhl8ROOi90D77qFEXc NS ns1.example. NS ns2.example. TXT "dnssec test" $TTL 600; 10 minutes NSECa.example. NS SOA TXT RRSIG NSEC DNSKEY TYPE65534 $TTL 3600 ; 1 hour DNSKEY 256 3 10 ( AwEAAdByffBxPaxGFxfnf10TKUIwUKvq79vfMJ9wGW6s ) ; key id = 41870 DNSKEY 257 3 10 ( AwEAAdFituIkCms1lVbht+ykmwRUoBQJjHW9qep2GS1O ) ; key id = 996 RRSIG DNSKEY 10 1 3600 20110223093216 ( 20110124083216 996 example. LXfYVMI7BuQEEvYKpiadeboBHlv1RYv1vaaUoZLwnhC6 RRSIG DNSKEY 10 1 3600 20110223093216 ( 20110124083216 41870 example. $TTL 0 ; 0 seconds TYPE65534 \# 5 ( 0A03E40001 ) TYPE65534 \# 5 ( 0AA38E0001 ) $ORIGIN example. $TTL 3600 ; 1 hour a NS ns1.a NS ns2.a DS 23344 5 1 ( CECDDBFFD6A0C01F8D7E96C4BE31CB577433DD56 ) $ORIGIN a.example. ns1 A 127.0.0.1 ns2 A 127.0.0.1 $ORIGIN example. ai A 127.0.0.1 ::1 c NS ns1.c NS ns2.c $ORIGIN c.example. ns1 A 127.0.0.5 ns2 A 127.0.0.6 $ORIGIN example. ns1 A 127.0.0.3 ns2 A 127.0.0.4 w A 127.0.0.1 $ORIGIN w.example. * MX 10 ai.example. x MX 10 xx.example. x.y MX 10 xx.example. $ORIGIN example. xx A 127.0.0.1 ::1 - -- regards zbigniew jasinski [SYStem OPerator] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNPUwaAAoJEH26UYiRhe/gwDoP/ikpiRA/aLKoufjvUUs3+8OD BKzDUMUoHVQZ5kL+jiS0PA1gabTTL6iCyA7w+Rw6mwFsSM/SWqtjDE2EeKb27wYN osrRvPk6Cszq5W4hOD3PCZe93hcL/MZ8IQxF4qCW3v7XHpHQ7wXyttDC2KkIRcRI VNLaJDjD8MQsK1qAsPL86WXdZCousejUbPPNIc2mYyz/5fhOvCRFZ1ALW8ljuhqd hqM9gbv35d6nXg10yfdkp1nEOz7D25yU6KXhoeX4IOH4+qWvvs3e/zl7EY/BQ66k 4fco8fzkLik3hzAwyqbuBfiEH8/u7LjC8tcrMz3TuTsOdMkolgRVDorLsvKCz1WL eTp+9qe8PNrT5vCXsY7jz5ODgfiiKA9QbtSmAvvVVMnz5h1gBMZUyhLubA/ZCuhI A0UUSltbQo7yyZgfy8UW+3rV2mdyHJJ7wTGMbW0B0uzS59Uks/XIQ5kDDBAo/1fh fPJGPpbN5Ak93B2s/kMdYoCcFNRhLb8TtUGZduL4oZtPbX7stmP/+Nq2ghwyeM4f VlheVVE7GTAUOpkFhu/QxBnO2KIO6RbsTNfoI2vJNrZkmKgffbE4AacgBpktjp5X 7oB7mJifkzT7xSbbcf0AOgyBLuMrrkaa4tK0arzfDtF+0jV