Re: [Non-DoD Source] BIND Masters and slaves

[bind-lists]

I have been teaching informal DNS classes at work for decades, and I used to be 
very careful to use “master” and “slave” and would include a section where I 
pointed out that using “primary” and “secondary” instead was not correct. Then 
about 10 years ago one person in class pointed out to me that for some people 
when they hear that terminology it really bothers them because of what slavery 
means. When she said that a few other people nodded and agreed. I hadn’t 
thought about that aspect of it, and so someone had to explain to me how 
jarring and distracting from the subject matter that could be for some people. 
I’ve used “primary” and “secondary” in all my classes and documentation since 
then. Not because of twitter and social media or because I have an image to 
uphold, but in order to be considerate of other people’s feelings and not 
dismiss them because they’re so different from mine.

I would like to see the terms replaced by something that doesn’t hearken back 
to tragedy and torture.

Maria

> On Jun 15, 2020, at 2:15 PM, Michael De Roover  wrote:
> 
> Of course I could, but I do not feel like the effort to change nomenclature 
> is either beneficial or worth taking for granted the requests of some people 
> on Twitter - as the slave to peer authority I am - given how much it affects 
> documentation, code, comments, general environment of the projects 
> themselves. I enjoy being surrounded by people much smarter than I am when it 
> comes to the mailing list here. Let's keep it that way and not derange 
> ourselves into meaningless blabber from social media.
> 
> What I did notice over time however that most of the projects affected are 
> also those who do have to maintain a good public image, usually corporations. 
> Meanwhile projects such as Opal  and 
> recently Rubocop  as well 
> were not. The latter one I'd like to draw attention to. The maintainer 
> clearly didn't ask for this and asked everyone who shamed him, why are you 
> doing this? None of the complainers were affiliated to the project at all. 
> Chances are that they weren't even using it and just searched for projects 
> with the name "cop" in it instead. These are not the people I want to support 
> in my effort to end racism, which I do support, and quite heavily so.
> 
> On 6/15/20 8:00 PM, DeCaro, James John (Jim) CIV DISA FE (USA) wrote:
>> Or you can call the slave servers 'secondary' servers.  
> -- 
> Met vriendelijke groet / Best regards,
> Michael De Roover

___
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: Can we provide recursion for forward zones in response to iterative queries?

[bind-lists]

Thanks. I have opened a ticket with AWS support asking them to allow us to pull 
slave copies of our VPC-internal zones. If they don’t do that, then making the 
zones slaves will not fix our problem, because the AWS endpoints refuse to 
answer iterative queries.

Thanks,
Maria

> On Apr 7, 2020, at 4:09 PM, Mark Andrews  wrote:
> 
> Add delegations if they are missing. This is how DNS is designed to be 
> managed.
> 
> This should have been done as  part of allocating the address  space  
> initially.
> -- 
> Mark Andrews
> 
>> On 8 Apr 2020, at 02:43, bind-li...@iano.org wrote:
>> 
>> Currently our linux caching resolvers have a forwarding rule for 
>> 10.in-addr.arpa back to a small subset of our approximately 200 AD domain 
>> controllers. We made it a stub zone at one point in the past, but ran into 
>> intermittent resolution problems, although I don’t recall the details. We’ve 
>> never tried making it a slave zone as you recommend. If it would be better 
>> to change that to a slave zone then we want to do that, but there is a 
>> concern. Not all subdomains are delegated under 10.in-addr.arpa over on the 
>> AD side, and it is used as a catch-all for those that aren’t. Hundreds of 
>> thousands of desktops, laptops, devices and servers are constantly renewing 
>> and updating their IP addresses, and that domain is constantly changing. 
>> This would lead to our caching resolvers constantly pulling zone transfers 
>> from the AD servers. What would you recommend we do on the linux side to 
>> mitigate that, and is it still best to make it a slave zone in that case? We 
>> can make recommendations for changes on the AD side, but changes there take 
>> longer and are more complex to put in place. It’s easier if we can work 
>> around it on the linux side.
>> 
>> Thanks!
>> Maria
>> 
>>> On Apr 6, 2020, at 8:30 PM, Mark Andrews  wrote:
>>> 
>>> As 10.in-addr.arpa is private namespace *all* of you recursive servers 
>>> should be configured to serve it.  This is similar to how all of your 
>>> recursive nameservers know where the root servers are except you are using 
>>> a slave zone instead of a hint zone.
>>> 
>>> i.e.
>>> 
>>> 10.in-addr.arpa {
>>>   type slave;
>>>   masters { ; };
>>>   file “slave/10.in-addr.arpa”;// adjust to match your local conventions.
>>>   request-ixfr no; // only use AXFR for 10.in-addr.arpa as it is 
>>> coming from AD as IXFR does not work well.
>>>   forwarders { /* empty */ };  // use iterative resolution for the children 
>>> of 10.in-addr.arpa.
>>> };
>>> 
>>> Forwarding should NEVER be needed if servers are reachable at the IP level. 
>>>  If the solution says “configure a forward zone” it is almost always wrong.
>>> 
>>> Do the similar for the top of all other private namespaces you are using.
>>> 
>>> Mark
>>> 
> On 4 Apr 2020, at 03:06, bind-li...@iano.org wrote:
 
 Hi,
 
 In summary, my question is whether there is a way to configure a bind 
 caching server to provide recursion in response to iterative queries for 
 records in a forward type zone.
 
 The background is that we have:
 
 - AD domain controllers that are authoritative for all of 10.in-addr.arpa. 
 in our data centers - most clients point to these for DNS resolution.
 - Linux bind caching resolvers in our data centers - domain controllers 
 forward to these for anything they don’t own.
 - Some AWS VPCs which have been allocated subdomains of 10.in-addr.arpa. 
 and are routable from our data centers. These have Route53 inbound 
 endpoints which answer queries for those subdomains.
 - The bind caching resolvers have forwarding rules for those subdomains to 
 the AWS inbound endpoints.
 
 The subdomains in our AWS VPCs have NS records, but the servers those 
 point to refuse queries for records in the subdomains. The zone resolution 
 is taken care of by the Route53 resolver service. The Route53 inbound 
 endpoints successfully resolve queries from our data centers for those 
 subdomains as long as the recursion desired flag is set to 1 in the query. 
 If recursion desired is set to 0 they do not send any reply at all.
 
 We want to be able to resolve PTR records in the subdomains in the AWS 
 VPCs from our data centers where, as I said above, the clients point to 
 the domain controllers for DNS resolution.
 
 Because the AD domain controllers already own 10.in-addr.arpa, they refuse 
 to allow us to configure conditional forwarding for its subdomains. So we 
 delegated the subdomains to the inbound endpoints. Because they are 
 delegations, the domain controllers set the recursion desired flag to 0 on 
 the queries they send to the endpoints, and we are not getting replies 
 from the endpoints.
 
 As a workaround we tried delegating to our linux bind caching resolvers 
 but we ran into the same issue, that the domain controllers set 

