Re: forward first: iterative or recursive query

[Kevin Darcy]

On 5/6/2011 6:40 AM, iharrathi@orange-ftgroup.com wrote:

Thanks for the answer but:

   *
  In the example i post yesterday: on my server1 the recursion is
  enabled (recursion yes), but the server1 can't recurse because i
  stop it on firewall and it can't contact the outside.
   *
  You say "Don't use forwarding from a recursive server to a
  non-recursive server" but when my server1 is recursive (and the
  firewall allow it to contact the outside), and server2 don't
  recurse because in it's conf recursion is set to no, when i ask
  my server1 about ftp.example.com  (dig @0
  ftp.example.com ) , server1 forward the
  query to server2 which answer by the CNAME www.abc.com
   and then server1 recurse to find the IP of
  www.abc.com . and everything works fine.

   *
  you say "If server 2 is auth-only or otherwise can't resolve the
  address of www.abc.com , then forwarding a
  query to it is not going to work." No as i say when server1
  really recurse ( recursion yes, and the firewall allow the
  server1 to contact outside) and server2 don't recurse (recursion
  no) all is ok: server1 forward the query to server2 which answer
  by the CNAME www.abc.com  and then server1
  recurse to find the IP of www.abc.com . and
  everything works fine.
   *
  You say "then using a stub zone for example.com
  will work", why i will use a stub zone
  since  a forward do the same thing expected.

And my question is always this:
forward only; as i read means a recursive query, in other term a query 
with the RD bit is enabled. which means that when my server1 (which 
has recursion yes but can't recurse because the firewall don't 
allow it to contact the outside, which finally means server1 can't 
recuse) ask server2 about ftp.example.com , 
server2 will normally make all the work means he read on it's zone, 
then find the CNAME, then make a recursion to resolve the CNAME and 
finally send the IP to server1.

why server2 don't recurse to find the IP of www.abc.com?
According to your own words: "server2 don't [sic] recurse because in 
it's [sic] conf recursion is set to no". There's your answer.


Why are you dealing with such screwy configs anyway? If you need to 
resolve things from the Internet, then you need to have a resolution 
path to the Internet (either directly talking to Internet nameservers, 
or some forwarding chain -- hopefully as short as possible, preferably 
0-length -- to something that can query Internet nameservers directly). 
If, on the other hand, you need to resolve something internal, then you 
only need to have an authoritative source of that information 
internally. Why are you complicating things more than they need to be? 
Setting recursion and then blocking it via a firewall? What purpose does 
that serve?




- Kevin

thanks for your help.


*De :* Chris Buxton [mailto:chris.p.bux...@gmail.com]
*Envoyé :* jeudi 5 mai 2011 19:47
*À :* HARRATHI Issam Ext OLNC/DPS
*Cc :* bind-users@lists.isc.org
*Objet :* Re: forward first: iterative or recursive query

If recursion is disabled, forwarding doesn't happen. I think
you've confused some terms and configurations.

Don't use forwarding from a recursive server to a non-recursive
server. Use a stub zone instead, if you can't rely on the
recursion process to find the correct server to query.

If server 2 is auth-only or otherwise can't resolve the address of
www.abc.com , then forwarding a query to it is
not going to work. However, if server 1 is a caching server and is
able to resolve www.abc.com , then using a
stub zone for example.com  will work; server 2
will send the CNAME record to server 1, and then server 1 will
resolve the final address record on its own.

Chris Buxton
BlueCat Networks

On May 5, 2011, at 2:15 AM, mailto:iharrathi@orange-ftgroup.com>>
mailto:iharrathi@orange-ftgroup.com>> wrote:


Hi,
i have a server called server1 that is acting as a cache server(
recursion none). And i forward the zone example.com
 to server2 which has recursion enabled and
master on some zone like example.com .
this is the forwarding zone on server1:
zone "example.com " {
type forward;
forward only;
forwarders { IP_of server2;  };
};
and server2 is ma

Re: DNSSEC submit of DLV vs DNSKEY records?

[Chris Thompson]

On May 6 2011, Mark Andrews wrote:


Once the parent zone is signed and is accepting DS/DNSKEY records for
child zones there shouldn't be any need to add records to DLV.


