Re: Delegation question!
Have you requested delegation? 2010/1/25 Alans > Hello, > > When I check our dns ip from external server for ptr records it shows > nothing but > 93.in-addr.arpa.6562IN SOA ns-pri.ripe.net. > dns-help.ripe.net. 2010012534 3600 7200 1209600 7200 > We bought 93.x.x.0/x from RIPE, does that mean that RIPE didn't delegate > 93.x.x.0/x to us? > > Regards, > Alans > > ___ > 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
RE: Delegation question!
I'm new with this ISP, but I don't think they requested that. Your point is RIPE won't give delegations without request, right? Regards, Alans From: bind-users-bounces+batpower83=yahoo.co...@lists.isc.org [mailto:bind-users-bounces+batpower83=yahoo.co...@lists.isc.org] On Behalf Of Peter Andreev Sent: Monday, January 25, 2010 12:15 PM To: BIND Users Mailing List Subject: Re: Delegation question! Have you requested delegation? 2010/1/25 Alans Hello, When I check our dns ip from external server for ptr records it shows nothing but 93.in-addr.arpa.6562IN SOA ns-pri.ripe.net. dns-help.ripe.net. 2010012534 3600 7200 1209600 7200 We bought 93.x.x.0/x from RIPE, does that mean that RIPE didn't delegate 93.x.x.0/x to us? Regards, Alans ___ 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
Re: Delegation question!
Yes, of course, at least they needs to know nameservers for that zone. http://ripe.net/rs/reverse/reverse_howto.html 2010/1/25 Alans > I’m new with this ISP, but I don’t think they requested that. > > Your point is RIPE won’t give delegations without request, right? > > > > Regards, > > Alans > > > > *From:* bind-users-bounces+batpower83=yahoo.co...@lists.isc.org [mailto: > bind-users-bounces+batpower83 = > yahoo.co...@lists.isc.org] *On Behalf Of *Peter Andreev > *Sent:* Monday, January 25, 2010 12:15 PM > *To:* BIND Users Mailing List > *Subject:* Re: Delegation question! > > > > Have you requested delegation? > > 2010/1/25 Alans > > Hello, > > When I check our dns ip from external server for ptr records it shows > nothing but > 93.in-addr.arpa.6562IN SOA ns-pri.ripe.net. > dns-help.ripe.net. 2010012534 3600 7200 1209600 7200 > We bought 93.x.x.0/x from RIPE, does that mean that RIPE didn't delegate > 93.x.x.0/x to us? > > Regards, > Alans > > ___ > 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
Re: Delegation question!
Also you did not *buy* the addresses from RIPE as RIPE does not *sell* addresses. You leased the addressed from RIPE. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
On Fri, Feb 04, 2011 at 09:55:07PM +1100, Jean-Yves Avenard wrote a message of 112 lines which said: > Now if I uncomment the NS ad.domain.com. mel.domain.com will not > resolve anymore: General rule with Unix daemons: always read the log. You'll find the error message. BIND-specific rule: test your zone with named-checkzone. Here, I suggest you will get a "Out of zone data" error (once there is a delegation, the A record for the same name is probably a mistake). ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
Hi On 4 February 2011 22:15, Stephane Bortzmeyer wrote: > General rule with Unix daemons: always read the log. You'll find the > error message. > > BIND-specific rule: test your zone with named-checkzone. no errors of any kind are reported, in the log nor by named-checkzone > > Here, I suggest you will get a "Out of zone data" error (once there is > a delegation, the A record for the same name is probably a mistake). > hum... named-checkzone domain.com /etc/namedb/sp/db.domain.com zone domain.com/IN: loaded serial 2011020401 OK Actually I just found what caused it not to work ; I have forwarders set ; If I comment-out the forwarders line ; then everything work as it should Can't delegation works if forwarders are enabled ? Thanks Jean-Yves ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
I changed:
zone "domain.com" {
type master;
file "internal/db.domain.com";
check-names ignore;
notify TRUE;
allow-update { key "rndc-key"; };
};
to:
zone "domain.com" {
type master;
file "internal/db.domain.com";
check-names ignore;
notify TRUE;
allow-update { key "rndc-key"; };
// Cancel the forwarding for this authoritative domain.
forwarders {
};
};
and it's working !
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
Just re read that message and it didn't make too much sense so will try again as there is no full stop at the end of the following line ; NS ad.domain.com it would end up looking like this ;domain.com NS ad.domain.com.domain.com if you put a full stop at the end of this line see below it should work NS ad.domain.com. ad A 192.168.0.3 you could also do this NS ad ad A 192.168.0.3 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
> Actually I just found what caused it not to work ; I have forwarders > set ; If I comment-out the forwarders line ; then everything work as > it should > Can't delegation works if forwarders are enabled ? Unless I'm misunderstanding something, it should work. Here's an extract from the BIND 9.7 ARM, section 6.2.16.2: "Forwarding occurs only on those queries for which the server is not authoritative and does not have the answer in its cache." How exactly had you configured forwarding in your named.conf file? Regards Eivind Olsen ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
On 4 February 2011 22:51, Balder wrote: > not sure how forwarders fixed this but looking at your zone it is > because you have reset your ORIGIN and not put a fuul stop at the end > of the ad record > ;=as there is no dit at the end of ad.domain.com this will > become. put a full stop at the end of the record and it should work > ;domain.com NS ad.domain.com.domain.com > ; NS ad.domain.com My bad... I improperly copied it; it should have read: NS ad.domain.com. and that's how i had it set up here. If I do not have the forwarders disabled for that particular zone ; it fails ... it's puzzling ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
> mel A 192.168.0.3 > ; NS ad.domain.com You are already defining an A record for "mel". I'd try commenting that one out when you put the NS line back in (and make sure to give that NS line a name of its own then, since it can then no longer piggyback off the previous line you've just commented out). You didn't mention whether you already were commenting out the A record or not. Check your logs to see if BIND complains about anything. Also try pushing your zonefile through named-checkzone. Regards Eivind Olsen ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
Hi
On 4 February 2011 22:54, Eivind Olsen wrote:
> Unless I'm misunderstanding something, it should work. Here's an extract
> from the BIND 9.7 ARM, section 6.2.16.2:
>
> "Forwarding occurs only on those queries for which the server is not
> authoritative and does not have the answer in its cache."
>
> How exactly had you configured forwarding in your named.conf file?
I use bind that comes with mac os 10.6 server (9.6.0-APPLE-P2);
named.conf at the beginning includes a file options.conf.apple like so:
options {
include "/etc/dns/options.conf.apple";
};
options.conf.apple contains:
directory "/var/named";
forwarders { 203.59.24.3; 203.0.178.191; 203.134.24.70; };
allow-transfer { none; };
in named.conf I then have:
include "/etc/dns/privateView.conf";
which contains:
view "intranet_view" {
match-clients { 127.0.0.0/8; 192.168.0.0/23; };
allow-recursion { "internal"; };
zone "." {
type hint;
file "named.ca";
};
zone "domain.com" {
type master;
file "internal/db.domain.com";
check-names ignore;
notify TRUE;
allow-update { key "rndc-key"; };
// Cancel the forwarding for this authoritative domain.
forwarders {
};
};
On the other hand ; is the server authoritative for the sub-domain
mel.domain.com provided I added the delegation ?
digg shows something like:
;; AUTHORITY SECTION:
mel.domain.com. 7200IN NS ad.domain.com.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
On 4 February 2011 12:28, Jean-Yves Avenard wrote: > I changed: not sure how forwarders fixed this but looking at your zone it is because you have reset your ORIGIN and not put a fuul stop at the end of the ad record domain.com. IN SOA m.domain.com. domainmaster.domain.com. ( 2011020405 ; serial 7200 ; refresh (2 hours) 1800 ; retry (30 minutes) 1209600; expire (2 weeks) 86400 ; minimum (1 day) ) NS m.domain.com. MX 0 mail.domain.com. $ORIGIN domain.com. A 192.168.0.2 ; glue record m A 192.168.0.2 mel A 192.168.0.3 ;=as there is no dit at the end of ad.domain.com this will become. put a full stop at the end of the record and it should work ;domain.com NS ad.domain.com.domain.com ; NS ad.domain.com ad A 192.168.0.3 --- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
Dnia 2011-02-04 23:16 Jean-Yves Avenard napisał(a):
>Hi
>
>On 4 February 2011 22:54, Eivind Olsen wrote:
>
>> Unless I'm misunderstanding something, it should work. Here's an extract
>> from the BIND 9.7 ARM, section 6.2.16.2:
>>
>> "Forwarding occurs only on those queries for which the server is not
>> authoritative and does not have the answer in its cache."
>>
>> How exactly had you configured forwarding in your named.conf file?
>
>I use bind that comes with mac os 10.6 server (9.6.0-APPLE-P2);
>
>named.conf at the beginning includes a file options.conf.apple like so:
>options {
>include "/etc/dns/options.conf.apple";
>};
>
>options.conf.apple contains:
>directory "/var/named";
>
>forwarders { 203.59.24.3; 203.0.178.191; 203.134.24.70; };
>
>allow-transfer { none; };
>
>in named.conf I then have:
>include "/etc/dns/privateView.conf";
>
>which contains:
>view "intranet_view" {
>
>match-clients { 127.0.0.0/8; 192.168.0.0/23; };
>
> allow-recursion { "internal"; };
>
>zone "." {
>type hint;
> file "named.ca";
>};
>
>zone "domain.com" {
>type master;
> file "internal/db.domain.com";
> check-names ignore;
>notify TRUE;
> allow-update { key "rndc-key"; };
>// Cancel the forwarding for this authoritative domain.
>forwarders {
>};
>};
>
>On the other hand ; is the server authoritative for the sub-domain
>mel.domain.com provided I added the delegation ?
>digg shows something like:
>;; AUTHORITY SECTION:
>mel.domain.com.7200IN NS ad.domain.com.
This answer is not stating that it's authorative, but only that authorities
are below.
My wild guess ont what's happening, and why disabling forwarders fix this:
without NS m.domain.com is authorative for mel.domain.com, so it answers for
A mel.domain.com without issues.
Now, with NS, it's not authorative, as you've just set up a delegation. So,
when it receives the question it forwards it to one of three forwarding
servers. And they probably don't know how to access ad.domain.com (as it has
private IP adress, and these are public - that's one part of guess), they
end up not resolving the name.
Can verify that 203.59.24.3; 203.0.178.191; 203.134.24.70; can call
192.168.0.3, on that address?
Also, keep in mind that normally you should not use only one NS per
delegation, but a minimum of two. Here, for a testing environment (I guess)
it'll work, but don't do it on production environment.
Torinthiel
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
On Feb 4, 2011, at 3:25 AM, Jean-Yves Avenard wrote: > Actually I just found what caused it not to work ; I have forwarders > set ; If I comment-out the forwarders line ; then everything work as > it should > > Can't delegation works if forwarders are enabled ? Only if either (a) the forwarders can resolve the name, or (b) you disable forwarding for either the authoritative zone or the delegated child zone. What you are seeing is the expected behavior. Keep in mind, a BIND server does two quite different jobs: authoritatively answering queries about local zones and recursive/caching resolution of remote zones. Mixing the two services in one named.conf can be confusing and can lead to complex interplay between their configurations. It can also cause problems for DNSSEC. You should strive to avoid it. Chris Buxton BlueCat Networks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
On Fri, Feb 04, 2011 at 09:55:07PM +1100, Jean-Yves Avenard wrote:
> Hi there..
>
> I'm trying to create a delegation to a sub-domain ; for some reasons
> I'm getting no-where
>
> I have a domain.com zone ; I'd like to delegate mel.domain.com to
> another dns server (windows server DNS fwiw)
> Here is my zone file:
...
> domain.com. IN SOA m.domain.com. domainmaster.domain.com. (
...
> )
> NS m.domain.com.
> MX 0 mail.domain.com.
...
> A 192.168.0.2
> ; glue record
> m A 192.168.0.2
> mel A 192.168.0.3
> ; NS ad.domain.com
> ad A 192.168.0.3
> ---
>
> when NS ad.domain.com line is commented out ; querying for
> mel.domain.com is properly resolved:
>
> bash-3.2# dig @192.168.0.2 mel.domain.com
>
> ; <<>> DiG 9.6.0-APPLE-P2 <<>> @192.168.0.2 mel.domain.com
...
> ;; ANSWER SECTION:
> mel.domain.com. 7200IN A 192.168.0.3
...
> Now if I uncomment the NS ad.domain.com. mel.domain.com will not
> resolve anymore:
>
> bash-3.2# dig @192.168.0.2 mel.domain.com
>
> ; <<>> DiG 9.6.0-APPLE-P2 <<>> @192.168.0.2 mel.domain.com
...
> For what it's worth; ad.domain.com (the other dns server) properly
> answer the query:
> bash-3.2# dig @192.168.0.3 mel.domain.com
>
> ; <<>> DiG 9.6.0-APPLE-P2 <<>> @192.168.0.3 mel.domain.com
...
> ;; ANSWER SECTION:
> mel.domain.com. 600 IN A 192.168.0.3
...
As someone else mentioned, the main problem was the lack of a period
('.') at the end of the delegating server name.
I don't remember anyone saying outright that, once you have delegated
the domain, any records intended for that domain in the delegating
domain are completely ignored. [It was hinted at.] In other words,
the "A" record for "mel" above gets ignored when delegation is on. [So
I always put the delegated domain name explicitly in front of a
delegating NS record line.]
Also, you have a pair of completely useless $ORIGIN lines in your file.
I find it very rare that $ORIGIN lines are actually useful in master
copies of zone files. Mostly they confuse, especially if they are
sufficiently far away from where one is focused in the file that one is
not aware how the domain has changed. [In machine-generated files such
as slaved copies of zone files, it's not expected that humans will be
reading the file, so confusion is not a consideration.]
Teaching texts should use comments rather than $ORIGIN lines to indicate
what the domain is at given points in a zone file.
IMHO, of course.
--
/*\
**
** Joe Yao j...@tux.org - Joseph S. D. Yao
**
\*/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation question
In article ,
Jean-Yves Avenard wrote:
> Actually I just found what caused it not to work ; I have forwarders
> set ; If I comment-out the forwarders line ; then everything work as
> it should
>
> Can't delegation works if forwarders are enabled ?
No. When you have forwarders configured, it means "When you need to
recurse to answer a query, forward the query to the forwarders instead
of following delegation records."
Why did you configure forwarders in the first place if your server can
follow delegations? Do you think there's a difference between
delegations from your own zone (you want to follow) and delegations from
the root (you want to use the forwarders)?
You can override the general forwarders option by configuring a
forwarding zone:
zone "mel.domain.com" {
type forward;
forwarders {};
};
The empty forwarders clause in here disables forwarders, so it follows
delegations.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