Re: Can we provide recursion for forward zones in response to iterative queries?

[bind-lists]

I had been told they tried that twice and in both cases the domain controller 
would not let them add the conditional forwarder. On the strength of your 
having said it worked in your situation, they tried again and now it is working.

Thank you!
Maria

> On Apr 6, 2020, at 11:37 AM, Chris Buxton  wrote:
> 
> On Apr 3, 2020, at 9:06 AM, bind-li...@iano.org wrote:
>> Because the AD domain controllers already own 10.in-addr.arpa, they refuse 
>> to allow us to configure conditional forwarding for its subdomains. So we 
>> delegated the subdomains to the inbound endpoints. Because they are 
>> delegations, the domain controllers set the recursion desired flag to 0 on 
>> the queries they send to the endpoints, and we are not getting replies from 
>> the endpoints.
>> 
>> As a workaround we tried delegating to our linux bind caching resolvers but 
>> we ran into the same issue, that the domain controllers set recursion 
>> desired to 0. As a result, when our linux caching servers have the result in 
>> cache, the lookup is successful, but when it would require a fresh lookup it 
>> gets a reply with no answers. Hence my question, is there a way to tell our 
>> bind caching resolvers to ignore the recursion desired flag and provide 
>> recursion anyway?
> 
> I've solved this before. You've tried two solutions, and neither worked 
> alone. You need to do both.
> 
> - Delegate the subzones in question to the forwarders (or anywhere, really).
> - Add conditional forwarding for the subzones also, pointing to the 
> forwarders.
> 
> Without the delegation, the conditional forwarding won't work -- the MS DNS 
> servers will respond authoritatively. But without the conditional forwarding, 
> the MS DNS servers will send iterative queries, not recursive queries.
> 
> Regards,
> Chris Buxton

___
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: Can we provide recursion for forward zones in response to iterative queries?

[bind-lists]

Currently our linux caching resolvers have a forwarding rule for 
10.in-addr.arpa back to a small subset of our approximately 200 AD domain 
controllers. We made it a stub zone at one point in the past, but ran into 
intermittent resolution problems, although I don’t recall the details. We’ve 
never tried making it a slave zone as you recommend. If it would be better to 
change that to a slave zone then we want to do that, but there is a concern. 
Not all subdomains are delegated under 10.in-addr.arpa over on the AD side, and 
it is used as a catch-all for those that aren’t. Hundreds of thousands of 
desktops, laptops, devices and servers are constantly renewing and updating 
their IP addresses, and that domain is constantly changing. This would lead to 
our caching resolvers constantly pulling zone transfers from the AD servers. 
What would you recommend we do on the linux side to mitigate that, and is it 
still best to make it a slave zone in that case? We can make recommendations 
for changes on the AD side, but changes there take longer and are more complex 
to put in place. It’s easier if we can work around it on the linux side.

Thanks!
Maria

> On Apr 6, 2020, at 8:30 PM, Mark Andrews  wrote:
> 
> As 10.in-addr.arpa is private namespace *all* of you recursive servers should 
> be configured to serve it.  This is similar to how all of your recursive 
> nameservers know where the root servers are except you are using a slave zone 
> instead of a hint zone.
> 
> i.e.
> 
> 10.in-addr.arpa {
>   type slave;
>   masters { ; };
>   file “slave/10.in-addr.arpa”;// adjust to match your local conventions.
>   request-ixfr no; // only use AXFR for 10.in-addr.arpa as it 
> is coming from AD as IXFR does not work well.
>   forwarders { /* empty */ };  // use iterative resolution for the 
> children of 10.in-addr.arpa.
> };
> 
> Forwarding should NEVER be needed if servers are reachable at the IP level.  
> If the solution says “configure a forward zone” it is almost always wrong.
> 
> Do the similar for the top of all other private namespaces you are using.
> 
> Mark
> 
>> On 4 Apr 2020, at 03:06, bind-li...@iano.org wrote:
>> 
>> Hi,
>> 
>> In summary, my question is whether there is a way to configure a bind 
>> caching server to provide recursion in response to iterative queries for 
>> records in a forward type zone.
>> 
>> The background is that we have:
>> 
>> - AD domain controllers that are authoritative for all of 10.in-addr.arpa. 
>> in our data centers - most clients point to these for DNS resolution.
>> - Linux bind caching resolvers in our data centers - domain controllers 
>> forward to these for anything they don’t own.
>> - Some AWS VPCs which have been allocated subdomains of 10.in-addr.arpa. and 
>> are routable from our data centers. These have Route53 inbound endpoints 
>> which answer queries for those subdomains.
>> - The bind caching resolvers have forwarding rules for those subdomains to 
>> the AWS inbound endpoints.
>> 
>> The subdomains in our AWS VPCs have NS records, but the servers those point 
>> to refuse queries for records in the subdomains. The zone resolution is 
>> taken care of by the Route53 resolver service. The Route53 inbound endpoints 
>> successfully resolve queries from our data centers for those subdomains as 
>> long as the recursion desired flag is set to 1 in the query. If recursion 
>> desired is set to 0 they do not send any reply at all.
>> 
>> We want to be able to resolve PTR records in the subdomains in the AWS VPCs 
>> from our data centers where, as I said above, the clients point to the 
>> domain controllers for DNS resolution.
>> 
>> Because the AD domain controllers already own 10.in-addr.arpa, they refuse 
>> to allow us to configure conditional forwarding for its subdomains. So we 
>> delegated the subdomains to the inbound endpoints. Because they are 
>> delegations, the domain controllers set the recursion desired flag to 0 on 
>> the queries they send to the endpoints, and we are not getting replies from 
>> the endpoints.
>> 
>> As a workaround we tried delegating to our linux bind caching resolvers but 
>> we ran into the same issue, that the domain controllers set recursion 
>> desired to 0. As a result, when our linux caching servers have the result in 
>> cache, the lookup is successful, but when it would require a fresh lookup it 
>> gets a reply with no answers. Hence my question, is there a way to tell our 
>> bind caching resolvers to ignore the recursion desired flag and provide 
>> recursion anyway?
>> 
>> Thanks,
>> Maria
>> ___
>> 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
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  