Well, for some value of "should" ...

It might be that the parent, although signed and accepting DS records,
does not yet have a chain of trust back to the root, or via dlv.isc.org.

It might be that although it does, you don't trust the parent's
operational procedures enough to be sure that will continue to be
the case, as compared with your ability to maintain your own records
in dlv.isc.org.

It might be that you want nameservers with restricted support for
signing algorithms to be able to validate your zone. dlv.isc.org
only needs RSASHA1 + NSEC, back to the root needs at least RSASHA256
and often NSEC3 as well.

In fact, our main forward zone (cam.ac.uk) and main IPv4 reverse zone
(111.131.in-addr.arpa) do now have DNSSEC chains of trust all the way
from the root zone. But I haven't removed their entries from dlv.isc.org
yet, and in fact am still quite undecided as to when it will be
appropriate to do so.

--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: how to check if a slave zone is expired

[Warren Kumari]

On May 6, 2011, at 11:16 AM, John Wobus wrote:

> I try to catch zones that are not updating on the slaves
> to which I have access.  I compare the modtime of the zone
> file with the current time and the refresh interval
> for the zone.  Typically I allow a failure or two
> before alerting, e.g. wait 1 refresh + 2 retry intervals.
> If the expire interval is very short, this could
> be too late.

Mind sharing the script? It's one of those things that I keep meaning to write, 
but never get enough roundtoits...

W

> 
> Depending upon the expire interval and refresh interval,
> the window in which you can be alerted and troubleshoot
> a problem might be short.  If you're slaving zones
> for another site, you might not have control of that.
> 
> If you find out refreshes aren't happening long before
> the expiration, and if the zone is pretty static (e.g. a single
> www.example.com address), you don't have to jump very fast to
> address things if the expire interval is weeks.  If folks are
> depending upon records that are dynamic, you want to respond
> pretty quickly.
> 
> John Wobus
> ___
> 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: forward first: iterative or recursive query

[David Sparro]

On 5/6/2011 6:40 AM, iharrathi@orange-ftgroup.com wrote:

Thanks for the answer but:



  You say "Don't use forwarding from a recursive server to a
  non-recursive server" but when my server1 is recursive (and the
  firewall allow it to contact the outside), and server2 don't
  recurse because in it's conf recursion is set to no, when i ask my
  server1 about ftp.example.com  (dig @0
  ftp.example.com ) , server1 forward the
  query to server2 which answer by the CNAME www.abc.com
   and then server1 recurse to find the IP of
  www.abc.com . and everything works fine.

And my question is always this:
forward only; as i read means a recursive query, in other term a query
with the RD bit is enabled. which means that when my server1 (which has
recursion yes but can't recurse because the firewall don't allow it to
contact the outside, which finally means server1 can't recuse) ask
server2 about ftp.example.com , server2 will
normally make all the work means he read on it's zone, then find the
CNAME, then make a recursion to resolve the CNAME and finally send the
IP to server1.



why server2 don't recurse to find the IP of www.abc.com?
thanks for your help.


Because you told it not to "> server2 don't recurse because in it's conf 
recursion is set to no"


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

Re: how to check if a slave zone is expired

[John Wobus]

I try to catch zones that are not updating on the slaves
to which I have access.  I compare the modtime of the zone
file with the current time and the refresh interval
for the zone.  Typically I allow a failure or two
before alerting, e.g. wait 1 refresh + 2 retry intervals.
If the expire interval is very short, this could
be too late.

Depending upon the expire interval and refresh interval,
the window in which you can be alerted and troubleshoot
a problem might be short.  If you're slaving zones
for another site, you might not have control of that.

If you find out refreshes aren't happening long before
the expiration, and if the zone is pretty static (e.g. a single
www.example.com address), you don't have to jump very fast to
address things if the expire interval is weeks.  If folks are
depending upon records that are dynamic, you want to respond
pretty quickly.

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

[DNSSEC] Resolver behavior with broken DS records

[Stephane Bortzmeyer]

In an (involuntary) experiment under .FR, I discovered that the rule
"at least one DS must match for a child zone to be authenticated" is
wrong if a broken DS is present. In our case, the field Algorithm in
the DS did not match the one in the DNSKEY. While there was another
correct DS for the child zone, BIND 9.6 and 9.8 servfail. So, the
incorrect DS made the child zone bogus.

If there are DS and that one of them is dangling (going to an
unexisting key) or unknown (new algorithm), BIND validates if there is
at least one DS it can process.

I won't discuss the legality of this behaviour (my reading of the RFC
on this point is that a resolver can do what it wants) but I believe
that the current BIND behaviour is:

