is NS record pointing to some other name server needed in case of classless IN-ADDR.ARPA delegations?
Hi, in case of classless IN-ADDR.ARPA delegations(http://www.ietf.org/rfc/rfc2317.txt) I have usually seen at least one NS record pointing to name server other than the end-customer ones. Example from rfc2317.txt where there are two NS records and the second one is not the end-customer name server: ; 0-127 /25 0/25NS ns.A.domain. 0/25NS some.other.name.server. ; 1 CNAME 1.0/25.2.0.192.in-addr.arpa. 2 CNAME 2.0/25.2.0.192.in-addr.arpa. 3 CNAME 3.0/25.2.0.192.in-addr.arpa. ; Another example from one real name server zone file: ; 0 IN NS ns.content-providerA.com. 0 IN NS ns2.content-providerA.com. 0 IN NS ns.isp-of-content-providerA.net. ; 1 IN CNAME 1.0.47.168.192.in-addr.arpa. 2 IN CNAME 2.0.47.168.192.in-addr.arpa. 3 IN CNAME 3.0.47.168.192.in-addr.arpa. ; Is NS record pointing to some other name server needed in case of classless IN-ADDR.ARPA delegations? What happens if one does not specify this? regards, Martin ___ 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: is NS record pointing to some other name server needed in case of classless IN-ADDR.ARPA delegations?
If a zone is being made available to the public (which these are) then steps should be taken to ensure it is resolvable all the time. This means having multiple servers that are not subject to common failures. This is basic DNS. In message cajx5yve43ctinmw+aeun01paig3kjk8d+4tbhvawyhuiqgn...@mail.gmail.com, Martin T writes: Hi, in case of classless IN-ADDR.ARPA delegations(http://www.ietf.org/rfc/rfc2317.txt) I have usually seen at least one NS record pointing to name server other than the end-customer ones. Example from rfc2317.txt where there are two NS records and the second one is not the end-customer name server: ; 0-127 /25 0/25NS ns.A.domain. 0/25NS some.other.name.server. ; 1 CNAME 1.0/25.2.0.192.in-addr.arpa. 2 CNAME 2.0/25.2.0.192.in-addr.arpa. 3 CNAME 3.0/25.2.0.192.in-addr.arpa. ; Another example from one real name server zone file: ; 0 IN NS ns.content-providerA.com. 0 IN NS ns2.content-providerA.com. 0 IN NS ns.isp-of-content-providerA.net. ; 1 IN CNAME 1.0.47.168.192.in-addr.arpa. 2 IN CNAME 2.0.47.168.192.in-addr.arpa. 3 IN CNAME 3.0.47.168.192.in-addr.arpa. ; Is NS record pointing to some other name server needed in case of classless IN-ADDR.ARPA delegations? What happens if one does not specify this? regards, Martin ___ 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 INTERNET: ma...@isc.org ___ 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: is NS record pointing to some other name server needed in case of classless IN-ADDR.ARPA delegations?
On 04/02/2013 12:47 AM, Martin T wrote: Is NS record pointing to some other name server needed in case of classless IN-ADDR.ARPA delegations? What happens if one does not specify this? It's very common for the parent name server(s) to slave the 2317 zone so that it can answer directly. It's also common for the child to slave the parent zone so that it can answer internal queries directly. And of course as Mark pointed out name servers 1 is basic DNS. You may find this useful as well: https://dougbarton.us/DNS/2317.html Doug ___ 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: Delegations
In article mailman.564.1351726720.11945.bind-us...@lists.isc.org, Mark Andrews ma...@isc.org wrote: In message 5091adef.1040...@dougbarton.us, Doug Barton writes: On 10/31/2012 03:56 PM, Mark Andrews wrote: You are equating a practice that was techically wrong, and known to be wrong from the get go, with one that has never been techically wrong. Yes, I'm making exactly the same judgment that typical users make. It works, so it must be Ok. The fact that we (experts) can get away with something, whether it's technically right/wrong/indifferent not withstanding, doesn't mean that it's good advice for the average user. Doug Putting in delegations where they are not needed introduces additional work and more places that can go wrong. And also (he said very quietly indeed after delurking) increases the granularity of management. Being able to reload or work on a small (sub)zone rather than a large one can have advantages, which of course have to be balanced with the extra effort involved in setting such a system up. YPYMAYTYP. Sam -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ 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: Delegations
YPYMAYTYP Zero results from my favorite search engine -- congratulations. ;-) -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
Re: Delegations
In article mailman.571.1351768172.11945.bind-us...@lists.isc.org, Jan-Piet Mens jpmens@gmail.com wrote: YPYMAYTYP Zero results from my favorite search engine -- congratulations. ;-) Thank you. Try YPYMAYTYC but I was thinking pick. Sam -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ 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: Delegations
On Oct 31, 2012, at 4:02 PM, Doug Barton wrote: On 10/31/2012 03:56 PM, Mark Andrews wrote: You are equating a practice that was techically wrong, and known to be wrong from the get go, with one that has never been techically wrong. Yes, I'm making exactly the same judgment that typical users make. It works, so it must be Ok. The fact that we (experts) can get away with something, whether it's technically right/wrong/indifferent not withstanding, doesn't mean that it's good advice for the average user. I must disagree with my learned colleague here. Introducing the extra subzone for the current subdomain also introduces extra work if DNSSEC is later introduced. It can also cause as many problems as it solves even in the absence of DNSSEC. As for the possibility of administrator error in the future, and making things futureproof, I would assert that stumbling when bad assumptions cause problems is the quickest way to learn the proper rules of DNS. Designing a system to match the possible wrong-headed assumptions of future admins results in a system akin to Microsoft's DNS snap-in for MMC, whereby users then develop mistakes in their thinking about how DNS works and therefore are unable to properly troubleshoot and fix real problems when they occur. I would prefer to promote a correct understanding of the actual rules of DNS. Chris Buxton BlueCat Networks ___ 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
Delegations
I have a zone file for example.org that has entries for a subdomain l2.example.org like this: vpn.l2 IN A10.1.2.3 Now they want to add a subdomain below l2, ie. ad.l2.eboces.org with hosts such as dc.ad.l2.eboces.org In the zone file for example.org, I can add NS and glue records for ad.l2.example.org as this: dc.ad.l2 IN A 10.2.3.4 dr.ad.l2 IN A 10.4.5.6 ad.l2 IN NS dc.ad.l2.example.org. ad.l2 IN NS dr.ad.l2.eboces.org. Will this work, or do I need to delegate l2.example.org before I can delegate ad.l2.example.org? -- William Brown Core Hosted Application Technical Team and Messaging Team Technology Services, WNYRIC, Erie 1 BOCES Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ 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: Delegations
On 31/10/12 17:12, wbr...@e1b.org wrote: I have a zone file for example.org that has entries for a subdomain l2.example.org like this: vpn.l2 IN A10.1.2.3 Now they want to add a subdomain below l2, ie. ad.l2.eboces.org with hosts such as dc.ad.l2.eboces.org You terminology is a bit confusing here. subdomain is imprecise. Specify what *zones* you want, and where you want the delegations, and it should be easy to see what will work and not. example.org SOA www.example.org A - hostname, in example.org zone vpn.l2.example.org A - hostname, still in example.org zone ad.l2.example.org NS - delegation point in example.org zone xx.ad.l2example.org A - glue, *still* in example.org zone ...and of course then the SOA zone contents for ad.l2.example.org In the zone file for example.org, I can add NS and glue records for ad.l2.example.org as this: dc.ad.l2 IN A 10.2.3.4 dr.ad.l2 IN A 10.4.5.6 ad.l2 IN NS dc.ad.l2.example.org. ad.l2 IN NS dr.ad.l2.eboces.org. Will this work, Yes, if I've understood what you want. or do I need to delegate l2.example.org before I can delegate ad.l2.example.org? No. Zone cuts can be at any label inside a zone. ___ 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: Delegations
Phil Mayers p.may...@imperial.ac.uk wrote: No. Zone cuts can be at any label inside a zone. Provided inside does not include the zone apex :-) Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Delegations
Phil wrote on 10/31/2012 02:15:16 PM: You terminology is a bit confusing here. subdomain is imprecise. Sorry, I meant it as a piece of the FQDN. Specify what *zones* you want, and where you want the delegations, and it should be easy to see what will work and not. Yes, if I've understood what you want. I think you got it. or do I need to delegate l2.example.org before I can delegate ad.l2.example.org? No. Zone cuts can be at any label inside a zone. Thanks. Waiting for firewall changes tonight to test. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ 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: Delegations
On 10/31/2012 10:12 AM, wbr...@e1b.org wrote: I have a zone file for example.org that has entries for a subdomain l2.example.org like this: vpn.l2 IN A10.1.2.3 Now they want to add a subdomain below l2, ie. ad.l2.eboces.org with hosts such as dc.ad.l2.eboces.org As someone else pointed out, you're confusing different terms here. If all you want is to add new host names that have l2.eboces.org in them, you can do that without creating a zone cut. OTOH, if what you want to do is create a new zone at ad.l2.eboces.org because you want to delegate it to _different_ name servers than those authoritative for eboces.org, then yes; your safest bet is to do proper zone cuts at each level. It's perfectly Ok to have the name servers for l2.eboces.org be the same as those for eboces.org, just make sure you move any related records (such as your vpn.l2 above) into the new zone file. It may or may not be strictly necessary to do this depending on everything else you have in the zone, but it's safer in the long term to do it this way. hope this helps, Doug In the zone file for example.org, I can add NS and glue records for ad.l2.example.org as this: dc.ad.l2 IN A 10.2.3.4 dr.ad.l2 IN A 10.4.5.6 ad.l2 IN NS dc.ad.l2.example.org. ad.l2 IN NS dr.ad.l2.eboces.org. Will this work, or do I need to delegate l2.example.org before I can delegate ad.l2.example.org? ___ 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: Delegations
On 10/31/2012 06:51 PM, Doug Barton wrote: It may or may not be strictly necessary to do this depending on everything else you have in the zone, but it's safer in the long term to do it this way. Are you suggesting it's best of the OP creates l2.example.com as a sub-zone? Why it this necessary / safer? ___ 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: Delegations
On 10/31/2012 5:15 PM, Phil Mayers wrote: On 10/31/2012 06:51 PM, Doug Barton wrote: It may or may not be strictly necessary to do this depending on everything else you have in the zone, but it's safer in the long term to do it this way. Are you suggesting it's best of the OP creates l2.example.com as a sub-zone? Why it this necessary / safer? I know of at least 2 commerically-available DNS maintenance systems that, by default, do not allow what they call dotted hostnames, by which they mean a name which is at least 2 labels below a zone cut, e.g. foo.bar in the example.com zone. Their underlying assumption seems to be that *every* level of the hierarchy will, in the usual/typical/default case, be delegated. I don't agree with this assumption in the slightest, but some people are afraid of changing default behaviors... - Kevin ___ 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: Delegations
On Oct 31 2012, Phil Mayers wrote: On 10/31/2012 06:51 PM, Doug Barton wrote: It may or may not be strictly necessary to do this depending on everything else you have in the zone, but it's safer in the long term to do it this way. Are you suggesting it's best of the OP creates l2.example.com as a sub-zone? Why it this necessary / safer? It certainly isn't necessary. We have plenty of zone cuts more than one label deep into the parent zone. And of course such delegations are *extremely* common in the reverse lookup trees, with the IPv6 one probably providing records for the number of labels between cuts. I don't see how safer would apply, either. -- Chris Thompson Email: c...@cam.ac.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: Delegations
On Oct 31 2012, Kevin Darcy wrote:
[...snip...]
I know of at least 2 commerically-available DNS maintenance systems
that, by default, do not allow what they call dotted hostnames, by
which they mean a name which is at least 2 labels below a zone cut, e.g.
foo.bar in the example.com zone. Their underlying assumption seems
to be that *every* level of the hierarchy will, in the
usual/typical/default case, be delegated.
I don't agree with this assumption in the slightest, but some people are
afraid of changing default behaviors...
What default behavior? The default behavior of (seriously) defective
DNS maintenance systems? (You wouldn't like to name-and-shame, I suppose?)
The end-point of that sort of logic is that, for example, the SRV record
for _someservice._tcp.somename.example.com has to have separate zones
for somename.example.com and _tcp.somename.example.com, probably
containing nothing but the names mentioned. I've seen people actually
do this, and it's painful to watch.
We were never in that mess as regards the DNS itself, but we did have
an IP registration database that delegated control over names on the basis
of a domain part taken to be all but the first label. It was hard work
to change it to allow the domain part for authorisation purposes to be
any trailing set of labels, but by ${DEITY?} it was necessary!
--
Chris Thompson
Email: c...@cam.ac.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: Delegations
On 10/31/2012 03:22 PM, Chris Thompson wrote: On Oct 31 2012, Kevin Darcy wrote: [...snip...] I know of at least 2 commerically-available DNS maintenance systems that, by default, do not allow what they call dotted hostnames, by which they mean a name which is at least 2 labels below a zone cut, e.g. foo.bar in the example.com zone. Their underlying assumption seems to be that *every* level of the hierarchy will, in the usual/typical/default case, be delegated. I don't agree with this assumption in the slightest, but some people are afraid of changing default behaviors... What default behavior? The default behavior of (seriously) defective DNS maintenance systems? (You wouldn't like to name-and-shame, I suppose?) The end-point of that sort of logic is that, for example, the SRV record for _someservice._tcp.somename.example.com has to have separate zones for somename.example.com and _tcp.somename.example.com, probably containing nothing but the names mentioned. I've seen people actually do this, and it's painful to watch. Chris, I specifically asked the OP if they wanted a zone cut at the higher level, or if they were just looking for multi-dot names. So this particular argumentum ad absurdum is particularly inappropriate. We used to say that you didn't need to do a delegation if the subzone was going to be hosted on the same auth. name server either, and then along came DNSSEC and lots of people with systems that weren't breaking any rules are suddenly dealing with strange error messages. So sure, the OP could probably get away with it even without doing a zone cut at the middle level. But I stand by my assertion that for maximum future-proofing they're safer with it than without. Doing the zone cut costs them almost nothing now, and may save time/effort/energy down the road. Doug ___ 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: Delegations
In message 5091a8bc.70...@dougbarton.us, Doug Barton writes: On 10/31/2012 03:22 PM, Chris Thompson wrote: On Oct 31 2012, Kevin Darcy wrote: [...snip...] I know of at least 2 commerically-available DNS maintenance systems that, by default, do not allow what they call dotted hostnames, by which they mean a name which is at least 2 labels below a zone cut, e.g. foo.bar in the example.com zone. Their underlying assumption seems to be that *every* level of the hierarchy will, in the usual/typical/default case, be delegated. I don't agree with this assumption in the slightest, but some people are afraid of changing default behaviors... What default behavior? The default behavior of (seriously) defective DNS maintenance systems? (You wouldn't like to name-and-shame, I suppose?) The end-point of that sort of logic is that, for example, the SRV record for _someservice._tcp.somename.example.com has to have separate zones for somename.example.com and _tcp.somename.example.com, probably containing nothing but the names mentioned. I've seen people actually do this, and it's painful to watch. Chris, I specifically asked the OP if they wanted a zone cut at the higher level, or if they were just looking for multi-dot names. So this particular argumentum ad absurdum is particularly inappropriate. We used to say that you didn't need to do a delegation if the subzone was going to be hosted on the same auth. name server either, and then along came DNSSEC and lots of people with systems that weren't breaking any rules are suddenly dealing with strange error messages. Adding a child zone without adding the delegating NS records was always a bad idea. Such instruction also usually contained the caveat this is technically wrong and will cause issues if you ever have machines that do not host both zones but you can get away with it. Nameserver also used to merge zone contents so that AXFR included the NS records from the child zone. So sure, the OP could probably get away with it even without doing a zone cut at the middle level. But I stand by my assertion that for maximum future-proofing they're safer with it than without. Doing the zone cut costs them almost nothing now, and may save time/effort/energy down the road. You are equating a practice that was techically wrong, and known to be wrong from the get go, with one that has never been techically wrong. Doug ___ 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 INTERNET: ma...@isc.org ___ 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: Delegations
In message 5091adef.1040...@dougbarton.us, Doug Barton writes: On 10/31/2012 03:56 PM, Mark Andrews wrote: You are equating a practice that was techically wrong, and known to be wrong from the get go, with one that has never been techically wrong. Yes, I'm making exactly the same judgment that typical users make. It works, so it must be Ok. The fact that we (experts) can get away with something, whether it's technically right/wrong/indifferent not withstanding, doesn't mean that it's good advice for the average user. Doug Putting in delegations where they are not needed introduces additional work and more places that can go wrong. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
minimal-responses yes; to prevent downstream MS DNS server following DNS delegations
Greetings
A customer have a security policy based on a zoned network model which
deny DNS servers in the internal network zone to communicate directly
with DNS servers outside the internal network zone. Only exception is
the defined central DNS servers.
In the internal network zone we have internal MS DNS servers which
host the AD DNS zone, and also have a general forwarding to the
internal BIND DNS.
The internal BIND DNS servers host a few zones, and have a general
forwarding (forward only;) to the central BIND DNS servers.
The central BIND DNS servers are allowed to communicate with any DNS server.
My main goal is to prevent the internal MS DNS server from trying to
communicate with DNS servers outside the internal network zone
following delegations. Such communication will be dropped in
firewalls. Instead I want the internal MS DNS server to follow the
generic DNS forwarding configured. In my test-lab I have implemented
the following on the internal BIND DNS with promising results:
...
options {
...
minimal-responses yes;
forward only;
forwarders { central BIND DNS; };
...
};
...
Do you see (or have you experienced) problems with such a configuration?
Regards
Sven Emil
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: minimal-responses yes; to prevent downstream MS DNS server following DNS delegations
In the Windows DNS Manager, open the Properties page of the applicable DNS server. On the Forwarders tab, click Edit and enter the IP address(es) of the BIND server(s) to which you want the Windows DNS server to forward queries. Click OK, and now back on the Forwarders tab, uncheck Use root hints if no forwarders are available. That will constrain the Windows DNS server to using only the BIND servers you have configured. This description is for Windows Server 2008 R2 DNS, but similar functionality is available for other Windows versions. Jeffry A. Spain Network Administrator Cincinnati Country Day School Sent: Tuesday, May 03, 2011 4:16 AM To: bind-users@lists.isc.org Subject: minimal-responses yes; to prevent downstream MS DNS server following DNS delegations My main goal is to prevent the internal MS DNS server from trying to communicate with DNS servers outside the internal network zone following delegations. Such communication will be dropped in firewalls. Instead I want the internal MS DNS server to follow the generic DNS forwarding configured. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Name resolution follows forwarders instead of delegations on master server
Taylor, Gord wrote:
I've noticed that if I have default forwarders setup in the options
section of my named.conf, then BIND (9.4.1-P1) will forward to these
servers rather than following the delegations for zones where it's
authoritative (verified via sniffer trace). Is this true of all BIND
versions?
Yes (at least anything reasonably recent).
In my case, the forwarders in the options section are in my primary data
centre which is authoritative for all of our internal zones, and the
config below exists in one our geographical data centers (overseas),
which is master only a subset of the zones. Since the delegation is to a
local F5 GTM in that same geographical datacenters, I really don't want
everything coming back across the WAN, only to be delegated back across
the WAN again (lots of inefficiencies). I've found that putting an empty
forwarders statement in the zone config (e.g. forwarders { };) prevents
following the default forwarders, so I have a workaround for now.
This isn't a workaround, it's the correct configuration to ensure that
resolution follows the delegation to the subdomain servers instead of
using global forwarding.
This behavior seems a little counter-intuitive to me and never caused me
any problems until recently. So I wanted to know if this behavior was
consistent across all BIND versions, or if it only happened recently due
to our BIND version upgrade last year (9.4.1-P1). I'm looking at another
code upgrade shortly, so want to ensure no surprises...
Any help/clarification is appreciated
You shouldn't get any new surprises relating to forwarding on your next
upgrade :-)
Cathy
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Name resolution follows forwarders instead of delegations on master server
I've found over the years that many people find forwarders { }; to be
non- or even counter-intuitive.
I want to forward, but I'm explicitly telling you not to use any other
server for forwarding. Huh?
My 2 cents is that a different forwarding *mode* (e.g. forward no,
forward none) would make more sense than forwarders { };
- Kevin
On 1/27/2010 6:48 AM, Cathy Almond wrote:
Taylor, Gord wrote:
I've noticed that if I have default forwarders setup in the options
section of my named.conf, then BIND (9.4.1-P1) will forward to these
servers rather than following the delegations for zones where it's
authoritative (verified via sniffer trace). Is this true of all BIND
versions?
Yes (at least anything reasonably recent).
In my case, the forwarders in the options section are in my primary data
centre which is authoritative for all of our internal zones, and the
config below exists in one our geographical data centers (overseas),
which is master only a subset of the zones. Since the delegation is to a
local F5 GTM in that same geographical datacenters, I really don't want
everything coming back across the WAN, only to be delegated back across
the WAN again (lots of inefficiencies). I've found that putting an empty
forwarders statement in the zone config (e.g. forwarders { };) prevents
following the default forwarders, so I have a workaround for now.
This isn't a workaround, it's the correct configuration to ensure that
resolution follows the delegation to the subdomain servers instead of
using global forwarding.
This behavior seems a little counter-intuitive to me and never caused me
any problems until recently. So I wanted to know if this behavior was
consistent across all BIND versions, or if it only happened recently due
to our BIND version upgrade last year (9.4.1-P1). I'm looking at another
code upgrade shortly, so want to ensure no surprises...
Any help/clarification is appreciated
You shouldn't get any new surprises relating to forwarding on your next
upgrade :-)
Cathy
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Name resolution follows forwarders instead of delegations on master server
I've noticed that if I have default forwarders setup in the options
section of my named.conf, then BIND (9.4.1-P1) will forward to these
servers rather than following the delegations for zones where it's
authoritative (verified via sniffer trace). Is this true of all BIND
versions?
In my case, the forwarders in the options section are in my primary data
centre which is authoritative for all of our internal zones, and the
config below exists in one our geographical data centers (overseas),
which is master only a subset of the zones. Since the delegation is to a
local F5 GTM in that same geographical datacenters, I really don't want
everything coming back across the WAN, only to be delegated back across
the WAN again (lots of inefficiencies). I've found that putting an empty
forwarders statement in the zone config (e.g. forwarders { };) prevents
following the default forwarders, so I have a workaround for now.
This behavior seems a little counter-intuitive to me and never caused me
any problems until recently. So I wanted to know if this behavior was
consistent across all BIND versions, or if it only happened recently due
to our BIND version upgrade last year (9.4.1-P1). I'm looking at another
code upgrade shortly, so want to ensure no surprises...
Any help/clarification is appreciated
Here's a simplified config of what I'm running. In this case, queries to
this DNS server (172.16.1.1), will be forwarded to 10.1.1.1 10.2.2.2
first, then if no reply it will try the NS servers for appx listed in
the zone file (delegated to a global load balancer):
NAMED.CONF
~~~
Options {
directory /var/named;
allow-recursion { any; };
allow-query { any; };
allow-query-cache { any; };
forwarders { 10.1.1.1; 10.2.2.2; };
};
Zone internal.corp.sample in {
type master;
file db.internal.corp.sample;
allow-update { none; };
allow-transfer { internal-acl-list; };
};
Db.internal.corp.sample
~~
@ IN SOA ;(...the usual stuff)
IN NS 172.16.1.1
IN NS 172.16.2.2
IN NS 10.1.1.1
IN NS 10.2.2.2
appx IN NS 172.16.3.3
appx IN NS 172.16.4.4
Gord Taylor (CISSP, GCIH, GEEK) | Senior Network Analyst, Internet
Technologies | Royal Bank of Canada
___
This e-mail may be privileged and/or confidential, and the sender does not waive
any related rights and obligations. Any distribution, use or copying of this
e-mail or the information
it contains by other than an intended recipient is unauthorized.
If you received this e-mail in error, please advise me (by return e-mail or
otherwise) immediately.
Ce courriel peut contenir des renseignements protégés et confidentiels.
Lexpéditeur ne renonce pas aux droits et obligations qui sy rapportent.
Toute diffusion, utilisation ou copie de ce courriel ou des renseignements
quil contient
par une personne autre que le destinataire désigné est interdite.
Si vous recevez ce courriel par erreur, veuillez men aviser immédiatement,
par retour de courriel ou par un autre moyen.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: unwanted delegations was: What to do about openDNS
On 21-Jan-2009, at 03:23 , Scott Haneda wrote: On Jan 20, 2009, at 6:42 PM, Matthew Pounsett wrote: Registries that implement host records (so, at least the gTLDs) could accept the word of the registrant of the zone that contains a name server (or the word of their registrar on their behalf) that the server is no longer authoritative for zone X. Registries that haven't implemented host records could also do it, but it may be more complicated to implement, depending on their particular system. This is actually an interesting idea to me. However, the one thing that no one has chimed in on yet, is this seems to me to be an openDNS issue. The current DNS system works pretty well. It actually handles this case rather gracefully, with proper caching there is no real danger. My issue is the relentless pounding openDNS does, and for reasons I am not able to even guess. It does sound like they're doing something at least odd, if not completely wrong. I suspect it's probably related to the way they substitute opcode 3 (nxdomain) with their own answers -- they're probably making absolutely certain that the host doesn't exist, or something. What you describe seems excessive, though. PGP.sig Description: This is a digitally signed message part ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
unwanted delegations was: What to do about openDNS
Scott Haneda wrote: I brought this up a few months back. For me, it is getting worse, and I am not able to come up with a solution. I have many clients who reg domains. They all point to my NS. Sometimes, the client lapses hosting with me, and I delete the zones. They usually leave the domain reg'd and my NS's listed. The system should recognise the rights of nameserver operators. There should be some process by which unwanted delegations can be removed. Obviously doing this on the basis of an email is not a good idea, but perhaps the nameserver operator can publish their desire in a credible fashion: dig @ns1.uq.edu.au 71.155.in-addr.arpa any ~ ; DiG 9.4.2-P2 @ns1.uq.edu.au 71.155.in-addr.arpa any ; (1 server found)9C ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 436 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 3 ;; QUESTION SECTION: ;71.155.in-addr.arpa.INANY ;; ANSWER SECTION: 71.155.in-addr.arpa.3600INSOAnoddns.cc.uq.edu.au. hostmaster.uq.edu.au. 2008121901 10800 1800 360 3600 71.155.in-addr.arpa.259200INNSns1.uq.edu.au. 71.155.in-addr.arpa.259200INNSns2.uq.edu.au. 71.155.in-addr.arpa.259200INNSns3.uq.edu.au. 71.155.in-addr.arpa.3600INTXTzone transfers are allowed to show the zone is useless 71.155.in-addr.arpa.3600INTXTplease remove delegations to the name-servers listed in this zones NS records Danny ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