Can we provide recursion for forward zones in response to iterative queries?

[bind-lists]

Hi,

In summary, my question is whether there is a way to configure a bind caching 
server to provide recursion in response to iterative queries for records in a 
forward type zone.

The background is that we have:

- AD domain controllers that are authoritative for all of 10.in-addr.arpa. in 
our data centers - most clients point to these for DNS resolution.
- Linux bind caching resolvers in our data centers - domain controllers forward 
to these for anything they don’t own.
- Some AWS VPCs which have been allocated subdomains of 10.in-addr.arpa. and 
are routable from our data centers. These have Route53 inbound endpoints which 
answer queries for those subdomains.
- The bind caching resolvers have forwarding rules for those subdomains to the 
AWS inbound endpoints.

The subdomains in our AWS VPCs have NS records, but the servers those point to 
refuse queries for records in the subdomains. The zone resolution is taken care 
of by the Route53 resolver service. The Route53 inbound endpoints successfully 
resolve queries from our data centers for those subdomains as long as the 
recursion desired flag is set to 1 in the query. If recursion desired is set to 
0 they do not send any reply at all.

We want to be able to resolve PTR records in the subdomains in the AWS VPCs 
from our data centers where, as I said above, the clients point to the domain 
controllers for DNS resolution.

Because the AD domain controllers already own 10.in-addr.arpa, they refuse to 
allow us to configure conditional forwarding for its subdomains. So we 
delegated the subdomains to the inbound endpoints. Because they are 
delegations, the domain controllers set the recursion desired flag to 0 on the 
queries they send to the endpoints, and we are not getting replies from the 
endpoints.

As a workaround we tried delegating to our linux bind caching resolvers but we 
ran into the same issue, that the domain controllers set recursion desired to 
0. As a result, when our linux caching servers have the result in cache, the 
lookup is successful, but when it would require a fresh lookup it gets a reply 
with no answers. Hence my question, is there a way to tell our bind caching 
resolvers to ignore the recursion desired flag and provide recursion anyway?

Thanks,
Maria
___
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: one domain not resolving via response-policy zone

[lists]

Hey Kai,

> If I do a nslookup for one of the otto.de domains I reveive "** server
> can't find somehost.ov.otto.de: SERVFAIL"

The guideline behind the response-policy is that only an actual response gets 
rewritten.
This is usually an answer from a recursive lookup.
If you don't get an answer, there is nothing to rewrite.

The SERVFAIL won't be rewritten unless you told BIND to do so.

You could try the 'qname-wait-recurse' option.
I guess this isn't the original purpose of this option, but based on the 
documentation this should
work for you.

>From https://ftp.isc.org/isc/bind9/cur/9.11/doc/arm/Bv9ARM.ch06.html
> Using this option can cause error responses such as SERVFAIL
> to appear to be rewritten, since no recursion is being done to
> discover problems at the authoritative server.

Cheers
Felix

On 22.01.2018 13:58, Kai Wiechers wrote:

> Hi List,
> I setup a response-policy zone to override some Records from external
> DNS-Servers I can't control.
> My db.rpz Zonefile:
> $TTL 4H
> @ IN SOA localhost. kai.mydomain.com. (
> 2018012212 ; serial
> 5M ; refresh
> 5M ; retry
> 4W ; expiry
> 5M) ; minimum
> IN NS localhost.
> localhost A 127.0.0.1
> ulf.test.google.de A 192.168.0.1
> gerd.test.google.de A 192.168.0.2
> bild.de A 192.168.0.3
> somehost.ov.otto.de A 10.0.0.1
> otherhost.ov.otto.de A 10.0.0.2
> heise.de A 192.168.0.4
> In my options I just added
> response-policy { zone "rpz"; };
> What really drives me crazy is, that the override of the google and
> heise domain is working. But the otto.de domains not.
> If I do a nslookup for one of the otto.de domains I reveive "** server
> can't find somehost.ov.otto.de: SERVFAIL"
> Any hints for me?
> Thanks and best regards,
> Kai
> ___
> 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: stumped on sub domain addition

[lists - euca]

Jeff / John, thanks.

It appears it was a sticky cache or something, as it finally is working now. :-/

Thanks for the help.

Donovan