* inconsistent: BIND uses a "at least one DS" policy when there are
dangling DS but a "all the DS" when there are broken DS.

* dangerous: a simple mistake in one of the DS will make the zone
bogus.

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

Re: Error when trying to make secondary nameserver from copying primary nameserver

[Samad Agha]

Elvind & Ben,

Thanks so much for your quick replies, I really appreciate it. I'll try out
your suggested solutions on Monday, since I'm off today, and will report
back my results.

Thanks again and have a nice weekend.

SA

On Thu, May 5, 2011 at 6:10 PM, Eivind Olsen  wrote:

> Samad Agha wrote:
>
> > 1- found out which version of bind dsn1 is running and installed exactly
> > that version on dns2:
> > [root@dns1 named]# named -v
> > BIND 9.3.6-P1-RedHat-9.3.6-16.P1.el5
>
> That version is quite old. In general, just because server 1 has an old
> BIND isn't a reason to choose an old BIND on server 2 as well.
>
> > 2- Copied dns1:/etc/named.conf from primary server (dns1) onto dns2 and
> > chown it:
> > [root@dns2 ~]# ls -l /etc/named.conf
> > -rw-r--r-- 1 root named 2876 May  3 09:30 /etc/named.conf
>
> Sure, you can use an existing named.conf as basis for your 2nd nameserver,
> but if you want to turn you setup into a normal master/slave setup, you'll
> also want to configure one of them with zones of type slave, and telling
> BIND who the master is, something like:
>
> zone "my.zonename" {
>type slave;
>file "path/to/my.zonename-file";
>masters {
>192.168.1.10; // use proper IP address instead
>};
> };
>
> You might also want to set up your zonefile transfers, typically by
> allowing the slave to transfer from the master (so you might need to
> change the configuration on the master), and perhaps disallowing anyone
> else from doing transfers.
>
> > 4- I get the "couldn't open pid file '/var/run/named/named.pid':
> > Permission
> > denied" as follows:
>
> Check the permissions of that directory, and see if there's also a
> named.pid file already. I'm not familiar with that old RedHat package, so
> I on't know how it expects things to be set up, if you're using the
> bundled start script.
> If the permissions initially look good, I suggest you look into whether
> you have SELinux running, maybe its policies are making problems for you?
>
> Regards
> Eivind Olsen
> eiv...@aminor.no
>
>
> ___
> 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: forward first: iterative or recursive query

[iharrathi.ext]

Thanks for the answer but:

 *
In the example i post yesterday: on my server1 the recursion is enabled 
(recursion yes), but the server1 can't recurse because i stop it on firewall 
and it can't contact the outside.
 *
You say "Don't use forwarding from a recursive server to a non-recursive 
server" but when my server1 is recursive (and the firewall allow it to contact 
the outside), and server2 don't recurse because in it's conf recursion is set 
to no, when i ask my server1 about ftp.example.com (dig 
@0 ftp.example.com) , server1 forward the query to 
server2 which answer by the CNAME www.abc.com and then 
server1 recurse to find the IP of www.abc.com. and 
everything works fine.
 *
you say "If server 2 is auth-only or otherwise can't resolve the address of 
www.abc.com, then forwarding a query to it is not going to 
work." No as i say when server1 really recurse ( recursion yes, and the 
firewall allow the server1 to contact outside) and server2 don't recurse 
(recursion no) all is ok: server1 forward the query to server2 which answer by 
the CNAME www.abc.com and then server1 recurse to find the 
IP of www.abc.com. and everything works fine.
 *
You say "then using a stub zone for example.com will 
work", why i will use a stub zone since  a forward do the same thing expected.

