Re: Determining case of REFUSED queries
On Thu, Oct 3, 2024 at 6:23 PM Lyle Giese via bind-users wrote: > I get this: > ; <<>> DiG 9.16.50-Debian <<>> ns socialinnovation.ca >... > socialinnovation.ca.3600IN NS dns.rebel.ca. > socialinnovation.ca.3600IN NS sean.ns.cloudflare.com. > socialinnovation.ca.3600IN NS kami.ns.cloudflare.com. > socialinnovation.ca.3600IN NS dns2.rebel.ca. >...> > But a whois query for this domain only lists dns.rebel.ca and dns2.rebel.ca > for name servers. The Cloudflare NSs are coming from the apex NS RRset as returned by rebel.ca. > Wonder if the cloudflare server are not getting a good axfr from the rebel.ca > servers or something else is wrong. REFUSED would tend to indicate that Cloudflare is just not configured for the zone at all. -- tale -- 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: qname minimization: me too :(
On Tue, Jun 25, 2024 at 10:42 AM Stephane Bortzmeyer wrote:
> > Jun 25 16:18:31 conr named[4725]: lame-servers:
> >info: success resolving 'bar.foo.isc.org/A' after disabling
> >qname minimization due to 'ncache nxdomain'
>
> I do not see how this is possible ("success resolving") since the name
> does not exist and all ISC name servers reply it does not exist.
>
> And all the resolvers I tried (through RIPE Atlas) say the same. No
> "success resolving".
Admittedly "success" can be ambiguous, and in this case it means
successfully got an answer for the question that was originally being
pursued. In this context, a negative answer is still a successful
resolution, unlike timeout or servfail from auths or various other
failures.
--
tale
--
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: Observation: BIND 9.18 qname-minimization strict vs dig +trace
Hmm, I wonder if qname-minimisation is at issue here. My trace dies with: 85.191.131.in-addr.arpa. 1800 IN NS fs838.click-network.com. 85.191.131.in-addr.arpa. 1800 IN NS ns102.click-network.com. couldn't get address for 'fs838.click-network.com': not found couldn't get address for 'ns102.click-network.com': not found -- 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: Unable to Query DoH with `tls none` and Plain HTTP
On Tue, Jan 2, 2024 at 4:38 AM Jakob Bohm via bind-users wrote: > Having the DoH server as a standalone process talking to DNS/TCP would > be a solid implementation given the constant flow of changes made to > HTTP(S) by the Big 5. Perhaps, but for reference here is the relevant section of the DoH spec: https://datatracker.ietf.org/doc/html/rfc8484#section-5.2 HTTP/2 [RFC7540] is the minimum RECOMMENDED version of HTTP for use with DoH. The messages in classic UDP-based DNS [RFC1035] are inherently unordered and have low overhead. A competitive HTTP transport needs to support reordering, parallelism, priority, and header compression to achieve similar performance. Those features were introduced to HTTP in HTTP/2 [RFC7540]. Earlier versions of HTTP are capable of conveying the semantic requirements of DoH but may result in very poor performance. That ISC has chosen to follow the minimum HTTP version as recommended by the RFC is solid ground on which to be standing. -- tale -- 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: Delegation NS-records when zones share an authority server
it'll matter when you decide to add DNSSEC to the zone, and it's also good hygiene in the absence of DNSSEC so that any future maintainer can be reminded that there is a subdomain at that name when looking at the parent. -- 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: Intermittent issues resolving "labor.upload.akamai.com"
On Fri, Feb 3, 2023 at 4:32 AM Greg Choules via bind-users
wrote:
>> From a quick look in Wireshark at what my own server (9.18.8) is doing, this
>> looks like Akamai not responding correctly to a BIND QNAME minimisation
>> query. Here's one response, from 95.101.36.192 for example, of many similar
>> ones showing an issue. The response code shouldn't be REFUSED:
Definitely protocol issues going on with akamai.net. A query for the
target in the OP, at an akamai.net auth, indicates that there's a
zone cut at e.stor:
dig +noall +auth r33674-33729.neards.1.cftp.e.stor.lb.akamai.net
@zc.akamaitech.net
e.stor.lb.akamai.net. 4000IN NS n4e.stor.lb.akamai.net.
e.stor.lb.akamai.net. 4000IN NS n0e.stor.lb.akamai.net.
e.stor.lb.akamai.net. 4000IN NS n3e.stor.lb.akamai.net.
e.stor.lb.akamai.net. 4000IN NS n2e.stor.lb.akamai.net.
e.stor.lb.akamai.net. 4000IN NS n1e.stor.lb.akamai.net.
but it returns that the stor label is a lame delegation:
dig stor.lb.akamai.net @zc.akamaitech.net | awk '/status/ {print $6}'
REFUSED,
Even if lb were itself delegated, REFUSED is still the wrong answer
for stor; in that case it should get the delegation for lb. But lb
isn't delegated either, so refused is even more wrongerer.
I'll forward this over to Akamai.
--
tale
--
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: Issue Using Wildcards for Subdimain Redirecing
On Thu, Feb 17, 2022 at 3:34 AM muhanad wrote: > I have a main domain ( aa.example.com) with hunderds of subdomains ( > bb.aa.example.com). I made a wildcard record to forward all subdomains (bb.) > to a list of addresses in round-robin fashion. The problem I am fscing is > the wildcard is forwarding anything towards the the IP ( example , "cc.bb." > which is not a vaild subdomain). How can I limit that so it will only > forwards ( bb.aa.example.com) and drops any invalid subdomains ( > cc.bb.aa.example.com ). > > Note: aa, bb, and cc being any arbitary value. With a standard BIND zone, you can't. Wildcards match multiple labels. That goes to the earliest days of the DNS, https://www.rfc-editor.org/rfc/rfc1034#section-4.3.3. You'd need a specialized handler to do this. -- tale -- 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: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On Wed, Dec 29, 2021 at 5:31 AM Danilo Godec via bind-users wrote: > I have an authoritative DNS server for a domain, but I was also going to > use the same server as a recursive DNS for my internal network, limiting > recursion by the IP. Apparently, this is a bad idea that can lead to > cache poisoning... In short, no, this configuration with a BIND 9 server does not increase your risk of cache poisoning any more than running your local server in pure recursive mode. I'm curious to hear more from the source that has given you this impression. I suspect there were some additional qualifications that don't align with what you've described. -- tale ___ Please 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: Add DNS records automatically for static IP's
On Mon, Aug 9, 2021 at 8:46 AM Roberto Carna wrote: > Thanks to all of you, is it possible to use nslookup in order to > update DNS records from Linux hosts to a Windows DNS server (not BIND) Not nslookup, but nsupdate as Brian Cuttler said. nslookup is purely a query tool; nsupdate implements the DNS Update protocol, which is one of the mechanisms that Windows DNS server supports. So, yes, you can go Linux -> Windows using nsupdate. > El jue, 5 ago 2021 a las 14:14, Cuttler, Brian R (HEALTH) > () escribió: > > I've been using nsupdate for that. -- tale ___ Please 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: Add DNS records automatically for static IP's
On Thu, Aug 5, 2021 at 12:19 PM Roberto Carna wrote: > I have several hosts with static IP's / hostnames and I want to > register them to our private BIND DNS, and they should be updated if > the IP or hostname changes. > > Is there any way to do what I need ? Any Linux/Windows client to > install in the servers in order to register IP and hostname to aour > provate BIND ??? What you're looking for is DHCP configuration. For example, with ISC's DHCP server implementation you would use the "host" statements to match clients and either assign them to a particular static name via "fixed-address", or use "ddns-hostname" to update DNS for the hostname with the dynamic address of the assignment. -- tale ___ Please 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: non-improving referral
On Thu, Jul 8, 2021 at 1:38 AM Mark Andrews wrote: > AA is NOT set so it is not a valid answer to the question. Ahh that was the part that I overlooked. -- tale ___ Please 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: non-improving referral
On Mon, Jul 5, 2021 at 8:20 PM Mark Andrews wrote: > This is an error with the delegation of ok.contact. The NS records at the > delegation point do > not match those at the zone apex. I'm curious if this is a re-purposing of the existing "non-improving referral" message. I totally get how that brief phrase makes sense for a sideways referral, but I'm not seeing how that statement makes sense for ok.contact. # Delegation for .contact $ dig +noall +auth ns contact @a.root-servers.net contact. 172800 IN NS demand.beta.aridns.net.au. contact. 172800 IN NS demand.alpha.aridns.net.au. contact. 172800 IN NS demand.delta.aridns.net.au. contact. 172800 IN NS demand.gamma.aridns.net.au. # Delegation for ok.contact $ dig +noall +auth ns ok.contact @demand.alpha.aridns.net.au. ok.contact. 86400 IN NS fwd2.dccdns.com. ok.contact. 86400 IN NS fwd1.dccdns.com. ok.contact. 86400 IN NS fwd4.dccdns.com. ok.contact. 86400 IN NS fwd3.dccdns.com. # Apex NS for ok.contact $ dig +noall +ans ns ok.contact @fwd1.dccdns.com ok.contact. 3499 IN NS fwd4.dns.ws. ok.contact. 3499 IN NS fwd2.dns.ws. ok.contact. 3499 IN NS fwd1.dns.ws. ok.contact. 3499 IN NS fwd3.dns.ws. Yes, the apex NS names aren't the same as the delegating NS (though the adb addresses are), but that last one isn't a referral. I trust you are right, Mark. I'm just not sure what I'm missing about "non-improving referral". -- tale ___ Please 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: REST API for recursive queries
On Tue, May 4, 2021 at 8:42 AM Roee Mayerowicz wrote: > Do you know of a way to ask multiple DNS queries in a recursive bind server > at the same packet\request? > Using DoH might work? How? Is there a plugin which does that? The short answer is no, but it might not be answering the question you're really trying to ask. In strict terms of what would constitute "the same request", though, no. While you could conceive of a legally-formed DNS packet that had multiple questions in the Question section, a server has no way to acceptably indicate the proper response for all questions. In some cases, it might be obvious -- say, asking for the address of a.example.com and b.example.com, and them both having addresses -- but things quickly get out of hand when you look at the problems of indicating the many other ways that DNS can answer, like NXDOMAIN, NODATA, or delegation. With various forms of DNS TCP connections -- vanilla DNS, DNS over TLS (DoT), DNS over HTTPS (DoH) -- you can put multiple DNS request messages over the same connection. But that's not quite the same as "at the same packet\request". It also can depend on the end points; you might want to shove 1000 requests down a TCP connection, but server policy might limit the number it will actually process before terminating the link. And plugins are specific to a particular software package. Plugin to what? BIND and other major DNS resolvers and authoritative servers support TCP technologies natively. The clients that talk to them are numerous, with varying degrees of support for both TCP initiation and multi-request streaming. -- tale ___ Please 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: Getting "query failed (REFUSED) for ./IN/ANY"
> >Are the queries refused because of the dot (.)? In the query log, I also > > found some 28 IN ANY queries from 7 IPs for xxx.at.fragolina.it, which > > probably got away with a NXDOMAIN. > > no. the dot is just the root domain. Correct that . is the root domain, but I'd say the answer is a qualified yes. If you are not providing open recursive services and are not authoritative for the root domain, BIND will respond with REFUSED just like it would if someone asked you about example.com when you're not authoritative for that. In the old days you'd get a root referral for authoritative resolution, but now you get a minimal REFUSED to signal lack of authority for the question. -- tale ___ Please 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: SRV Record Server Availability
On Tue, Jan 5, 2021 at 4:30 AM Wilfred Sarmiento via bind-users wrote: > Is DNS Bind SRV record can detect the Server's availability? If yes, how? Could you provide more information about your goal? I don't fully understand the question. For my reading, the answer is basically no, in that an SRV record just provides data about where.a particular service can be found. It's up to other systems to fetch that data and interpret it, including whether that service is actually available at the given endpoint. In its typical operation, BIND will just take whatever name and port the zone administrator said to provide for that SRV record, and not do any sort of availability checks on it. However, if you go deep into a far more complicated, custom use of BIND, you could set up a process that monitors the availability and changes the SRV record accordingly. -- tale ___ Please 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: Weird DNS behaviour resolution issues when more labels are present in a zone
On Wed, Dec 16, 2020 at 3:48 AM Prasanna Mathivanan (pmathiva) via
bind-users wrote:
> Whenever we have broken delegation as domain owners didn't follow proper RFC,
> the default behaviour of the query hits " _." which
> doesn’t exist.? And we get NXDOMAIN or SERVFAIL response.
Going back to your original example, a.b.c.example.com, qname
minimisation first identifies that there is a delegation at .com for
example.com, and then asks the example.com namesevers for
_.c.example.com. Typically this _.c.example.com query would come
back with either an NXDOMAIN answer, which means that the queried
nameserver believes it is authoritative for all names within
c.example.com, or it comes back with a NOERROR answer that lists a
delegation in the authority section.
In the first case (NXDOMAIN), the resolver knows it can ask the same
servers about _.b.c.example.com and the cycle repeats. In the latter
case, the resolver is able to distinguish between whether there was a
delegation for c.example.com (and ask the new nameservers about
_.b.c.example.com) or a delegation that's actually at _.c.example.com
(highly unusual, in which case, ask the original example.com
nameservers about _.b.c.example.com).
Getting a SERVFAIL throws a wrench in all this. It's the
authoritative server basically saying, "I'm badly broken and can't
tell you how." Generally this means the resolver should ask the next
server in the authoritative list. If they're all giving SERVFAIL then
the resolver can either try to work around the brokenness (for
example, by querying the full name at its closest enclosing
delegation) or just give up on the SERVFAIL.
--
tale
PS: While thinking about this I realized a weird case, which is if
only a subset of the parent nameservers are authoritative for a
subdomain. That is, imagine example.com is served by the four servers
ns{1,2,34}.example.com, but c.example.com is delegated only to
ns{1,2}.example.com. If you ask ns1 or ns2 about _.c.example.com,
they'll give an authoritative answer and the fact that a delegation
exists wouldn't be identified (absent DNSSEC), but asking ns3 or ns4
would give the delegation to ns1 and ns2. I can't think of how this
might be a real problem for future queries though, outside of the
usual type of brokenness that can happen even with full name queries
(eg, a parent has a subdomain configured that it isn't actually
delegated to it).
___
Please 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: forwarders used in order or based on RTT ?
On Fri, Oct 16, 2020 at 10:22 AM Matus UHLAR - fantomas wrote: >> On 16.10.20 09:56, Bob Harold wrote: > >The BIND ARM (9.16.2) says: > >"There may be one or more forwarders, and they are queried in turn until > >the list is exhausted or an answer is found." > > > >But [an old mailinglist post] says: > >"Forwarders are selected based on an RTT(round-trip-time)-based algorithm" > > > >So which is correct? > > both are. The ARM does not say they are queried in defined order. > The order is defined by RTT To be fair, the ARM strongly implies in its context that it's the order you put them in the list. The ARM discrepancy has already been noted by ISC, but the first bug report in the long long ago on it was never really fixed.They raised the issue again internally a few months ago and so I would anticipate that the ARM will be fixed in a not too distant release. https://gitlab.isc.org/isc-projects/bind9/-/issues/2030 ___ Please 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: Do not cache certain domains
On Mon, Sep 7, 2020 at 6:01 PM Ben Lavender wrote: > Without having to alter the TTL of the existing RRs as well as the > default TTL. I know this can be done using cache-max-ttl to limit the > whole cache, but can this be done for say one single or multiple defined > domains only? AFAIK there's no specially designed way to handle this, so achieving it will basically mean cobbling some parts together. max-cache-ttl is usable in a view statement, and each view by default gets its own cache. With the caveat that this might not be the best way and I haven't actually tested it, I'd try this. Set up a view that bound a listener to an interface alias on your host, and inside that view clamp down max-cache-ttl however you like. Back in your main configuration set up the zone(s) to forward to that private listener. I think even on the first hit, the TTL that your main resolver sees will be the one that got clamped in the view resolver, but I'm not positive about that. You will also get double the number of cache entries for each lookup, of course. ___ Please 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: Reverse lookup response format
> Instead of the way it is now: > # nslookup 192.168.2.206 > 206.2.168.192.in-addr.arpa name = > server1.ctois.local.2.168.192.in-addr.arpa. In your zone file be sure that the name that is the target of the PTR records has a final dot. Without the trailing dot, the names are interpreted as relative to the current origin. ___ Please 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: Error "Query section mismatch : got"
On Wed, Aug 19, 2020 at 7:42 AM Matus UHLAR - fantomas
wrote:
> again, why you query for 250.0-24.199.212.125.in-addr.arpa
> under normal circumstances there's no point of querying that name.
>
Well yes and no. While an individual user would typically not,
resolvers sure will. While trying to resolve
250.199.212.125.in-addr.arpa, it will eventually get to
250.199.212.125.in-addr.arpa CNAME 250.0-24.199.212.125.in-addr.arpa.
Then it will need to resolve the canonical name, and a response like
the original one that was shown will be clearly buggy.
I say "possibly" because from my vantage, all three of
ns{,1,2}.viettelidc.com.vn, the authorities for
0-24.199.212.125.in-addr.arpa, are giving fine answers right now (on
udp; blocked on tcp). This includes the originally reported problem
IP, 115.84.177.8
--
tale
___
Please 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: /etc/bind.keys in a chrooted environment
On Wed, Jul 22, 2020 at 11:05 AM Anand Buddhdev wrote: > There is no harm in copying the file into the chroot. It will get rid of > the warning. With the caveat that you have to be sure that if you keep the original copy outside of the chroot, you have to be sure updates get reflected inside the chroot. NAMED_CONF_INCLUDE_FILES mentioned in the OP seems to be a SuSE-ism and I didn't dig into whatever bearing it might have for maintenance of the chroot. -- tale ___ Please 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: Debian/Ubuntu: Why was the service renamed from bind9 to named?
On Sun, Jul 19, 2020 at 7:06 AM @lbutlr wrote: > On 17 Jul 2020, at 11:56, Ted Mittelstaedt wrote: > > In fact, the ONLY reason that the name "bind9" was ever even coined > > at all was because the changes from bind8 both in the syntax of the > > config file and how the program operated they wanted to boot admins > > in the behind to get them to change their config files. > > This. Exactly this. Well, one minor bit of clarification is important. While highlighting the significant change in software might have been the motivation for why some installers chose to go with the name bind9 in place of named in some contexts, it was also a major design goal of BIND9 that it could run as a drop-in replacement for BIND8 on most configurations. It achieved this goal. The basic syntax was unchanged and configuration behavior was largely the same but for a little bit around the edges. And for what it's worth, not all systems moved away from "named" to "bind9". I've been running FreeBSD for decades, and I can't remember ever calling the service "bind9". ___ Please 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