On Jul 23, 2015, at 1:33 PM, Lightner, Jeff jlight...@dsservices.com wrote:

 Your A record is working on a dig +trace and also working when I do dig 
 @ns10.euca.us and dig @ns11.euca.us.
 
 This suggests the record (or nxrecord) is cached somewhere for normal lookups 
 and will likely be OK after that cache expires.
 
 Record returned:
 onqsolutions.euca.us.   21600   IN  A   209.236.238.19
 
 In your SOA you have (in addition to the rest of the record):
 2015072342  ; Serial 
 That suggests you updated the record today (07/23) and it automatically 
 updated serial number when you did it.
 
 Jeffrey C. Lightner
 Sr. UNIX/Linux Administrator
  
 DS Services of America, Inc.
 2300 Windy Ridge Pkwy
 Suite 600 N
 Atlanta, GA  30339-8461
  
 P: 678-486-3516
 C: 678-772-0018
 F: 678-460-3603
 E: jlight...@dsservices.com
 
 
 -Original Message-
 From: lists - euca [mailto:li...@euca.us] 
 Sent: Thursday, July 23, 2015 2:23 PM
 To: Lightner, Jeff
 Cc: Bind Users Mailing List
 Subject: Re: stumped on sub domain addition
 
 Thanks for the responses.
 
 
 On Jul 23, 2015, at 12:37 PM, Lightner, Jeff jlight...@dsservices.com wrote:
 
 Did you change the sequence/serial in the SOA and reload the zone?
 
 
 No, I am using 'smbind' to administer bind, and it appears to not let me do 
 that. I don't know if it does an 'auto reload' or not, but I've never had a 
 problem with the 500+ domains that are on it as of yet, so I'm guessing it 
 does.
 
 
 
 Doing dig tests for euca.us I get it's A record and for www.euca.us I get 
 is CNAME.  
 
 That suggests you didn't setup onqsolutions record properly.   Looking at 
 your www CNAME in your zone file might let you know how to setup the one for 
 onqsolutions.   Don't forget to put the dot at end of CNAME record like you 
 see for WWW.
 
 Jeffrey C. Lightner
 
 [snip]
 
 From: bind-users-boun...@lists.isc.org 
 [mailto:bind-users-boun...@lists.isc.org] On Behalf OfJohn Miller
 Sent: Thursday, July 23, 2015 1:17 PM
 Cc: Bind Users Mailing List
 Subject: Re: stumped on sub domain addition
 
 Hi Donovan,
 
 Your zone file(s) as well as your named.conf config would be best here.  We 
 really need more information from you than a single fqdn.
 
 
 
 Here is the file that smbind created  (note that I have been making some 
 changes):
 $TTL   21600
 @   IN  SOA ns10.euca.us. hostmaster.euca.us. (
2015072342  ; Serial
10800   ; Refresh
7200; Retry
604800  ; Expire
21600)  ; Negative Cache TTL
 ;
 @   IN  NSns10.euca.us.
 @   IN  NSns11.euca.us.
 @   IN  A   209.236.238.19
 @   IN  MX  10  mail.euca.us.
 design  IN  CNAME   @
 dev IN  CNAME   @
 elatia  IN  A   209.236.238.19
 ftp IN  A   209.236.238.19
 mailIN  A   209.236.238.18
 mail2   IN  A   209.236.238.18
 ns10IN  A   209.236.238.21
 ns11IN  A   209.236.238.22
 onqsolutionsIN  A   209.236.238.19
 www IN  CNAME   @
 www-tek IN  CNAME   @
 
 
 
 John
 --
 John Miller

___
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

stumped on sub domain addition

[lists - euca]

Hello, 
I added a sub domain to my zone file euca.us yesterday. 

“onqsolutions”.

It first was added as a CNAME, then I couldn’t get it to work.. so now it is an 
A record. 
Still not working.

Can someone help troubleshoot?

onqsolutions.euca.us

TIA,
Donovan


___
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: MS AD 2008R2 and bind

[Will Lists]

On Tue, Jan 3, 2012 at 4:00 AM, Melbinger Christian 
christian.melbin...@wienit.at wrote:

 Hi

 ** **

 My company moved to a 2008R2 Domain Controller environment. Now I see the
 following message in the windows log:

 ** **

 *Title*: This domain controller must register its correct IP addresses
 with the DNS server

 *Severity*: Error

 *Category*: Configuration

 *Issue*: The Domain Name System (DNS) host resource records for this
 domain controller's fully qualified domain name currently map to the IP
 addresses that do not belong to this domain controller. The invalid IP
 addresses are 10.1.1.1; 10.2.2.2.

 *Impact*: Other member computers and domain controllers in the domain or
 forest might not be able to locate this domain controller. This domain
 controller will not be able to provide a full suite of services.

 *Resolution*: Ensure that the DNS Client service on this domain
 controller is configured and able to register valid host resource records
 with an authoritative DNS server for the domain.

 More information about this best practice and detailed resolution
 procedures: http://go.microsoft.com/fwlink/?LinkId=131229

 ** **

 ** **

 All Domain Controllers have zone updates rights on the master dns server,
 and according to the logfile updating zones works.

 My DNS-Servers are running BIND 9.7.3-P3.

 ** **

 ** **

 ** **

 So this is presumably not a problem of the bind servers themselves, but
 still, does anyone have an idea how to get rid of the error messages?

 Anyone know the checkbox to unset? I didn’t find one…

 ** **

 With regards

 Christian Melbinger

 ** **

 ** **

 ---

 Ing. Christian Melbinger

 Netzwerk  Security

 ** **

 WienIT EDV Dienstleistungsgesellschaft mbH  Co KG

 A-1030 Wien, Thomas-Klestil-Platz 6

 tel: +43 (1) 90405 47188

 fax: +43 (1) 90405 88 47188

 mailto:christian.melbin...@wienit.at

 ** **

 
 WienIT EDV Dienstleistungsgesellschaft mbH  Co KG, A-1030 Wien,
 Thomas-Klestil-Platz 6,
 FN 255974h, Handelsgericht Wien, DVR: 2109667, UID-Nr. ATU61260824
 Persönlich haftender Gesellschafter:
 WienIT EDV Dienstleistungsgesellschaft mbH, A-1030 Wien,
 Thomas-Klestil-Platz 6,
 FN 255649f, Handelsgericht Wien, UID-Nr. ATU61296118

 ___
 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