And my question is always this:
forward only; as i read means a recursive query, in other term a query with the 
RD bit is enabled. which means that when my server1 (which has recursion yes 
but can't recurse because the firewall don't allow it to contact the outside, 
which finally means server1 can't recuse) ask server2 about 
ftp.example.com, server2 will normally make all the work 
means he read on it's zone, then find the CNAME, then make a recursion to 
resolve the CNAME and finally send the IP to server1.
why server2 don't recurse to find the IP of www.abc.com?

thanks for your help.



De : Chris Buxton [mailto:chris.p.bux...@gmail.com]
Envoyé : jeudi 5 mai 2011 19:47
À : HARRATHI Issam Ext OLNC/DPS
Cc : bind-users@lists.isc.org
Objet : Re: forward first: iterative or recursive query

If recursion is disabled, forwarding doesn't happen. I think you've confused 
some terms and configurations.

Don't use forwarding from a recursive server to a non-recursive server. Use a 
stub zone instead, if you can't rely on the recursion process to find the 
correct server to query.

If server 2 is auth-only or otherwise can't resolve the address of 
www.abc.com, then forwarding a query to it is not going to 
work. However, if server 1 is a caching server and is able to resolve 
www.abc.com, then using a stub zone for 
example.com will work; server 2 will send the CNAME record 
to server 1, and then server 1 will resolve the final address record on its own.

Chris Buxton
BlueCat Networks

On May 5, 2011, at 2:15 AM, 
mailto:iharrathi@orange-ftgroup.com>> 
mailto:iharrathi@orange-ftgroup.com>> 
wrote:

Hi,
i have a server called server1 that is acting as a cache server( recursion 
none). And i forward the zone example.com to server2 which 
has recursion enabled and master on some zone like 
example.com.
 this is the forwarding zone on server1:
zone "example.com" {
type forward;
forward only;
forwarders { IP_of server2;  };
};
and server2 is master of the zone example.com:

zone "example.com" {
type master;
file "master/db.example.com";
};


BUT the problem is here:
db.example.com:

$ORIGIN example.com.
www   A1.2.3.4
ftp  CNAME  www.abc.com



server1 can resolve www.example.com, but can't resolve 
ftp.example.com since the server2 sends the answer which 
is www.abc.com and not the IP, and my server1 can't make 
recursion to resolve www.abc.com.

why?
from server1 when i dig on server2: dig @IP-server2 
www.example.com it sends to me the IP, all is OK!!! 
but with a forwarding statement it sends only the CNAME

server1 is bind9.6-ESV-R4  et server2 bind-9.4.2

Thanks.
Issam HARRATHI


De : Chris Buxton [mailto:chris.p.bux...@gmail.com]
Envoyé : mercredi 4 mai 2011 08:49
À : HARRATHI Issam Ext OLNC/DPS
Cc : bind-users@lists.isc.org
Objet : Re: forward first: iterative or recursive query

With a static-stub zone, you would get an iterative query. Forwarding always 
results in a recursive query.

How are you determini

Re: does authority named require the external name servers?

[Jeff Pang]

2011/5/6 Matus UHLAR - fantomas :

>
> BIND will search for def.com only for recursive queries, not for iterative,
> and only when the client has recursion allowed on it.
>

you are totally mis-unstanding me.

-- 
Jeff Pang
www.DNSbed.com
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: does authority named require the external name servers?

[Matus UHLAR - fantomas]

> 2011/5/2 Torinthiel :
> > Authority named never sends queries on it's own, only responds to
> > submitted queries.

On 02.05.11 20:17, Jeff Pang wrote:
> Doesn't it execute iterative query from the root server?

root servers do not send queries.

> For example, given the nameserver is authority for abc.com.
> And abc.com has two NS RRs:
> 
> abc.com.IN   NS   ns1.def.com.
> abc.com.IN   NS   ns2.def.com.
> 
> def.com is authoritative resolved by other nameservers.

BIND will search for def.com only for recursive queries, not for iterative,
and only when the client has recursion allowed on it.

> If there is no correct nameserver list in /etc/resolv.conf, then this
> named can't find ns1.def.com and ns2.def.com?

the BIND has nothing to do with resolv.conf.

-- 
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
10 GOTO 10 : REM (C) Bill Gates 1998, All Rights Reserved!
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users