RE: ipv6 adoption
I'm already using Hurricane for my external slave servers to I will have a dig through their site thanks Andy Baker IT Technical Lead | SIIL Corporate IT Tel: +974-44838733, Direct: +974-44485711| Fax: +974-44838732 Salam International Investments Ltd. Maysaloun Street - West Bay | Salam Plaza Tower, 3rd Floor | PO Box: 15224, Doha – Qatar E-mail: a.ba...@salaminternational.com| Website: www.salaminternational.com -Original Message- From: bind-users On Behalf Of Mark Tinka Sent: Wednesday, February 16, 2022 6:53 PM To: bind-users@lists.isc.org Subject: Re: ipv6 adoption On 2/16/22 17:18, Timothe Litt wrote: > You can get IPv6 via a tunnel broker. Hurricane Electric > (http://he.net/) is one of the larger ones. You can get a /48 from > them - for free. Bandwidth is modest. You can setup reverse zones; > they'll delegate. I don't think they support DNSSEC - it's been on > their wishlist for years. > Ah, I misunderstood the OP's question - I thought he meant if their provider does IPv6, but cannot assign an IPv6 address from their PA space. Yes, if your providers does not yet support IPv6, then a tunnel broker like HE (and others) are workable. Mark. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ipv6 adoption
On 2/16/22 9:24 AM, G.W. Haywood via bind-users wrote: FWIW I've been using DNSSEC with HE slaves since October 2017. I'm happy to report that I've never had any problem with the service. Please clarify if you are talking about DNSSEC for your own zone that they are doing secondary transfers of or if you are talking about DNSSEC for the IPv6's reverse DNS namespace that they delegate to you. Also, +1 for the H.E. IPv6 training. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ipv6 adoption
> On 16 Feb 2022, at 23:38, Andrew Baker via bind-users > wrote: > > Firstly, thanks for the advice about the hidden master the other day, that’s > now setup, working fine and we’ve just finished transferring about 4500 > records across! > My software team came up this morning and slapped me across the face with a > wet fish (figuratively speaking as It’s not Thursday yet!) by informing me > that they are developing a mobile app for one of our companies that Apple > have mandated an ipv6 DNS requirement before they publish. Firstly welcome to the 21st century. > At the moment, all our infrastructure from ISP device inwards is ipv4 so > setting up the zone on our DNS is going to require a lot of significant > changes! There are a couple of things reference all this that I’m unsure > about and am hoping you can educate me on. > > Firstly, we are running bind 9.11 on Debian 10 hosts. > • Is it worth use upgrading to Debian 11 to get the newer version of > bind? BIND 9.11 supports IPv6 fine. There is no reason to upgrade if you just want to add records or to use IPv6 as a transport. That said BIND 9.11 is reaching EOL so its time to upgrade for that reason. > • Are there any issues/bugs/holes in 9.11 that will cause us a problem, > especially if we start messing with ipv6? No. BIND had supported IPv6 as a transport for over 20 years now. > • If I do upgrade the on-premise servers, is it better to do master > then slaves or the other way around? Doesn’t matter. > • If we have DNSSEC configured, is it going to break anything > upgrading? (I have lots of backups of the zones and hosts files) No. > Secondly, reference bind config > • For the “listen-on-v6” statement, are the only options still ‘none’ > or ‘all’? Those have never been the only choices. If you didn’t properly populate the chroot area and you where using chroot then you couldn’t enumerate the IPv6 interfaces on Linux as it required '/proc/net/if_inet6’ to exist. > • Can the “listen-on-v6” only be enabled globally in the > ‘named.conf.options’ or is it possible to enable per zone as we are > (currently) only going to have 1 zone needing ipv6? Listening on IPv6 is parameter of the server not the zone. For the record listening on IPv4 is also a parameter of the server. > • Once ipv6 is enabled. Is it advisable to setup a sub-domain for the > ipv6 addresses to avoid dual-stacking? Not really. > The reverse zones for our ipv4 are handled (badly) by our local telecoms > provider. How big an issue is it going to be for ipv6 if the reverse lookups > are badly/not implemented? IPv6 is actually easier as IPv6 address blocks are usually handed out on nibble boundaries (/(n*4) e.g. /32, /48, /60, /64) which corresponds to break points in the ipv6.arpa tree. Just add PTR records for the machines that exist. IPv4 address blocks are usually not delegated on byte boundaries so you need to have multiple zone or use CNAMES for /25-/31 sized delegations (See RFC 2317). > If our ISP can’t give us a public ipv6 address, can we still run our bind to > give out ipv6 addresses or not? Apple want to be able to connect to your servers over IPv6 without using any IPv6 at all. I suspect that they test from IPv6-only networks. The first step is to have some of your servers on IPv6 with glue records for them. > Finally, can anyone point me towards any good reading on bind configuration > and DNS best practice (preferably with idiot proof examples)? I must decide > fairly quickly if we roll this zone back to our domain registrar who is setup > to handle ipv6 or do we strike out and bring our DNS setup up to date and > future proofed! > > Thanks for your time and expertise. > > > Andy Baker > > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ipv6 adoption
Hi there, On Wed, 16 Feb 2022, Mark Tinka wrote: On 2/16/22 17:18, Timothe Litt wrote: > You can get IPv6 via a tunnel broker.? Hurricane Electric > (http://he.net/) is one of the larger ones.? You can get a /48 from > them - for free.? Bandwidth is modest.? You can setup reverse zones; > they'll delegate.? I don't think they support DNSSEC - it's been on > their wishlist for years. Ah, I misunderstood the OP's question - I thought he meant if their provider does IPv6, but cannot assign an IPv6 address from their PA space. Yes, if your providers does not yet support IPv6, then a tunnel broker like HE (and others) are workable. FWIW I've been using DNSSEC with HE slaves since October 2017. I'm happy to report that I've never had any problem with the service. -- 73, Ged. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ipv6 adoption
On 2/16/22 17:50, Grant Taylor via bind-users wrote: Most of the -- what I'll call -- binary distributions of Linux tend to have a fairly small range of any given versions of software in the repositories provided by the Linux distribution provider. There is nothing that prevents you from sourcing other versions, binary or compile it yourself, from other providers. But some people are unwilling to accept the risk. Yes, it's all coming back to now from my SuSE/OpenSUSE days. It's one of the reasons we like FreeBSD. The base OS is just a(n empty) shell, really. The Ports is where all the magic is, and they generally are OS-version independent, as well as having the current, past and bleeding edge versions. Here's an example for those who aren't familiar with FreeBSD: [root@ns-01-jnb /home/tinka]# ls /usr/ports/dns/bind bind-tools/ bind9-devel/ bind911/ bind912/ bind913/ bind916/ bind918/ bindgraph/ [root@ns-01-jnb /home/tinka]# Mark. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ipv6 adoption
> On 16 Feb 2022, at 16:50, Grant Taylor via bind-users > wrote: > > On 2/16/22 7:35 AM, Mark Tinka wrote: >> I was assuming Linux has something similar, where in userland, you have the >> option to install which train of BIND you want, regardless of OS version. > > Most of the -- what I'll call -- binary distributions of Linux tend to have a > fairly small range of any given versions of software in the repositories > provided by the Linux distribution provider. > > There is nothing that prevents you from sourcing other versions, binary or > compile it yourself, from other providers. But some people are unwilling to > accept the risk. Well, (shameless plug) that’s the great thing about FreeBSD Ports. Moreover, many packages have important compile time options. What did the packager decide to omit for whatever reasons? For software in which knowing what you are running is critical (such as bind) it’s a no brainer. Borja. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ipv6 adoption
On 2/16/22 17:18, Timothe Litt wrote: You can get IPv6 via a tunnel broker. Hurricane Electric (http://he.net/) is one of the larger ones. You can get a /48 from them - for free. Bandwidth is modest. You can setup reverse zones; they'll delegate. I don't think they support DNSSEC - it's been on their wishlist for years. Ah, I misunderstood the OP's question - I thought he meant if their provider does IPv6, but cannot assign an IPv6 address from their PA space. Yes, if your providers does not yet support IPv6, then a tunnel broker like HE (and others) are workable. Mark. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ipv6 adoption
On 2/16/22 7:35 AM, Mark Tinka wrote: I was assuming Linux has something similar, where in userland, you have the option to install which train of BIND you want, regardless of OS version. Most of the -- what I'll call -- binary distributions of Linux tend to have a fairly small range of any given versions of software in the repositories provided by the Linux distribution provider. There is nothing that prevents you from sourcing other versions, binary or compile it yourself, from other providers. But some people are unwilling to accept the risk. But thinking about the days when I ran SuSE Linux and OpenSUSE (up until 2007), I think I recall apps being tied to major/minor OS versions, when they used RPM as the package manager. It's been a while, so things may have since changed. I'm used to seeing ~current, down level, and maybe bleeding level in the beta / early adopters distro releases. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
On 2/16/22 17:15, Borja Marcos wrote: Now I have 9.11.36, 9.16.24 and 9.18.0 What I have noticed with 9.18.0, which is running on the heaviest loaded server, is less memory footprint. I started it on Monday and according to top it’s taking 486 MB (SIZE) - 375 MB (RES). And the memory pressure is much less. It’a working fine but in ISCs tradition of squeezing bad practices it will give you errors for misconfigured domains. I have had to add some “server” clauses disabling cookies and all that. I am updating the server running 9.16.24 to .25. Let’s see how it goes. Running 9.16.24 it takes 1462 MB (size) - 1233 MB (res). I restarted named on 17th January. The load is not exactly the same. They are both part of an anyast pool, but one of them gets more email server requests while the other one receives mostly customer queries. Awesome feedback! Thanks, Borja :-). Keen to hear what you see re: 9.16.25. Mark. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: ipv6 adoption
> HE has a lot of IPv6 educational materials (not bind-specific) that are quite > good. I wasn't aware, but this looks worthy and I'm going to do it: https://ipv6.he.net/certification/ Also to the OP here's another +1 that Debian 10 bind version does IPv6 just fine, and +1 upgrade it anyway before it reaches EOL. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ipv6 adoption
On 16-Feb-22 07:38, Andrew Baker wrote: Firstly, thanks for the advice about the hidden master the other day, that’s now setup, working fine and we’ve just finished transferring about 4500 records across! My software team came up this morning and slapped me across the face with a wet fish (figuratively speaking as It’s not Thursday yet!) by informing me that they are developing a mobile app for one of our companies that Apple have mandated an ipv6 DNS requirement before they publish. At the moment, all our infrastructure from ISP device inwards is ipv4 so setting up the zone on our DNS is going to require a lot of significant changes! There are a couple of things reference all this that I’m unsure about and am hoping you can educate me on. Firstly, we are running bind 9.11 on Debian 10 hosts. * Is it worth use upgrading to Debian 11 to get the newer version of bind? * Are there any issues/bugs/holes in 9.11 that will cause us a problem, especially if we start messing with ipv6? * If I do upgrade the on-premise servers, is it better to do master then slaves or the other way around? * If we have DNSSEC configured, is it going to break anything upgrading? (I have lots of backups of the zones and hosts files) Secondly, reference bind config * For the “listen-on-v6” statement, are the only options still ‘none’ or ‘all’? * Can the “listen-on-v6” only be enabled globally in the ‘named.conf.options’ or is it possible to enable per zone as we are (currently) only going to have 1 zone needing ipv6? * Once ipv6 is enabled. Is it advisable to setup a sub-domain for the ipv6 addresses to avoid dual-stacking? The reverse zones for our ipv4 are handled (badly) by our local telecoms provider. How big an issue is it going to be for ipv6 if the reverse lookups are badly/not implemented? If our ISP can’t give us a public ipv6 address, can we still run our bind to give out ipv6 addresses or not? Finally, can anyone point me towards any good reading on bind configuration and DNS best practice (preferably with idiot proof examples)? I must decide fairly quickly if we roll this zone back to our domain registrar who is setup to handle ipv6 or do we strike out and bring our DNS setup up to date and future proofed! Thanks for your time and expertise. Andy Baker ** You can get IPv6 via a tunnel broker. Hurricane Electric (http://he.net/) is one of the larger ones. You can get a /48 from them - for free. Bandwidth is modest. You can setup reverse zones; they'll delegate. I don't think they support DNSSEC - it's been on their wishlist for years. I use 9.11 (and have used previous) versions of bind with IPv6 - no IPv6 issues. Zones have nothing to do with dual stack. If you create an record, your host can be found via IPv6. If you create an A record, IPv4. Both gives you "dual stack". I tend to create x.v[46].example.net style names in addition to x.example.net for cases where I want one or the other. This doesn't require a zone - it's just a name. One reason to not configure your host with both A and records may be that most resolvers will prefer V6, but if you have a tunnel for V6 & a wide pipe to your ISP, you may find that you're connecting thru the tunnel & limited by its bandwidth. There is no requirement for named to listen on IPv6 for it to serve records. That's orthogonal, and dependent on what the resolver(s) can live with. HE has a lot of IPv6 educational materials (not bind-specific) that are quite good. Depending on where you are in the world, there are other brokers. I switched to HE when SiXXS went out of business and have been happy. I have no other connection to HE. YMMV. DNSSEC doesn't care what transport protocol is used or what records are served. It just signs them. Moving, you do need to make sure that the keys and delegations are present on the receiving end. Once the move is complete, it may be a good time to do a key roll. Finally, it's not clear from your note how you're setup, but if you run your own servers, you need to meet the geographic dispersion rules. At least 2 servers in two places. That's true no matter what protocols you use. There are backup DNS services that support IPv6. A free one that supports both IPv6 and DNSSEC is puck.nether.net/dns. There are plenty of DNS books/guides. I'll let someone else do the reviews. Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. OpenPGP_signature Description: OpenPGP digital signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
> On 16 Feb 2022, at 10:53, Mark Tinka wrote: > > Hi all. > > Just coming back to this... > > I notice that the release notes for 9.16.25 say the memory leak issue on > FreeBSD is now fixed: > > * > > On FreeBSD, TCP connections leaked a small amount of heap memory, leading to > an eventual out-of-memory problem. This has been fixed in: > > https://gitlab.isc.org/isc-projects/bind9/-/issues/3051 > > * > > If anyone was running/testing this train prior to this update on FreeBSD as a > resolver, have you seen the problem go away? > > I know Borja was testing, but haven't heard from him in a while :-). I’m here ;) > We are still happily running 9.11.36 on our busiest resolvers, with no issue. Now I have 9.11.36, 9.16.24 and 9.18.0 What I have noticed with 9.18.0, which is running on the heaviest loaded server, is less memory footprint. I started it on Monday and according to top it’s taking 486 MB (SIZE) - 375 MB (RES). And the memory pressure is much less. It’a working fine but in ISCs tradition of squeezing bad practices it will give you errors for misconfigured domains. I have had to add some “server” clauses disabling cookies and all that. I am updating the server running 9.16.24 to .25. Let’s see how it goes. Running 9.16.24 it takes 1462 MB (size) - 1233 MB (res). I restarted named on 17th January. The load is not exactly the same. They are both part of an anyast pool, but one of them gets more email server requests while the other one receives mostly customer queries. Borja. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ipv6 adoption
> On 16. 2. 2022, at 14:50, Reindl Harald wrote: > > not when you don't use 3rd party repos or build it at your own - the whole > point of a stable distibution is to not have random major-upgrades of software Technically, using ISC repositories would be 0-party as it’s upstream provider of the software. > and unless you have no very good reason you should either stay at the > packages from your distribution or make a dist-upgrade Everything has its pros and its cons. Using the conservative distributions also often means being stuck in past. > otherwise you end in the chaos MacOS and Windows are when it comes to keep > everything up-to-date and get security bugs fixed - linux distributions are > backporting security fixes Debian bullseye follows patch releases of 9.16 and not just backporting security fixes. Nevertheless, Debian buster is almost EOL (June 2022), so you should upgrade to bullseye in any case. Ondřej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ipv6 adoption
On 2/16/22 15:49, Reindl Harald wrote: not when you don't use 3rd party repos or build it at your own - the whole point of a stable distibution is to not have random major-upgrades of software and unless you have no very good reason you should either stay at the packages from your distribution or make a dist-upgrade otherwise you end in the chaos MacOS and Windows are when it comes to keep everything up-to-date and get security bugs fixed - linux distributions are backporting security fixes We use FreeBSD for services, and regardless of major/minor OS version, the FreeBSD ports (and packages) will always support the various trains of the app. It's just a case of what you want to install. I was assuming Linux has something similar, where in userland, you have the option to install which train of BIND you want, regardless of OS version. But thinking about the days when I ran SuSE Linux and OpenSUSE (up until 2007), I think I recall apps being tied to major/minor OS versions, when they used RPM as the package manager. It's been a while, so things may have since changed. Mark. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ipv6 adoption
Am 16.02.22 um 14:25 schrieb Mark Tinka: On 2/16/22 14:38, Andrew Baker via bind-users wrote: Firstly, we are running bind 9.11 on Debian 10 hosts. * Is it worth use upgrading to Debian 11 to get the newer version of bind? I don't run Linux, but shouldn't it be possible to just upgrade only BIND on your current Linux release, without having to change major OS versions? not when you don't use 3rd party repos or build it at your own - the whole point of a stable distibution is to not have random major-upgrades of software and unless you have no very good reason you should either stay at the packages from your distribution or make a dist-upgrade otherwise you end in the chaos MacOS and Windows are when it comes to keep everything up-to-date and get security bugs fixed - linux distributions are backporting security fixes -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ipv6 adoption
On 2/16/22 14:38, Andrew Baker via bind-users wrote:
Firstly, we are running bind 9.11 on Debian 10 hosts.
* Is it worth use upgrading to Debian 11 to get the newer version of
bind?
I don't run Linux, but shouldn't it be possible to just upgrade only
BIND on your current Linux release, without having to change major OS
versions?
*
* Are there any issues/bugs/holes in 9.11 that will cause us a
problem, especially if we start messing with ipv6?
None that I can tell.
We are running bind911-9.11.36 happily as a resolver. Given
authoritative name servers would be less busy, I imagine you'll be fine
from that standpoint.
*
* If I do upgrade the on-premise servers, is it better to do master
then slaves or the other way around?
I've done both ways, because I've found it doesn't matter, especially if
you have more than one master.
* If we have DNSSEC configured, is it going to break anything
upgrading? (I have lots of backups of the zones and hosts files)
Take your time understanding DNSSEC, and how to set it up. I'd do this
long after adding IPv6 support, as that is what is most urgent, if I
hear you right.
Secondly, reference bind config
* For the “listen-on-v6” statement, are the only options still
‘none’ or ‘all’?
On all our name servers, we have this:
listen-on-v6 { any; };
Works great.
*
* Can the “listen-on-v6” only be enabled globally in the
‘named.conf.options’ or is it possible to enable per zone as we
are (currently) only going to have 1 zone needing ipv6?
Good question - I don't know.
But I'd suspect it's a global setting, because the protocol BIND listens
on has nothing to do with what it answers, i.e., you can carry an IPv6
response over IPv4.
* Once ipv6 is enabled. Is it advisable to setup a sub-domain for
the ipv6 addresses to avoid dual-stacking?
You could if you want to, but there is no relationship between the
A/ records in the zone, and how the server's TCP/IP stack is configured.
We just have all IPv4 and IPv6 records in the same zone, with the server
dual-stacked.
*
The reverse zones for our ipv4 are handled (badly) by our local
telecoms provider. How big an issue is it going to be for ipv6 if the
reverse lookups are badly/not implemented?
You can choose to handle your own PTR, assuming the IPv6 space is yours.
Unless I misunderstand...
If our ISP can’t give us a public ipv6 address, can we still run our
bind to give out ipv6 addresses or not?
Yes - you can answer to IPv6 DNS queries, and provide that answer over
IPv4, i.e., you can answer an query over IPv4. The answer and the
transport don't have to be congruent.
Finally, can anyone point me towards any good reading on bind
configuration and DNS best practice (preferably with idiot proof
examples)? I must decide fairly quickly if we roll this zone back to
our domain registrar who is setup to handle ipv6 or do we strike out
and bring our DNS setup up to date and future proofed!
https://www.oreilly.com/library/view/dns-and-bind/9781449308025/
Mark.--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: about apply Deckard to test BIND named
On 16. 02. 22 10:12, Ondřej Surý wrote: I guess you can possibly workaround this by disabling jemalloc from named build and hope that the static shims for jemalloc calls will trump the preloaded functions from libfaketime. Oh right, I forgot we can also compile BIND without jemalloc - it works! So, this Deckard commit adds support for BIND: https://gitlab.nic.cz/knot/deckard/-/merge_requests/217/diffs?commit_id=7668661a63d59388a8b1e7e372f58f43ff561934 Be warned that many tests will require tweaking to make them pass on BIND. One such example is: https://gitlab.nic.cz/knot/deckard/-/merge_requests/217/diffs?commit_id=aa70a23ca2dd04929d1425257322bcd55c661065 Enjoy testing BIND :-) Petr Špaček @ Internet Systems Consortium On 16. 2. 2022, at 9:59, Petr Špaček wrote: - It does not work anyway because jemalloc library used by libfaketime breaks libfaketime library is used by Deckard for DNSSEC tests. See https://github.com/wolfcw/libfaketime/issues/130. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
ipv6 adoption
Firstly, thanks for the advice about the hidden master the other day, that's now setup, working fine and we've just finished transferring about 4500 records across! My software team came up this morning and slapped me across the face with a wet fish (figuratively speaking as It's not Thursday yet!) by informing me that they are developing a mobile app for one of our companies that Apple have mandated an ipv6 DNS requirement before they publish. At the moment, all our infrastructure from ISP device inwards is ipv4 so setting up the zone on our DNS is going to require a lot of significant changes! There are a couple of things reference all this that I'm unsure about and am hoping you can educate me on. Firstly, we are running bind 9.11 on Debian 10 hosts. * Is it worth use upgrading to Debian 11 to get the newer version of bind? * Are there any issues/bugs/holes in 9.11 that will cause us a problem, especially if we start messing with ipv6? * If I do upgrade the on-premise servers, is it better to do master then slaves or the other way around? * If we have DNSSEC configured, is it going to break anything upgrading? (I have lots of backups of the zones and hosts files) Secondly, reference bind config * For the "listen-on-v6" statement, are the only options still 'none' or 'all'? * Can the "listen-on-v6" only be enabled globally in the 'named.conf.options' or is it possible to enable per zone as we are (currently) only going to have 1 zone needing ipv6? * Once ipv6 is enabled. Is it advisable to setup a sub-domain for the ipv6 addresses to avoid dual-stacking? The reverse zones for our ipv4 are handled (badly) by our local telecoms provider. How big an issue is it going to be for ipv6 if the reverse lookups are badly/not implemented? If our ISP can't give us a public ipv6 address, can we still run our bind to give out ipv6 addresses or not? Finally, can anyone point me towards any good reading on bind configuration and DNS best practice (preferably with idiot proof examples)? I must decide fairly quickly if we roll this zone back to our domain registrar who is setup to handle ipv6 or do we strike out and bring our DNS setup up to date and future proofed! Thanks for your time and expertise. Andy Baker -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
Hi all. Just coming back to this... I notice that the release notes for 9.16.25 say the memory leak issue on FreeBSD is now fixed: * On FreeBSD, TCP connections leaked a small amount of heap memory, leading to an eventual out-of-memory problem. This has been fixed in: https://gitlab.isc.org/isc-projects/bind9/-/issues/3051 * If anyone was running/testing this train prior to this update on FreeBSD as a resolver, have you seen the problem go away? I know Borja was testing, but haven't heard from him in a while :-). We are still happily running 9.11.36 on our busiest resolvers, with no issue. 9.16. 25 is working fine for our authoritative servers. 9.18 is too new for us. We have no issue keeping 9.11.36 well beyond its EoL date on our resolvers, if it means 9.16 needs further improvements for that use-case. Thanks. Mark.-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about apply Deckard to test BIND named
I guess you can possibly workaround this by disabling jemalloc from named build and hope that the static shims for jemalloc calls will trump the preloaded functions from libfaketime. Ondřej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 16. 2. 2022, at 9:59, Petr Špaček wrote: > > - It does not work anyway because jemalloc library used by libfaketime breaks > libfaketime library is used by Deckard for DNSSEC tests. See > https://github.com/wolfcw/libfaketime/issues/130. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about apply Deckard to test BIND named
Hi, it is even more complicated: - Latest version of Deckard uses Linux network namespaces and thus makes BIND GL#2088 unnecessary - It does not work anyway because jemalloc library used by libfaketime breaks libfaketime library is used by Deckard for DNSSEC tests. See https://github.com/wolfcw/libfaketime/issues/130. So for now you are out of luck. Besides that other points raised by Ondrej below are valid. Petr Špaček @ Internet Systems Consortium On 16. 02. 22 9:04, Ondřej Surý wrote: Hi Sun, this is impressive effort, but it has several known gotchas: 1. The `named` looks for real interfaces to listen too and it didn’t play well with Deckard in the past. I’ve been told that this is no longer a problem, but it could be something you should be aware of. See [GL #2088] 2. This is not an easy way to get a “street cred”. First of all, the Deckard tests needs to be tailored for a specific DNS daemon. Every DNS server has its quirks and this is definitely not something that you can take, run and fill issues “named failed Deckard test”. Every failure needs to be individually examined, debugged, explained and described. It might not be a bug, but just a difference in behavior. 3. Running Deckard as “one time thing” is not appealing at all. Any work in this area needs to integrate with the repository. Adding a GitLab CI job would be a bare minimum here. 4. Create an issue (I thought there’s already one as integrating Deckard has been on our TODO list for couple of years now), and track all the ideas and progress there. GL #2088: https://gitlab.isc.org/isc-projects/bind9/-/issues/2088 -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. On 16. 2. 2022, at 8:32, Sun Guonian via bind-users wrote: Hi, I notice that Deckard project can be used to test knot/knot-resolver/unbound/pdns except BIND. And I try to write the configuration and template files for named, but it didn't work. If BIND's implementation/configuration has any limitation to run with Deckard ? Thanks in advance ! Best Regards, SUN Guonian P.S. Deckard's homepage on github.com is https://github.com/CZ-NIC/deckard -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about apply Deckard to test BIND named
Thank Ondřej for the information ! Best Regards,SUN Guonian On Wednesday, February 16, 2022, 04:05:06 PM GMT+8, Ondřej Surý wrote: Hi Sun, this is impressive effort, but it has several known gotchas: 1. The `named` looks for real interfaces to listen too and it didn’t play well with Deckard in the past. I’ve been told that this is no longer a problem, but it could be something you should be aware of. See [GL #2088] 2. This is not an easy way to get a “street cred”. First of all, the Deckard tests needs to be tailored for a specific DNS daemon. Every DNS server has its quirks and this is definitely not something that you can take, run and fill issues “named failed Deckard test”. Every failure needs to be individually examined, debugged, explained and described. It might not be a bug, but just a difference in behavior. 3. Running Deckard as “one time thing” is not appealing at all. Any work in this area needs to integrate with the repository. Adding a GitLab CI job would be a bare minimum here. 4. Create an issue (I thought there’s already one as integrating Deckard has been on our TODO list for couple of years now), and track all the ideas and progress there. GL #2088: https://gitlab.isc.org/isc-projects/bind9/-/issues/2088 -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 16. 2. 2022, at 8:32, Sun Guonian via bind-users > wrote: > > Hi, > > I notice that Deckard project can be used to test > knot/knot-resolver/unbound/pdns except BIND. > And I try to write the configuration and template files for named, but it > didn't work. > > If BIND's implementation/configuration has any limitation to run with Deckard > ? > > Thanks in advance ! > > Best Regards, > SUN Guonian > > > P.S. > Deckard's homepage on github.com is https://github.com/CZ-NIC/deckard > > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about apply Deckard to test BIND named
Hi Sun, this is impressive effort, but it has several known gotchas: 1. The `named` looks for real interfaces to listen too and it didn’t play well with Deckard in the past. I’ve been told that this is no longer a problem, but it could be something you should be aware of. See [GL #2088] 2. This is not an easy way to get a “street cred”. First of all, the Deckard tests needs to be tailored for a specific DNS daemon. Every DNS server has its quirks and this is definitely not something that you can take, run and fill issues “named failed Deckard test”. Every failure needs to be individually examined, debugged, explained and described. It might not be a bug, but just a difference in behavior. 3. Running Deckard as “one time thing” is not appealing at all. Any work in this area needs to integrate with the repository. Adding a GitLab CI job would be a bare minimum here. 4. Create an issue (I thought there’s already one as integrating Deckard has been on our TODO list for couple of years now), and track all the ideas and progress there. GL #2088: https://gitlab.isc.org/isc-projects/bind9/-/issues/2088 -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 16. 2. 2022, at 8:32, Sun Guonian via bind-users > wrote: > > Hi, > > I notice that Deckard project can be used to test > knot/knot-resolver/unbound/pdns except BIND. > And I try to write the configuration and template files for named, but it > didn't work. > > If BIND's implementation/configuration has any limitation to run with Deckard > ? > > Thanks in advance ! > > Best Regards, > SUN Guonian > > > P.S. > Deckard's homepage on github.com is https://github.com/CZ-NIC/deckard > > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