-- 

I'm just going to throw out a few ideas, not sure any or all of them will
get you in the right direction...but I  had significant issues with DCs and
dynamic updates following a migration from AD integrated DNS to BIND.


What A records map to those IP addresses listed (10.1.1.1, 10.2.2.2)?

Are there any same as zone records that point to your DC IPs?  (this is
common if  DNS is AD integrated)

Do you see in the Event Viewer on the DC that it
is successfully registering the A, PTR and SRV records?  (not sure what log
this is in, been a little while since I looked last).

I know you said it was the case, but your BIND config has one of the
following options set?
 - allow-update { address_match_list }; -- If the DC is pointing to the
master BIND server
 - allow-update-forwarding { address_match_list }; -- if the DC is
pointing to the slave BIND server

What happens if you issue the ipconfig /registerdns command from the DCs?


- Will
___
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: Not able to resolve a domain

[Will Lists]

Maybe a network/firewall issue?  My results below.


dig +trace thisisgame.com

;  DiG 9.8.0-P2  +trace thisisgame.com
;; global options: +cmd
.   432154  IN  NS  b.root-servers.net.
.   432154  IN  NS  l.root-servers.net.
.   432154  IN  NS  h.root-servers.net.
.   432154  IN  NS  f.root-servers.net.
.   432154  IN  NS  m.root-servers.net.
.   432154  IN  NS  i.root-servers.net.
.   432154  IN  NS  d.root-servers.net.
.   432154  IN  NS  k.root-servers.net.
.   432154  IN  NS  j.root-servers.net.
.   432154  IN  NS  g.root-servers.net.
.   432154  IN  NS  a.root-servers.net.
.   432154  IN  NS  e.root-servers.net.
.   432154  IN  NS  c.root-servers.net.
;; Received 512 bytes from 10.1.6.203#53(10.1.6.203) in 0 ms

com.172800  IN  NS  a.gtld-servers.net.
com.172800  IN  NS  b.gtld-servers.net.
com.172800  IN  NS  c.gtld-servers.net.
com.172800  IN  NS  d.gtld-servers.net.
com.172800  IN  NS  e.gtld-servers.net.
com.172800  IN  NS  f.gtld-servers.net.
com.172800  IN  NS  g.gtld-servers.net.
com.172800  IN  NS  h.gtld-servers.net.
com.172800  IN  NS  i.gtld-servers.net.
com.172800  IN  NS  j.gtld-servers.net.
com.172800  IN  NS  k.gtld-servers.net.
com.172800  IN  NS  l.gtld-servers.net.
com.172800  IN  NS  m.gtld-servers.net.
;; Received 492 bytes from 199.7.83.42#53(l.root-servers.net) in 200 ms

thisisgame.com. 172800  IN  NS  ns1.thisisgame.com.
;; Received 66 bytes from 192.35.51.30#53(f.gtld-servers.net) in 60 ms


- Will




On Fri, Nov 18, 2011 at 9:23 AM, King, Harold Clyde (Hal) h...@utk.eduwrote:

   This is the trace I get trying to resolve the domain.

  dig +trace thisisgame.com

  ;  DiG 9.8.1-P1  +trace thisisgame.com
 ;; global options: +cmd
 .   456080  IN  NS  d.root-servers.net.
 .   456080  IN  NS  h.root-servers.net.
 .   456080  IN  NS  l.root-servers.net.
 .   456080  IN  NS  f.root-servers.net.
 .   456080  IN  NS  e.root-servers.net.
 .   456080  IN  NS  b.root-servers.net.
 .   456080  IN  NS  i.root-servers.net.
 .   456080  IN  NS  m.root-servers.net.
 .   456080  IN  NS  j.root-servers.net.
 .   456080  IN  NS  k.root-servers.net.
 .   456080  IN  NS  a.root-servers.net.
 .   456080  IN  NS  c.root-servers.net.
 .   456080  IN  NS  g.root-servers.net.
 ;; Received 512 bytes from 127.0.0.1#53(127.0.0.1) in 364 ms

  com.172800  IN  NS  f.gtld-servers.net.
 com.172800  IN  NS  d.gtld-servers.net.
 com.172800  IN  NS  c.gtld-servers.net.
 com.172800  IN  NS  j.gtld-servers.net.
 com.172800  IN  NS  k.gtld-servers.net.
 com.172800  IN  NS  e.gtld-servers.net.
 com.172800  IN  NS  i.gtld-servers.net.
 com.172800  IN  NS  m.gtld-servers.net.
 com.172800  IN  NS  g.gtld-servers.net.
 com.172800  IN  NS  h.gtld-servers.net.
 com.172800  IN  NS  a.gtld-servers.net.
 com.172800  IN  NS  l.gtld-servers.net.
 com.172800  IN  NS  b.gtld-servers.net.
 ;; Received 504 bytes from 192.33.4.12#53(192.33.4.12) in 496 ms

  thisisgame.com. 172800  IN  NS  ns1.thisisgame.com.
 dig: couldn't get address for 'ns1.thisisgame.com': not found

  --
 Hal King  - h...@utk.edu
 Systems Administrator
 Office of Information Technology
 Systems: Business Information Systems

 The University of Tennessee
 135D Kingston Pike Building
 2309 Kingston Pk. Knoxville, TN 37996
 Phone: 974-1599

   From: Hal King h...@utk.edu
 Date: Fri, 18 Nov 2011 15:19:18 +
 To: Bind Users bind-users@lists.isc.org
 Subject: Not able to resolve a domain

