Bind unable to get MX reocrd from Parrent name server
Hi Occasionally we see customer is complainning that we are not able to resolve mx record when mxtoolbox or other website can resolve their mx record . If i do a trace on the domain, i get bellow . now the problem is : demeter.is.co.za. and babylon.mitsol.co.za does not know anything about MX record of that domain. but if i query by using parent name server ns1.yithosting.co.za. and ns2.yithosting.co.za , it returns the mx record . but mxtoolbox, introdns can resolve the mx record although they complain the same that The following nameservers are listed at your nameservers as nameservers for your domain, but are not listed at the parent nameservers (see RFC2181 5.4.1). You need to make sure that these nameservers are working.If they are not working ok, you may have problems! demeter.is.co.za babylon.mitsol.co.za ERROR: One or more of the nameservers listed at the parent servers are not listed as NS records at your nameservers. The problem NS records are: ns1.yithosting.co.za ns2.yithosting.co.za This is listed as an ERROR because there are some cases where nasty problems can occur (if the TTLs vary from the NS records at the root servers and the NS records point to your own domain, for example). then why our bind is unable to resolve mx record ??? Thanks for the help [root@za-ns-8 ~]# dig rbcaa.co.za +trace ; DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 rbcaa.co.za +trace ;; global options: +cmd . 447499 IN NS a.root-servers.net. . 447499 IN NS j.root-servers.net. . 447499 IN NS l.root-servers.net. . 447499 IN NS d.root-servers.net. . 447499 IN NS k.root-servers.net. . 447499 IN NS g.root-servers.net. . 447499 IN NS i.root-servers.net. . 447499 IN NS h.root-servers.net. . 447499 IN NS m.root-servers.net. . 447499 IN NS c.root-servers.net. . 447499 IN NS f.root-servers.net. . 447499 IN NS e.root-servers.net. . 447499 IN NS b.root-servers.net. ;; Received 508 bytes from 10.33.91.35#53(10.33.91.35) in 14 ms za. 172800 IN NS za1.dnsnode.net. za. 172800 IN NS disa.tenet.ac.za. za. 172800 IN NS nsza.is.co.za. za. 172800 IN NS za-ns.anycast.pch.net. za. 172800 IN NS sns-pb.isc.org. ;; Received 360 bytes from 199.7.83.42#53(199.7.83.42) in 346 ms co.za. 86400 IN NS ns0.plig.net. co.za. 86400 IN NS ns.coza.net.za. co.za. 86400 IN NS ns0.neotel.co.za. co.za. 86400 IN NS ns1.coza.net.za. co.za. 86400 IN NS coza1.dnsnode.net. co.za. 86400 IN NS ns0.is.co.za. co.za. 86400 IN NS ns4.iafrica.com. ;; Received 266 bytes from 196.4.160.27#53(196.4.160.27) in 285 ms rbcaa.co.za. 86400 IN NS ns1.yithosting.co.za. rbcaa.co.za. 86400 IN NS ns2.yithosting.co.za. ;; Received 108 bytes from 196.4.160.17#53(196.4.160.17) in 81 ms rbcaa.co.za. 14400 IN A 41.203.1.156 rbcaa.co.za. 86400 IN NS demeter.is.co.za. rbcaa.co.za. 86400 IN NS babylon.mitsol.co.za. ;; Received 99 bytes from 41.203.1.158#53(41.203.1.158) in 41 ms ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind unable to get MX reocrd from Parrent name server
Your glue is broken. You need to update the glue NS records in the parent to reflect the actual nameservers that are authoritative for the zone. It also looks like you could have some data mismatch between zones hosted on (ns1.yithosting.co.za + ns2.yithosting.co.za) and (demeter.is.co.za + babylon.mitsol.co.za). Check that the zone data is consistent across the nameservers. Steve On 5 July 2013 12:35, Fosiul Alam fos...@gmail.com wrote: Hi Occasionally we see customer is complainning that we are not able to resolve mx record when mxtoolbox or other website can resolve their mx record . If i do a trace on the domain, i get bellow . now the problem is : demeter.is.co.za. and babylon.mitsol.co.za does not know anything about MX record of that domain. but if i query by using parent name server ns1.yithosting.co.za. and ns2.yithosting.co.za , it returns the mx record . but mxtoolbox, introdns can resolve the mx record although they complain the same that The following nameservers are listed at your nameservers as nameservers for your domain, but are not listed at the parent nameservers (see RFC2181 5.4.1). You need to make sure that these nameservers are working.If they are not working ok, you may have problems! demeter.is.co.za babylon.mitsol.co.za ERROR: One or more of the nameservers listed at the parent servers are not listed as NS records at your nameservers. The problem NS records are: ns1.yithosting.co.za ns2.yithosting.co.za This is listed as an ERROR because there are some cases where nasty problems can occur (if the TTLs vary from the NS records at the root servers and the NS records point to your own domain, for example). then why our bind is unable to resolve mx record ??? Thanks for the help [root@za-ns-8 ~]# dig rbcaa.co.za +trace ; DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 rbcaa.co.za +trace ;; global options: +cmd . 447499 IN NS a.root-servers.net. . 447499 IN NS j.root-servers.net. . 447499 IN NS l.root-servers.net. . 447499 IN NS d.root-servers.net. . 447499 IN NS k.root-servers.net. . 447499 IN NS g.root-servers.net. . 447499 IN NS i.root-servers.net. . 447499 IN NS h.root-servers.net. . 447499 IN NS m.root-servers.net. . 447499 IN NS c.root-servers.net. . 447499 IN NS f.root-servers.net. . 447499 IN NS e.root-servers.net. . 447499 IN NS b.root-servers.net. ;; Received 508 bytes from 10.33.91.35#53(10.33.91.35) in 14 ms za. 172800 IN NS za1.dnsnode.net. za. 172800 IN NS disa.tenet.ac.za. za. 172800 IN NS nsza.is.co.za. za. 172800 IN NS za-ns.anycast.pch.net. za. 172800 IN NS sns-pb.isc.org. ;; Received 360 bytes from 199.7.83.42#53(199.7.83.42) in 346 ms co.za. 86400 IN NS ns0.plig.net. co.za. 86400 IN NS ns.coza.net.za. co.za. 86400 IN NS ns0.neotel.co.za. co.za. 86400 IN NS ns1.coza.net.za. co.za. 86400 IN NS coza1.dnsnode.net. co.za. 86400 IN NS ns0.is.co.za. co.za. 86400 IN NS ns4.iafrica.com. ;; Received 266 bytes from 196.4.160.27#53(196.4.160.27) in 285 ms rbcaa.co.za. 86400 IN NS ns1.yithosting.co.za. rbcaa.co.za. 86400 IN NS ns2.yithosting.co.za. ;; Received 108 bytes from 196.4.160.17#53(196.4.160.17) in 81 ms rbcaa.co.za. 14400 IN A 41.203.1.156 rbcaa.co.za. 86400 IN NS demeter.is.co.za. rbcaa.co.za. 86400 IN NS babylon.mitsol.co.za. ;; Received 99 bytes from 41.203.1.158#53(41.203.1.158) in 41 ms ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind unable to get MX reocrd from Parrent name server
Hi thanks for reply, I am not the domain admin for rbcaa.co.za I can see they have issue with their domain setup . but what I want to know is : when all Dns server can resolved their mx record example , mxtoolbox,introdns,google .. (Despite they have issue with their dns setup for that domain (as you said) ) then why we cant ?? Thanks for looking into it . On Fri, Jul 5, 2013 at 12:45 PM, Steven Carr sjc...@gmail.com wrote: Your glue is broken. You need to update the glue NS records in the parent to reflect the actual nameservers that are authoritative for the zone. It also looks like you could have some data mismatch between zones hosted on (ns1.yithosting.co.za + ns2.yithosting.co.za) and (demeter.is.co.za + babylon.mitsol.co.za). Check that the zone data is consistent across the nameservers. Steve On 5 July 2013 12:35, Fosiul Alam fos...@gmail.com wrote: Hi Occasionally we see customer is complainning that we are not able to resolve mx record when mxtoolbox or other website can resolve their mx record . If i do a trace on the domain, i get bellow . now the problem is : demeter.is.co.za. and babylon.mitsol.co.za does not know anything about MX record of that domain. but if i query by using parent name server ns1.yithosting.co.za. and ns2.yithosting.co.za , it returns the mx record . but mxtoolbox, introdns can resolve the mx record although they complain the same that The following nameservers are listed at your nameservers as nameservers for your domain, but are not listed at the parent nameservers (see RFC2181 5.4.1). You need to make sure that these nameservers are working.If they are not working ok, you may have problems! demeter.is.co.za babylon.mitsol.co.za ERROR: One or more of the nameservers listed at the parent servers are not listed as NS records at your nameservers. The problem NS records are: ns1.yithosting.co.za ns2.yithosting.co.za This is listed as an ERROR because there are some cases where nasty problems can occur (if the TTLs vary from the NS records at the root servers and the NS records point to your own domain, for example). then why our bind is unable to resolve mx record ??? Thanks for the help [root@za-ns-8 ~]# dig rbcaa.co.za +trace ; DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 rbcaa.co.za +trace ;; global options: +cmd . 447499 IN NS a.root-servers.net. . 447499 IN NS j.root-servers.net. . 447499 IN NS l.root-servers.net. . 447499 IN NS d.root-servers.net. . 447499 IN NS k.root-servers.net. . 447499 IN NS g.root-servers.net. . 447499 IN NS i.root-servers.net. . 447499 IN NS h.root-servers.net. . 447499 IN NS m.root-servers.net. . 447499 IN NS c.root-servers.net. . 447499 IN NS f.root-servers.net. . 447499 IN NS e.root-servers.net. . 447499 IN NS b.root-servers.net. ;; Received 508 bytes from 10.33.91.35#53(10.33.91.35) in 14 ms za. 172800 IN NS za1.dnsnode.net. za. 172800 IN NS disa.tenet.ac.za. za. 172800 IN NS nsza.is.co.za. za. 172800 IN NS za-ns.anycast.pch.net. za. 172800 IN NS sns-pb.isc.org. ;; Received 360 bytes from 199.7.83.42#53(199.7.83.42) in 346 ms co.za. 86400 IN NS ns0.plig.net. co.za. 86400 IN NS ns.coza.net.za. co.za. 86400 IN NS ns0.neotel.co.za. co.za. 86400 IN NS ns1.coza.net.za. co.za. 86400 IN NS coza1.dnsnode.net. co.za. 86400 IN NS ns0.is.co.za. co.za. 86400 IN NS ns4.iafrica.com. ;; Received 266 bytes from 196.4.160.27#53(196.4.160.27) in 285 ms rbcaa.co.za. 86400 IN NS ns1.yithosting.co.za. rbcaa.co.za. 86400 IN NS ns2.yithosting.co.za. ;; Received 108 bytes from 196.4.160.17#53(196.4.160.17) in 81 ms rbcaa.co.za. 14400 IN A 41.203.1.156 rbcaa.co.za. 86400 IN NS demeter.is.co.za. rbcaa.co.za. 86400 IN NS babylon.mitsol.co.za. ;; Received 99 bytes from 41.203.1.158#53(41.203.1.158) in 41 ms ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Regards Fosiul Alam 07877100621 http://www.fosiul.co.uk ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind unable to get MX reocrd from Parrent name server
On 05.07.13 12:59, Fosiul Alam wrote: I am not the domain admin for rbcaa.co.za I can see they have issue with their domain setup . but what I want to know is : when all Dns server can resolved their mx record example , mxtoolbox,introdns,google .. (Despite they have issue with their dns setup for that domain (as you said) ) then why we cant ?? because some kinds of DNS problems, especially this one (incosistent NS between parent zone delegation and the zone itself) often lead to this kind of issues. In your example, the NS servers in the zone rbcaa.co.za refuse queries for the zone, so any server that caches the NS records will fail as long. The reason why services like mxtoolbox work is that they apparently do not behave as standard (rfc-conforming) DNS clients, they trace those domains to catch those issues. For example: http://www.intodns.com/rbcaa.co.za clearly says there are ERRORS in the domain. I really do not think that this should be interpreted as they can resolve. Other DNS checker also says: No name servers found at child. Not enough nameserver information was found to test the zone rbcaa.co.za, but an IP address lookup succeeded in spite of that. http://dnscheck.iis.se/?time=1373027394id=3521288view=basictest=standard rbcaa.co.za. 86400 IN NS ns1.yithosting.co.za. rbcaa.co.za. 86400 IN NS ns2.yithosting.co.za. ;; Received 108 bytes from 196.4.160.17#53(196.4.160.17) in 81 ms rbcaa.co.za. 14400 IN A 41.203.1.156 rbcaa.co.za. 86400 IN NS demeter.is.co.za. rbcaa.co.za. 86400 IN NS babylon.mitsol.co.za. ;; Received 99 bytes from 41.203.1.158#53(41.203.1.158) in 41 ms % dig any rbcaa.co.za. @babylon.mitsol.co.za. ; DiG 9.8.4-rpz2+rl005.12-P1 any rbcaa.co.za. ; @babylon.mitsol.co.za. ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: REFUSED, id: 40276 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available % dig +norec any rbcaa.co.za. @babylon.mitsol.co.za. ; DiG 9.8.4-rpz2+rl005.12-P1 +norec any rbcaa.co.za. ; @babylon.mitsol.co.za. ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: REFUSED, id: 52980 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 -- 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. Save the whales. Collect the whole set. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind unable to get MX reocrd from Parrent name server
The other DNS server software is working around or ignoring the issues. Server software varies in how much it ignores or works around bad domain setups. Also, in some situations, configuration problems result in symptoms that come and go. One reason DNS software is picky about correct setups is security: ignoring some configuration issues increases the chance of passing along bad, possibly malicious answers. Bind is apparently pickier than some other DNS server software. I have to believe some public resolvers have considerable extra logic to try to partially validate and use domains that are incorrectly set up. The ideal way to fix the issue is to get the owner of the domain to fix it. John Cornell University IT On Jul 5, 2013, at 7:59 AM, Fosiul Alam wrote: Hi thanks for reply, I am not the domain admin for rbcaa.co.za I can see they have issue with their domain setup . but what I want to know is : when all Dns server can resolved their mx record example , mxtoolbox,introdns,google .. (Despite they have issue with their dns setup for that domain (as you said) ) then why we cant ?? Thanks for looking into it . On Fri, Jul 5, 2013 at 12:45 PM, Steven Carr sjc...@gmail.com wrote: Your glue is broken. You need to update the glue NS records in the parent to reflect the actual nameservers that are authoritative for the zone. It also looks like you could have some data mismatch between zones hosted on (ns1.yithosting.co.za + ns2.yithosting.co.za) and (demeter.is.co.za + babylon.mitsol.co.za). Check that the zone data is consistent across the nameservers. Steve On 5 July 2013 12:35, Fosiul Alam fos...@gmail.com wrote: Hi Occasionally we see customer is complainning that we are not able to resolve mx record when mxtoolbox or other website can resolve their mx record . If i do a trace on the domain, i get bellow . now the problem is : demeter.is.co.za. and babylon.mitsol.co.za does not know anything about MX record of that domain. but if i query by using parent name server ns1.yithosting.co.za. and ns2.yithosting.co.za , it returns the mx record . but mxtoolbox, introdns can resolve the mx record although they complain the same that The following nameservers are listed at your nameservers as nameservers for your domain, but are not listed at the parent nameservers (see RFC2181 5.4.1). You need to make sure that these nameservers are working.If they are not working ok, you may have problems! demeter.is.co.za babylon.mitsol.co.za ERROR: One or more of the nameservers listed at the parent servers are not listed as NS records at your nameservers. The problem NS records are: ns1.yithosting.co.za ns2.yithosting.co.za This is listed as an ERROR because there are some cases where nasty problems can occur (if the TTLs vary from the NS records at the root servers and the NS records point to your own domain, for example). then why our bind is unable to resolve mx record ??? Thanks for the help [root@za-ns-8 ~]# dig rbcaa.co.za +trace ; DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 rbcaa.co.za +trace ;; global options: +cmd . 447499 IN NS a.root-servers.net. . 447499 IN NS j.root-servers.net. . 447499 IN NS l.root-servers.net. . 447499 IN NS d.root-servers.net. . 447499 IN NS k.root-servers.net. . 447499 IN NS g.root-servers.net. . 447499 IN NS i.root-servers.net. . 447499 IN NS h.root-servers.net. . 447499 IN NS m.root-servers.net. . 447499 IN NS c.root-servers.net. . 447499 IN NS f.root-servers.net. . 447499 IN NS e.root-servers.net. . 447499 IN NS b.root-servers.net. ;; Received 508 bytes from 10.33.91.35#53(10.33.91.35) in 14 ms za. 172800 IN NS za1.dnsnode.net. za. 172800 IN NS disa.tenet.ac.za. za. 172800 IN NS nsza.is.co.za. za. 172800 IN NS za-ns.anycast.pch.net. za. 172800 IN NS sns-pb.isc.org. ;; Received 360 bytes from 199.7.83.42#53(199.7.83.42) in 346 ms co.za. 86400 IN NS ns0.plig.net. co.za. 86400 IN NS ns.coza.net.za. co.za. 86400 IN NS ns0.neotel.co.za. co.za. 86400 IN NS ns1.coza.net.za. co.za. 86400 IN NS coza1.dnsnode.net. co.za. 86400 IN NS ns0.is.co.za. co.za. 86400 IN NS ns4.iafrica.com. ;; Received 266 bytes from 196.4.160.27#53(196.4.160.27) in 285 ms rbcaa.co.za. 86400 IN NS ns1.yithosting.co.za. rbcaa.co.za. 86400 IN NS ns2.yithosting.co.za. ;; Received 108 bytes from 196.4.160.17#53(196.4.160.17) in 81 ms rbcaa.co.za. 14400 IN A 41.203.1.156 rbcaa.co.za. 86400 IN NS demeter.is.co.za. rbcaa.co.za. 86400 IN NS babylon.mitsol.co.za. ;; Received 99 bytes from 41.203.1.158#53(41.203.1.158) in 41 ms ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Regards Fosiul Alam 07877100621 http://www.fosiul.co.uk ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users
Re: How to suppress ADDITIONAL SECTION per zone
Other possibility is to implement packet rate limiting - a patch was discussed here a few days/weeks ago. I endorse this suggestion: we were faced with such attacks and were naturally leery about issues we might run into running a patched bind and the additional tuning it could require. Our experience is: the RRL patch, used with its default parameters, simply does the job. John Cornell University IT ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How to suppress ADDITIONAL SECTION per zone
From: John Wobus jw...@cornell.edu Other possibility is to implement packet rate limiting - a patch was discussed here a few days/weeks ago. I endorse this suggestion: we were faced with such attacks and were naturally leery about issues we might run into running a patched bind and the additional tuning it could require. Our experience is: the RRL patch, used with its default parameters, simply does the job. (thanks for the good new.) See http://www.redbarn.org/dns/ratelimits Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Reverse address entries
On Jun 28, 2013, at 3:54 PM, Ward, Mike S wrote: I want to thank everyone for their input. It sounds like they do need the reverse address entries in specific circumstances so I’m going to recommend that they add them. Lack of reverse records made a big difference in the distant past. Now, I suspect the percentage of situations is much reduced, but of course the sheer number of users/uses of the Internet is higher. I have a suspicion that the deployment of IPV6 will kill off using reverse lookups for validation. Of course DNS supports IPV6 reverse records, but IPV6 poses challenges for some DNS strategies, e.g. setting up static placeholder DNS records for each address in a dynamically-addressed subnet. John Cornell University IT ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RRL and avoiding contributing to DDoS (Was: How to suppress ADDITIONAL SECTION per zone)
On 2013-07-05 07:21, John Wobus wrote: I endorse this suggestion: we were faced with such attacks and were naturally leery about issues we might run into running a patched bind and the additional tuning it could require. Our experience is: the RRL patch, used with its default parameters, simply does the job. I haven't been following the RRL discussions too closely, is this patch scheduled to be included in BIND9 proper or will it remain a patch? We generally prefer to avoid unsupported (third party) patches, although I am working on getting an exception through for this particular situation, but if it's scheduled for inclusion in the nearish future, we may wait. In the mean time, would it make sense to set minimal-responses yes proactively, or only if a spike of activity is detected (noting that it will take us 1-3 days to notice a spike unless it's disruptive to performance) -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RRL and avoiding contributing to DDoS (Was: How to suppress ADDITIONAL SECTION per zone)
From: Dave Warren da...@hireahit.com I haven't been following the RRL discussions too closely, is this patch scheduled to be included in BIND9 proper or will it remain a patch? } From: Evan Hunt each at isc.org } It's not built into bind (yet). } } Correct. For the record, it'll be in 9.10.0 by default and 9.9.4 as a } compile-time option (--enable-rrl). https://lists.isc.org/pipermail/bind-users/2013-June/090872.html In the mean time, would it make sense to set minimal-responses yes proactively, or only if a spike of activity is detected (noting that it will take us 1-3 days to notice a spike unless it's disruptive to performance) Depending on your DNS data, a minimal response offers bad guys between significant and more than enough amplification for a DNS reflection attack. While a minimal-responses yes without RRL DNS server is participating in a DNS reflection attack, it can be sending a lot of bits/second. Some DNS servers are not bothered by few extra Gbit/sec of DNS output bandwidth, but many are In other words, as I see them, as DNS reflection mitigation, minimal-responses yes is like blocking ANY, just wishful thinking. Vernon Schryverv...@rhyolite.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