I have found that www.thisisgame.com does not resolve on our DNS
 servers. Google DNS works fine. According to 

Re: Not able to resolve a domain

[Will Lists]

Oops, left off the most important part:


thisisgame.com. 1800IN  A   1.234.35.120
thisisgame.com. 1800IN  NS  ns1.thisisgame.com.
;; Received 82 bytes from 1.234.35.141#53(ns1.thisisgame.com) in 187 ms


Full results:

;  DiG 9.8.0-P2  +trace thisisgame.com
;; global options: +cmd
.   431870  IN  NS  d.root-servers.net.
.   431870  IN  NS  h.root-servers.net.
.   431870  IN  NS  e.root-servers.net.
.   431870  IN  NS  g.root-servers.net.
.   431870  IN  NS  f.root-servers.net.
.   431870  IN  NS  a.root-servers.net.
.   431870  IN  NS  k.root-servers.net.
.   431870  IN  NS  c.root-servers.net.
.   431870  IN  NS  m.root-servers.net.
.   431870  IN  NS  j.root-servers.net.
.   431870  IN  NS  l.root-servers.net.
.   431870  IN  NS  b.root-servers.net.
.   431870  IN  NS  i.root-servers.net.
;; Received 512 bytes from 127.0.0.1#53(10.1.6.203) in 0 ms

com.172800  IN  NS  c.gtld-servers.net.
com.172800  IN  NS  b.gtld-servers.net.
com.172800  IN  NS  a.gtld-servers.net.
com.172800  IN  NS  j.gtld-servers.net.
com.172800  IN  NS  k.gtld-servers.net.
com.172800  IN  NS  l.gtld-servers.net.
com.172800  IN  NS  e.gtld-servers.net.
com.172800  IN  NS  f.gtld-servers.net.
com.172800  IN  NS  h.gtld-servers.net.
com.172800  IN  NS  g.gtld-servers.net.
com.172800  IN  NS  d.gtld-servers.net.
com.172800  IN  NS  i.gtld-servers.net.
com.172800  IN  NS  m.gtld-servers.net.
;; Received 492 bytes from 192.228.79.201#53(b.root-servers.net) in 78 ms

thisisgame.com. 172800  IN  NS  ns1.thisisgame.com.
;; Received 66 bytes from 192.41.162.30#53(l.gtld-servers.net) in 38 ms

thisisgame.com. 1800IN  A   1.234.35.120
thisisgame.com. 1800IN  NS  ns1.thisisgame.com.
;; Received 82 bytes from 1.234.35.141#53(ns1.thisisgame.com) in 187 ms




-Will

On Fri, Nov 18, 2011 at 9:27 AM, Will Lists listsw...@gmail.com wrote:

 Maybe a network/firewall issue?  My results below.


 dig +trace thisisgame.com

 ;  DiG 9.8.0-P2  +trace thisisgame.com
 ;; global options: +cmd
 .   432154  IN  NS  b.root-servers.net.
 .   432154  IN  NS  l.root-servers.net.
 .   432154  IN  NS  h.root-servers.net.
 .   432154  IN  NS  f.root-servers.net.
 .   432154  IN  NS  m.root-servers.net.
 .   432154  IN  NS  i.root-servers.net.
 .   432154  IN  NS  d.root-servers.net.
 .   432154  IN  NS  k.root-servers.net.
 .   432154  IN  NS  j.root-servers.net.
 .   432154  IN  NS  g.root-servers.net.
 .   432154  IN  NS  a.root-servers.net.
 .   432154  IN  NS  e.root-servers.net.
 .   432154  IN  NS  c.root-servers.net.
 ;; Received 512 bytes from 127.0.0.1#53(10.1.6.203) in 0 ms

 com.172800  IN  NS  a.gtld-servers.net.
 com.172800  IN  NS  b.gtld-servers.net.
 com.172800  IN  NS  c.gtld-servers.net.
 com.172800  IN  NS  d.gtld-servers.net.
 com.172800  IN  NS  e.gtld-servers.net.
 com.172800  IN  NS  f.gtld-servers.net.
 com.172800  IN  NS  g.gtld-servers.net.
 com.172800  IN  NS  h.gtld-servers.net.
 com.172800  IN  NS  i.gtld-servers.net.
 com.172800  IN  NS  j.gtld-servers.net.
 com.172800  IN  NS  k.gtld-servers.net.
 com.172800  IN  NS  l.gtld-servers.net.
 com.172800  IN  NS  m.gtld-servers.net.
 ;; Received 492 bytes from 199.7.83.42#53(l.root-servers.net) in 200 ms

 thisisgame.com. 172800  IN  NS  ns1.thisisgame.com.
 ;; Received 66 bytes from 192.35.51.30#53(f.gtld-servers.net) in 60 ms


 - Will




 On Fri, Nov 18, 2011 at 9:23 AM, King, Harold Clyde (Hal) h...@utk.eduwrote:

   This is the trace I get trying

Re: Not able to resolve a domain

[Will Lists]

Site is based in Korea based on the IP and whois, so it does sound like
some sort of access controls are in place on one end or the other.  I was
able to access the site.


-Will

On Fri, Nov 18, 2011 at 9:30 AM, Jan-Piet Mens jpmens@gmail.com wrote:

  I have found that www.thisisgame.com does not resolve on our DNS servers

 You haven't done anything wrong. thisisgame.com has a single name
 server, and that is currently not open to business, at least not from
 my part of the world, maybe due to some firewall rule. (Google's NS do
 indeed have access.)

-JP
 ___
 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

Switching from forwarding to recursion

[Will Lists]

We recently tried a test to see how our internal servers would react to a
loss of their external peers, with the goal being that the internal servers
would switch from forwarding to doing recursive queries for clients.
 Normally, the internal servers forward to the external servers.  To
simulate the loss of the external servers, we pushed a new firewall rule
that blocked port 53 to the external servers from the internal servers.
 That did seem to cause the internal servers to start using the root
servers in a recursive manner.

We did see that some recursive queries were answered, eventually, though
usually much, much slower than if the request had been forwarded as normal
to the external servers.  We saw traffic (lots of traffic) going across the
firewall to the roots as well as multiple domain specific name servers, so
that flow path is working as best as I can tell.  All servers are running
BIND 9.7.4.

The issue we saw was that the queries would time out more often than not
and on the off chance they did get an answer back to the requesting client,
it was very slow after several retries.

Am I missing something in the named.conf file?  Is there something specific
I should be looking for in the syslog or daemon.log?


The relevant portion of the named.conf file for the INTERNAL view is below:


forwarders { NS2; NS1; };
forward first;
allow-recursion { 10.0.0.0/8; 192.168.0.0/16; 172.16.0.0/12; };
recursion yes;

// zone: . [hint]
include ...;


The hints DB file is current as of the version of BIND in use (2011060800).


Thanks.

-Will
___
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: Switching from forwarding to recursion

[Will Lists]

Ben,

I seem to recall reading at some point in the past that after X amount of
time, BIND would stop trying to contact servers it figured to be dead (at
least it would stop trying for some amount of time).  Is that in fact the
case and would it eventually come into play here?  Any configurable options
here, if this behavior does exist?

It almost seems like the best way to handle this scenario, in the event of
a real failure of one or more external servers that typically act as
forwarders, would be to quickly modify the configuration internally to just
stop forwarding.  Thoughts?

Thanks.


-Will


On Tue, Nov 1, 2011 at 8:54 AM, Ben Croswell ben.crosw...@gmail.com wrote:

 If you have a global forwarder in place there are two options that affect
 its use. Forward first, the default, and forward only.
 Forward first will exhaust the forwarders you have and then attempt to
 follow NS records. Forward only will only use forwarders.

 The delay you are seeing is likely the delay in exhausting the forwarders
 before attempting the roots.

 -Ben Croswell
 On Nov 1, 2011 9:23 AM, Will Lists listsw...@gmail.com wrote:

 We recently tried a test to see how our internal servers would react to a
 loss of their external peers, with the goal being that the internal servers
 would switch from forwarding to doing recursive queries for clients.
  Normally, the internal servers forward to the external servers.  To
 simulate the loss of the external servers, we pushed a new firewall rule
 that blocked port 53 to the external servers from the internal servers.
  That did seem to cause the internal servers to start using the root
 servers in a recursive manner.

 We did see that some recursive queries were answered, eventually, though
 usually much, much slower than if the request had been forwarded as normal
 to the external servers.  We saw traffic (lots of traffic) going across the
 firewall to the roots as well as multiple domain specific name servers, so
 that flow path is working as best as I can tell.  All servers are running
 BIND 9.7.4.

 The issue we saw was that the queries would time out more often than not
 and on the off chance they did get an answer back to the requesting client,
 it was very slow after several retries.

 Am I missing something in the named.conf file?  Is there something
 specific I should be looking for in the syslog or daemon.log?


 The relevant portion of the named.conf file for the INTERNAL view is
 below:


 forwarders { NS2; NS1; };
 forward first;
 allow-recursion { 10.0.0.0/8; 192.168.0.0/16; 172.16.0.0/12; };
 recursion yes;

 // zone: . [hint]
 include ...;


 The hints DB file is current as of the version of BIND in use
 (2011060800).


 Thanks.

 -Will

 ___
 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: Switching from forwarding to recursion

[Will Lists]

I did get a chance to dig through the syslogs finally on one of the
internal name servers and I'm seeing a lot of these three entries for
various domains.  I would have to assume that one or all of these items
would also contribute to the lengthy times to resolve queries?


named[16593]: error (network unreachable) resolving '
a1294.w20.akamai.net/A/IN': 2001:428:1802:3f0:8719:deda:1eed:ea4#53

-- This would be due to our network (internal or external) not supporting
IPv6 I would assume.  I see that you can use the -4 flag when starting
named to force IPv4 only, but I'm not sure if/how you could actually force
this configuration via the named.conf file itself.


named[16593]: success resolving 'ns2.gslb.com/' (in 'gslb.com'?) after
reducing the advertised EDNS UDP packet size to 512 octets

-- Firewall configuration in regards to packet sizes?


named[16593]: success resolving 'ns2.gslb.com/A' (in 'gslb.com'?) after
disabling EDNS

-- ?


Thanks

-Will



On Tue, Nov 1, 2011 at 9:13 AM, Ben Croswell ben.crosw...@gmail.com wrote:

 If a given forwarder is bad  it get its round trip time, rtt, set high
 and will not be used until that comes back down via the normal rtt decay
 mechanism in BIND. I have not tested the behaviour when all are down. My
 assumption would be that if all are down they will all have to be tried
 before going to NS or there is no way of knowing when the forwarders are
 back.

 In your case if you have a limited number of servers a quick removal of
 the forwarders may be the quickest way to restore service.

 -Ben Croswell
 On Nov 1, 2011 10:03 AM, Will Lists listsw...@gmail.com wrote:

 Ben,

 I seem to recall reading at some point in the past that after X amount of
 time, BIND would stop trying to contact servers it figured to be dead (at
 least it would stop trying for some amount of time).  Is that in fact the
 case and would it eventually come into play here?  Any configurable options
 here, if this behavior does exist?

 It almost seems like the best way to handle this scenario, in the event
 of a real failure of one or more external servers that typically act as
 forwarders, would be to quickly modify the configuration internally to just
 stop forwarding.  Thoughts?

 Thanks.


 -Will


 On Tue, Nov 1, 2011 at 8:54 AM, Ben Croswell ben.crosw...@gmail.comwrote:

 If you have a global forwarder in place there are two options that
 affect its use. Forward first, the default, and forward only.
 Forward first will exhaust the forwarders you have and then attempt to
 follow NS records. Forward only will only use forwarders.

 The delay you are seeing is likely the delay in exhausting the
 forwarders before attempting the roots.

 -Ben Croswell
 On Nov 1, 2011 9:23 AM, Will Lists listsw...@gmail.com wrote:

 We recently tried a test to see how our internal servers would react to
 a loss of their external peers, with the goal being that the internal
 servers would switch from forwarding to doing recursive queries for
 clients.  Normally, the internal servers forward to the external servers.
  To simulate the loss of the external servers, we pushed a new firewall
 rule that blocked port 53 to the external servers from the internal
 servers.  That did seem to cause the internal servers to start using the
 root servers in a recursive manner.

 We did see that some recursive queries were answered, eventually,
 though usually much, much slower than if the request had been forwarded as
 normal to the external servers.  We saw traffic (lots of traffic) going
 across the firewall to the roots as well as multiple domain specific name
 servers, so that flow path is working as best as I can tell.  All servers
 are running BIND 9.7.4.

 The issue we saw was that the queries would time out more often than
 not and on the off chance they did get an answer back to the requesting
 client, it was very slow after several retries.

 Am I missing something in the named.conf file?  Is there something
 specific I should be looking for in the syslog or daemon.log?


 The relevant portion of the named.conf file for the INTERNAL view is
 below:


 forwarders { NS2; NS1; };
 forward first;
 allow-recursion { 10.0.0.0/8; 192.168.0.0/16; 172.16.0.0/12; };
 recursion yes;

 // zone: . [hint]
 include ...;


 The hints DB file is current as of the version of BIND in use
 (2011060800).


 Thanks.

 -Will

 ___
 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


___
Please visit https://lists.isc.org/mailman

RE: BIND master , Windows 2008 stub zone not transferring

[Will lists]

I had a very similar issue recently, but it was with secondaries on Windows
Server 2008 R2 and not stub zones.  We actually went to stub zones
afterwards to prevent the issue from happening again, hopefully.



The issue was that a machine had done DCHP and gotten the DDNS created
A/TXT/PTR records, but had registered some invalid Unicode characters in its
host name, including spaces so the host record was garbage.  Windows didn't
know what to do and stopped transferring all zones, BIND just chugged along
blissfully unaware.  I had to use nsupdate on the BIND side to remove the
bad record and get the host renamed.  After that, Windows still would not
transfer any zones (not even the zones that were not impacted by the bad
records) until ALL zones were deleted and recreated on each Windows DNS
server.  I was able to find the offending record by using the zone transfer
function in Windows nslookup and fortunately the bad characters made the
record easy to spot in the list.



I don't know that this scenario would cause your situation, but it was close
so I thought it might be of some help.



-Will





-Original Message-
From: bind-users-bounces+listswill=gmail@lists.isc.org
[mailto:bind-users-bounces+listswill=gmail@lists.isc.org] On Behalf Of
Gregory Machin
Sent: Wednesday, October 19, 2011 11:48 PM
To: bind-us...@isc.org
Subject: BIND master , Windows 2008 stub zone not transferring



Hi

We have a Linux server running bind 9.2.4 and dhcpd in a ddns configuration.
We also have a number of windows 2008 R2 servers running AD / DNS / dhcp on
other sites. These windows servers have stub zones configured, for the zones
on the Linux server.



All worked fine up until yesterday.



Now none of the zones will transfer to the stub zones on the Windows
servers. From the windows servers I can use nslookup to do zone transfers
with out any issues. But in DNS mangers , on the stub zone , when I click
one reload, or Transfer from Master, or Transfer new copy from zone Master
then result is the same Zone Not Loaded by DNS server  there is nothing in
the bind logs that relate to this server or the zone transfer request. As
far a I can see there are no firewall issues or connectivity issues.



Any suggestions ?



G

___

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: File System Choice

[Andy Shellam (Mailing Lists)]

On 26 November2009, at 07:00, Fajar A. Nugraha wrote:

 
 Also, you could organize the zone files (manually) so that they spread
 over many directories instead of one.


I've heard that compiling the zones first (named-compilezone?) is a big help in 
this situation; I can't vouch for it though.

Andy
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Trouble configuring forwarders for reverse zones.

[M-lists]

Thanks Chris.

I had actually tried that, but it turned out Windows wasn't answering
reverse queries properly so I didn't notice when I had got it right.  Once
your post pointed out that was the way to go, I got Wireshark on it and
quickly noticed Windows was also at fault.

One further thing, I'll be moving things around on our network soon, and
this means we'll have a classless subnet soon.  So if we moved one of our
Windows subnets to 10.1.1.0/24, how would I forward reverse queries for this
subnet to say 10.1.1.1?

Thanks.


C.


-Original Message-
From: Chris Buxton [mailto:cbux...@menandmice.com] 
Sent: 07 April 2009 17:15
To: Callum Millard
Cc: bind-users@lists.isc.org
Subject: Re: Trouble configuring forwarders for reverse zones.

On Apr 7, 2009, at 8:37 AM, Callum Millard wrote:
 //I've tried a variety of versions of this next line:
 //zone 16/0.0.5.10.in-addr.arpa.
 //zone 5.10.in-addr.arpa.
 //zone 0.0.5.10.in-addr.arpa.
 //Etc., etc.
 zone 16/0.0.5.10.in-addr.arpa. IN {

type forward;
   forwarders {10.5.0.1;};
 };

 zone 16/0.0.6.10.in-addr.arpa. IN {

type forward;
   forwarders {10.6.0.1;};
 };

Close, but no cigar. Here is the correct syntax:

zone 5.10.in-addr.arpa. IN {

type forward;
forwarders {10.5.0.1;};
};

zone 6.10.in-addr.arpa. IN {

type forward;
forwarders {10.6.0.1;};
};

Chris Buxton
Professional Services
Men  Mice


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users