RE: resolving-problem

2013-07-23 Thread Ejaz
Thank you so much for your email and support, 

 

Pls, See, the dig + trace output when use ns1.nesma.net.sa,   at the end it
say connection timedout. so please can you to find out the  problem is from
where???

 

 

 

[root@ns1 ~]# dig +trace www.fransiplus.com  , .

 

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> +trace
www.fransiplus.com

;; global options: +cmd

.   504930  IN  NS  j.root-servers.net.

.   504930  IN  NS  c.root-servers.net.

.   504930  IN  NS  a.root-servers.net.

.   504930  IN  NS  e.root-servers.net.

.   504930  IN  NS  f.root-servers.net.

.   504930  IN  NS  k.root-servers.net.

.   504930  IN  NS  g.root-servers.net.

.   504930  IN  NS  l.root-servers.net.

.   504930  IN  NS  i.root-servers.net.

.   504930  IN  NS  d.root-servers.net.

.   504930  IN  NS  m.root-servers.net.

.   504930  IN  NS  b.root-servers.net.

.   504930  IN  NS  h.root-servers.net.

;; Received 512 bytes from 212.119.64.2#53(212.119.64.2) in 5388 ms

 

com.172800  IN  NS  m.gtld-servers.net.

com.172800  IN  NS  c.gtld-servers.net.

com.172800  IN  NS  i.gtld-servers.net.

com.172800  IN  NS  a.gtld-servers.net.

com.172800  IN  NS  l.gtld-servers.net.

com.172800  IN  NS  g.gtld-servers.net.

com.172800  IN  NS  d.gtld-servers.net.

com.172800  IN  NS  k.gtld-servers.net.

com.172800  IN  NS  f.gtld-servers.net.

com.172800  IN  NS  b.gtld-servers.net.

com.172800  IN  NS  e.gtld-servers.net.

com.172800  IN  NS  h.gtld-servers.net.

com.172800  IN  NS  j.gtld-servers.net.

;; Received 508 bytes from 192.33.4.12#53(192.33.4.12) in 1789 ms

 

fransiplus.com. 172800  IN  NS  ns1.alfransi.com.sa.

fransiplus.com. 172800  IN  NS  ns2.alfransi.com.sa.

;; Received 87 bytes from 192.5.6.30#53(192.5.6.30) in 202 ms

 

;; connection timed out; no servers could be reached

 

Ejaz 

 

  _  

From: Steven Carr [mailto:sjc...@gmail.com] 
Sent: Sunday, July 21, 2013 3:09 PM
To: Ejaz
Cc: Bind users
Subject: Re: resolving-problem

 

So the logs would seem to indicate that the server responded to your PC, the
only way you can see exactly what happened with that response is with
traffic captures on the name server and your PC. 

 

Steve

 

 


On 21 Jul 2013, at 12:52, "Ejaz"  wrote:

 

I can resolve yahoo and here the snippet of logs, 

 

21-Jul-2013 14:46:11.119 queries: info: client 212.119.65.13#2007: query:
yahoo.com.cyberia.net.sa IN A + (212.71.32.19)

21-Jul-2013 14:46:11.122 queries: info: client 212.119.65.13#2008: query:
yahoo.com IN A + (212.71.32.19)

 

But, Where as 

 

I can't resolve fransiplus, here is the logs. 

 

21-Jul-2013 14:46:19.135 queries: info: client 212.119.65.13#2009: query:
fransiplus.com.cyberia.net.sa IN A + (212.71.32.19)

21-Jul-2013 14:46:19.138 queries: info: client 212.119.65.13#2010: query:
fransiplus.com IN A + (212.71.32.19) 

 

 

I didin't see any difference. 

 

Ejaz

___
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: NAMED LOGS

2013-07-23 Thread Matthäus Wander
* Mark Andrews [2013-07-23 06:42]:
>> The method is described here (Figure 4):
>> http://homes.cs.washington.edu/~gribble/papers/king.pdf
>>
>> Using a delegation is a technical detail. It's not different than
>> sending a query directly to the zone servers.
> 
> Send queries for domains that the server is NOT configured to accept
> is very different to sending queries for domains the server IS
> configured to accept.
> 
> You just cost the rw adminstrators time and money investigation the
> source of unexpected traffic.  You cost everyone on the list some
> time and money helping out the rw administrators.
> 
> The actual cost of the traffic in inconsequential to the other costs
> that have resulted from your actions.  TLD administrators actually
> need to look for abnormal traffic as they are high value targets.

Ok, I see your point. I will use opt-in for further measurements.

Regards,
Matt

-- 
Universität Duisburg-Essen
Verteilte Systeme
Bismarckstr. 90 / BC 316
47057 Duisburg



smime.p7s
Description: S/MIME Kryptografische Unterschrift
___
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 I change the zone file from command line?

2013-07-23 Thread Manish Rane
Well, I am trying to configure DNS System Monitoring stuff with Nagios
plugins. This monitor the server status and if any of th link fails remove
the said IP from zone and reload the zone. This entry would have low TTL so
that traffic would be routed to new entry instantly.

Lets say I have two ISPs terminated on my firewall and www.example.com with
private IP 172.16.3.10 is natted with 1.2.3.4 and 5.6.7.8 with TTL value 300
Nagios plugin check_tcp would monitor those links or IPs on port 80 and if
any of the link fails I can have by any mean edit the zone file and remove
the IP associated with failed link so that traffic would never reach to
that IP.

Upon recovery the plugin will show the result GREEN and I can again have
the A record added in zone file, thus reload the zone. Due to the low TTL I
believe there shouldn't be any issue for populating those changes faster.

What say guys?




--
Thanks and Regards,
Manish R


On Tue, Jul 23, 2013 at 11:46 AM, Mark Andrews  wrote:

>
> In message <
> can3um4yrt+t7cp2ezywq-rm5ewx3-ygok9vkxvug4qbxcbp...@mail.gmail.com>
> , Mike Hale writes:
> > This seems pretty straight forward.
> >
> > Use your standard bash tools to modify the file when necessary, then
> > you should simply be able to call rndc reload ZONENAME in the script.
>
> Though why one would want to do this rather than just updating the
> zone using DDNS is beyond me.   It's not like DDNS can't be made
> secure by using TSIG.
>
> Normalize the zone file using named-checkzone.
> Use awk or similar to change the relevent entries and update the SOA
> serial.
> Use named-checkzone to confirm that the resulting file is still valid then
> if it is rename it and reload the zone.
>
> named-checkzone -D -q zone file |
> awk '$1 == "server" && $4 == "A" { print $1, $2, $3, $4, NEWIP}
> $4 == "SOA" { $7 = $7 + 1; print }' > temp
> named-checkzone -q zone temp && mv temp file && rndc reload zone
>
> Mark
>
> > On Mon, Jul 22, 2013 at 10:28 PM, Mihamina Rakotomandimby
> >  wrote:
> > > Hello,
> > >
> > > I did not catch what you're trying to achieve.
> > > Please give more details.
> > >
> > >
> > > On 2013-07-23 08:25, Manish Rane wrote:
> > >
> > > Hi Folks,
> > >
> > > Wondering if I can edit/change the static zone file as a result of
> certain
> > > bash script. Well, I am trying to write a script which will monitor the
> > > server on certain ports and it if fails to connect to the server it
> will
> > > delete or add the entry from zone file so that traffic will be routed
> to
> > > another server, possible?
> > >
> > > OR does any one aware of such solution available in open source?
> > >
> > >
> > >
> > > ___
> > > 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
> > >
> > >
> > >
> > > --
> > > RMA.
> > >
> > >
> > > ___
> > > 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
> >
> >
> >
> > --
> > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
> > ___
> > 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
>
___
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 I change the zone file from command line?

2013-07-23 Thread Manish Rane
In that case how about other entries from same zone? I m talking about any
consequences on static entries or the ones which I dont want to me dynamic.
On 23 Jul 2013 16:45, "Kumar, Naveen, Vodafone Group" <
naveen.kuma...@vodafone.com> wrote:

>
>
> Manish,
>
> ** **
>
> You can configure the zone as dynamic, this way it can start taking
> nsupdates,
>
> Upon failed TCP monitor by nagios, it can fire nsupdate command and update
> the A record accordingly.
>
> ** **
>
> Regards,
>
> Naveen
>
> ** **
>
> *From:* bind-users-bounces+naveen.kumar=cw@lists.isc.org [mailto:
> bind-users-bounces+naveen.kumar=cw@lists.isc.org] *On Behalf Of *Manish
> Rane
> *Sent:* Tuesday, July 23, 2013 4:30 PM
> *To:* Mark Andrews
> *Cc:* bind-us...@isc.org
> *Subject:* Re: Can I change the zone file from command line?
>
> ** **
>
> Well, I am trying to configure DNS System Monitoring stuff with Nagios
> plugins. This monitor the server status and if any of th link fails remove
> the said IP from zone and reload the zone. This entry would have low TTL so
> that traffic would be routed to new entry instantly.
>
> Lets say I have two ISPs terminated on my firewall and www.example.comwith 
> private IP 172.16.3.10 is natted with 1.2.3.4 and 5.6.7.8 with TTL
> value 300
>
> Nagios plugin check_tcp would monitor those links or IPs on port 80 and if
> any of the link fails I can have by any mean edit the zone file and remove
> the IP associated with failed link so that traffic would never reach to
> that IP.
>
> Upon recovery the plugin will show the result GREEN and I can again have
> the A record added in zone file, thus reload the zone. Due to the low TTL I
> believe there shouldn't be any issue for populating those changes faster.
> 
>
> What say guys?
>
> 
>
> ** **
>
>
> 
>
> --
> Thanks and Regards,
> Manish R
>
> ** **
>
> On Tue, Jul 23, 2013 at 11:46 AM, Mark Andrews  wrote:
>
>
> In message <
> can3um4yrt+t7cp2ezywq-rm5ewx3-ygok9vkxvug4qbxcbp...@mail.gmail.com>
>
> , Mike Hale writes:
> > This seems pretty straight forward.
> >
> > Use your standard bash tools to modify the file when necessary, then
> > you should simply be able to call rndc reload ZONENAME in the script.***
> *
>
> Though why one would want to do this rather than just updating the
> zone using DDNS is beyond me.   It's not like DDNS can't be made
> secure by using TSIG.
>
> Normalize the zone file using named-checkzone.
> Use awk or similar to change the relevent entries and update the SOA
> serial.
> Use named-checkzone to confirm that the resulting file is still valid then
> if it is rename it and reload the zone.
>
> named-checkzone -D -q zone file |
> awk '$1 == "server" && $4 == "A" { print $1, $2, $3, $4, NEWIP}
> $4 == "SOA" { $7 = $7 + 1; print }' > temp
> named-checkzone -q zone temp && mv temp file && rndc reload zone
>
> Mark
>
>
> > On Mon, Jul 22, 2013 at 10:28 PM, Mihamina Rakotomandimby
> >  wrote:
> > > Hello,
> > >
> > > I did not catch what you're trying to achieve.
> > > Please give more details.
> > >
> > >
> > > On 2013-07-23 08:25, Manish Rane wrote:
> > >
> > > Hi Folks,
> > >
> > > Wondering if I can edit/change the static zone file as a result of
> certain
> > > bash script. Well, I am trying to write a script which will monitor the
> > > server on certain ports and it if fails to connect to the server it
> will
> > > delete or add the entry from zone file so that traffic will be routed
> to
> > > another server, possible?
> > >
> > > OR does any one aware of such solution available in open source?
> > >
> > >
> > >
> > > ___
> > > 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
> > >
> > >
> > >
> > > --
> > > RMA.
> > >
> > >
> > > ___
> > > 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
> >
> >
> >
> > --
> > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
> > ___
> > 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.

Re: New warning message...

2013-07-23 Thread Matus UHLAR - fantomas

In article ,
Matus UHLAR - fantomas  wrote:

No, it does not. If a mail gets delivered to address, which is sending it
further ("forwarding it"), the envelope sender has to be changed, because
it's not the original sender who sends the another mail.  Forwarding without
changing envelope address is already broken, it's just people don't care
without SPF.


On 22.07.13 12:22, Barry Margolin wrote:

They're talking about auto-forwarding, not people resending a message
they received. For instance, mail to bar...@alum.mit.edu is
automatically forwarded by the alum.mit.edu server to my ISP email
address. Many people also have vanity domains with auto-forwarding
enabled like this.


I'm afraid the same applies even in these cases.
How can you differ between vanity forwarder and spam/phish with fake from
address?


Rewrite the sender's address. You have more choices, SRS is one of them.


This would help in other ways too - at my former employer we've had to deal
with broken forwardings, therefore undeliverable mail and undeliverable
bounces.  Rewriting sender and properly detecting undeliverable garbage
helps there too.


Who should the sender be changed to?  AFAIK, it has never been standard
practice to rewrite the sender when simply forwarding to an alias, which
is what this is.


Because they did not care. Long time ago even open relays were not an issue
until people started abusing them.


...OK this is off-topic here. However this was already discussed and the
conclusion was that the SPF record is NOT dead. We just need enough time to
deal with these issues.

--
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.
I don't have lysdexia. The Dog wouldn't allow that.
___
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: New warning message...

2013-07-23 Thread Daniel McDonald



On 7/23/13 7:36 AM, "Matus UHLAR - fantomas" wrote:

>> In article ,
>> Matus UHLAR - fantomas wrote:
>>> No, it does not. If a mail gets delivered to address, which is sending it
>>> further ("forwarding it"), the envelope sender has to be changed, because
>>> it's not the original sender who sends the another mail.  Forwarding without
>>> changing envelope address is already broken, it's just people don't care
>>> without SPF.
> 
> On 22.07.13 12:22, Barry Margolin wrote:
>> They're talking about auto-forwarding, not people resending a message
>> they received. For instance, mail to bar...@alum.mit.edu is
>> automatically forwarded by the alum.mit.edu server to my ISP email
>> address. Many people also have vanity domains with auto-forwarding
>> enabled like this.
> 
Ok, but in this case you are trusting alum.mit.edu as a forwarder.  And it
is specific to you as the recipient, not all of the people in the world
getting your mail.  So add them to trusted-hosts and apply spf before the
last trusted...  Problem solved.  Or add enough whitelist points to
counteract SPF problems when a /^Received.{5,40}\balum.mit.edu/ header is
found in your mail.  In either case, you have to either trust your forwarder
to evaluate SPF for you and trust the SPF evaluation headers they insert, or
consider that forwarder part of your mail infrastructure and instruct your
spf evaluator to ignore those headers.

But again, that's your choice for outsourcing part of your mail solution to
another entity.  

> ...OK this is off-topic here. However this was already discussed and the
> conclusion was that the SPF record is NOT dead. We just need enough time to
> deal with these issues.

-- 
Daniel J McDonald, CCIE # 2495, CISSP # 78281

___
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: NAMED LOGS

2013-07-23 Thread Carl Byington
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 2013-07-23 at 14:42 +1000, Mark Andrews wrote:
> You just cost the rw adminstrators time and money investigation the
> source of unexpected traffic.  You cost everyone on the list some
> time and money helping out the rw administrators.

There seems to be a common idea in many educational institutions that
sending unwanted traffic in the name of research is ok.

Jul 23 08:00:36 xx sendmail[22101]: r6NF0XFo022101: ruleset=check_rcpt,
arg1=scan-ad...@umich.edu, relay=researchscan010.eecs.umich.edu
[141.212.121.10], reject=550 5.7.1 scan-ad...@umich.edu... Relaying
denied. Proper authentication required.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlHupYUACgkQL6j7milTFsFsvQCeMYqQ2Qu3JANjQ39ylFHEYhch
2HoAn04ApKLETRQnHvQW3uYPL6+bfeTv
=24Q7
-END PGP SIGNATURE-


___
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: NAMED LOGS

2013-07-23 Thread Ian Manners
Hi Carl,

> There seems to be a common idea in many educational institutions that
> sending unwanted traffic in the name of research is ok.

Which is why I have so many educational institutions
are blacklisted in my firewall.. I nolonger report abuse,
I simply add to the BL permanently now.

2 are whitelisted because they asked nicely, and they have
something I want so its a mutual thing.

There are a lot of others such as Anti-virus online scanners
that check websites before the 'client' lands on the page, 
and pen testing companys that also think its fine to sling crp
at anyones server for testing, or checking, with no hint of
asking before doing so. Same basket as all the bots that
read robots.txt then ignore it, because they can.

This is becoming a bigger issue for many at present,
especially when people like myself have limited bandwidth,
though I check logs as well I nolonger investigate to much,
I simply update the relevant conf file.

Cheers
Ian Manners


Cheers
Ian Manners
http://www.os2site.com/
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


RE: resolving-problem

2013-07-23 Thread Shawn Bakhtiar
Do you run your name servers from behind a firewall, or is your firewall 
(iptables) turned on?

We run our name servers from behind a firewall, my network computers give the 
same problem when I run  dig +trace www.fransiplus.com

The only place I can run the dig +trace www.fransiplus.com without failing is 
on the external authoritative servers. 

There is a good explanation of what this fails here:
https://otrs.menandmice.com/otrs/public.pl?Action=PublicFAQZoom;CategoryID=21;ItemID=75

But I think this is a different problem, than not being able to resolve the 
fransiplus.com from your PC



From: me...@cyberia.net.sa
To: sjc...@gmail.com
Subject: RE: resolving-problem
Date: Tue, 23 Jul 2013 11:36:46 +0300
CC: bind-users@lists.isc.org

















Thank you so much for your email and
support, 

 

Pls, See, the dig + trace output when
use ns1.nesma.net.sa,   at the end it say connection timedout. so please can
you to find out the  problem is from where???

 

 

 

[root@ns1 ~]# dig +trace www.fransiplus.com, …

 

; <<>> DiG
9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> +trace
www.fransiplus.com

;; global options: +cmd

.   504930  IN 
NS  j.root-servers.net.

.   504930  IN 
NS  c.root-servers.net.

.   504930  IN 
NS  a.root-servers.net.

.   504930  IN 
NS  e.root-servers.net.

.   504930  IN 
NS  f.root-servers.net.

.   504930  IN 
NS  k.root-servers.net.

.   504930  IN 
NS  g.root-servers.net.

.   504930  IN 
NS  l.root-servers.net.

.   504930  IN 
NS  i.root-servers.net.

.   504930  IN 
NS  d.root-servers.net.

.   504930  IN 
NS  m.root-servers.net.

.   504930  IN  NS 
b.root-servers.net.

.   504930  IN 
NS  h.root-servers.net.

;; Received 512 bytes from
212.119.64.2#53(212.119.64.2) in 5388 ms

 

com.172800  IN 
NS  m.gtld-servers.net.

com.172800  IN 
NS  c.gtld-servers.net.

com.172800  IN 
NS  i.gtld-servers.net.

com.172800  IN 
NS  a.gtld-servers.net.

com.172800  IN 
NS  l.gtld-servers.net.

com.172800  IN 
NS  g.gtld-servers.net.

com.172800  IN 
NS  d.gtld-servers.net.

com.172800  IN 
NS  k.gtld-servers.net.

com.172800  IN 
NS  f.gtld-servers.net.

com.172800  IN 
NS  b.gtld-servers.net.

com.172800  IN 
NS  e.gtld-servers.net.

com.172800  IN 
NS  h.gtld-servers.net.

com.172800  IN  NS 
j.gtld-servers.net.

;; Received 508 bytes from
192.33.4.12#53(192.33.4.12) in 1789 ms

 

fransiplus.com. 172800  IN 
NS  ns1.alfransi.com.sa.

fransiplus.com. 172800  IN 
NS  ns2.alfransi.com.sa.

;; Received 87 bytes from
192.5.6.30#53(192.5.6.30) in 202 ms

 

;; connection timed out; no servers could
be reached

 

Ejaz 

 









From: Steven Carr
[mailto:sjc...@gmail.com] 

Sent: Sunday, July 21, 2013 3:09
PM

To: Ejaz

Cc: Bind users

Subject: Re: resolving-problem



 



So the logs would seem to indicate that the server responded to your
PC, the only way you can see exactly what happened with that response is with
traffic captures on the name server and your PC. 





 





Steve





 





 







On 21 Jul 2013, at 12:52, "Ejaz"  wrote:





 

I can resolve yahoo and here the snippet of logs, 

 



21-Jul-2013 14:46:11.119 queries: info: client
212.119.65.13#2007: query: yahoo.com.cyberia.net.sa IN A + (212.71.32.19)

21-Jul-2013 14:46:11.122 queries: info: client
212.119.65.13#2008: query: yahoo.com IN A +
(212.71.32.19)

 

But, Where as 

 

I can’t resolve fransiplus, here is the logs. 

 

21-Jul-2013 14:46:19.135 queries: info: client
212.119.65.13#2009: query: fransiplus.com.cyberia.net.sa IN A + (212.71.32.19)

21-Jul-2013 14:46:19.138 queries: info: client
212.119.65.13#2010: query: fransiplus.com
IN A + (212.71.32.19) 

 

 

I didin’t see any difference. 

 

Ejaz












___
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: resolving-problem

2013-07-23 Thread John Wingenbach
Don't confuse dig +trace with what is happening or not at your name 
server.  When trace is enabled, dig performs the queries needed itself 
from the location the dig is run.  So, in other words, if your system is 
not allowed to send or receive DNS packets, then you'll never be able to 
perform a resolution and you will get the error noted below.  Any and 
all recursion performed by name servers on your behalf will mean 
different behaviour vs a +trace.


To correctly determine where the resolution is failing, the dig needs to 
be run from the outside (closest to the internet) inward.  Do not bother 
using +trace when your system is not by default performing the entire 
resolution.  When you find the system which is failing to resolve the 
name, then you know it is a problem w/ that system and it's next step 
towards the internet.


-- John


On 7/23/2013 12:35 PM, Shawn Bakhtiar wrote:
Do you run your name servers from behind a firewall, or is your 
firewall (iptables) turned on?


We run our name servers from behind a firewall, my network computers 
give the same problem when I run dig +trace www.fransiplus.com 



The only place I can run the dig +trace www.fransiplus.com without 
failing is on the external authoritative servers.


There is a good explanation of what this fails here:
https://otrs.menandmice.com/otrs/public.pl?Action=PublicFAQZoom;CategoryID=21;ItemID=75

But I think this is a different problem, than not being able to 
resolve the fransiplus.com  from your PC





From: me...@cyberia.net.sa
To: sjc...@gmail.com
Subject: RE: resolving-problem
Date: Tue, 23 Jul 2013 11:36:46 +0300
CC: bind-users@lists.isc.org

Thank you so much for your email and support,

Pls, See, the dig + trace output when use ns1.nesma.net.sa,   at the 
end it say connection timedout. so please can you to find out the 
 problem is from where???


[root@ns1 ~]# dig +trace www.fransiplus.com 
, ...


; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> +trace 
www.fransiplus.com


;; global options: +cmd

. 504930  IN NS  j.root-servers.net.

.  504930  IN NS  c.root-servers.net.

. 504930  IN NS  a.root-servers.net.

. 504930  IN NS  e.root-servers.net.

. 504930  IN NS  f.root-servers.net.

. 504930  IN NS  k.root-servers.net.

. 504930  IN NS  g.root-servers.net.

. 504930  IN NS  l.root-servers.net.

. 504930  IN NS  i.root-servers.net.

. 504930  IN NS  d.root-servers.net.

. 504930  IN NS  m.root-servers.net.

. 504930  IN  NS b.root-servers.net.

. 504930  IN NS  h.root-servers.net.

;; Received 512 bytes from 212.119.64.2#53(212.119.64.2) in 5388 ms

com. 172800  IN NS  m.gtld-servers.net.

com.  172800  IN NS  c.gtld-servers.net.

com. 172800  IN NS  i.gtld-servers.net.

com. 172800  IN NS  a.gtld-servers.net.

com. 172800  IN NS  l.gtld-servers.net.

com. 172800  IN NS  g.gtld-servers.net.

com. 172800  IN NS  d.gtld-servers.net.

com. 172800  IN NS  k.gtld-servers.net.

com. 172800  IN NS  f.gtld-servers.net.

com. 172800  IN NS  b.gtld-servers.net.

com. 172800  IN NS  e.gtld-servers.net.

com. 172800  IN NS  h.gtld-servers.net.

com. 172800  IN  NS j.gtld-servers.net.

;; Received 508 bytes from 192.33.4.12#53(192.33.4.12) in 1789 ms

fransiplus.com. 172800  IN NS  ns1.alfransi.com.sa.

fransiplus.com. 172800  IN NS  ns2.alfransi.com.sa.

;; Received 87 bytes from 192.5.6.30#53(192.5.6.30) in 202 ms

;; connection timed out; no servers could be reached

Ejaz



*From:*Steven Carr [mailto:sjc...@gmail.com]
*Sent:* Sunday, July 21, 2013 3:09 PM
*To:* Ejaz
*Cc:* Bind users
*Subject:* Re: resolving-problem

So the logs would seem to indicate that the server responded to your 
PC, the only way you can see exactly what happened with that response 
is with traffic captures on the name server and your PC.


Steve


On 21 Jul 2013, at 12:52, "Ejaz" > wrote:


I can resolve yahoo and here the snippet of logs,

21-Jul-2013 14:46:11.119 queries: info: client 212.119.65.13#2007: 
query: yahoo.com.cyberia.net.sa IN A + (212.71.32.19)


21-Jul-2013 14:46:11.122 queries: info: client 212.119.65.13#2008: 
query: yahoo.com  IN A + (212.71.32.19)


But, Where as

I can't resolve fransiplus, here is the logs.

21-Jul-2013 14:46:19.135 queries: info: client 212.119.65.13#2009: 
query: fransiplus.com.cyberia.net.sa IN A + (212.71.32.19)


21-Jul-2013 14:46:19.138 queries: info: client 212.119.65.13#2010: 
query: fransiplus.com  IN A + (212.71.32.19)


I didin't see any difference.

Ejaz


___ Please visit 
https://lists.isc.org/mailman/listinfo/bind-users to unsubs

Re: Can I change the zone file from command line?

2013-07-23 Thread Kevin Darcy
I'm not sure I understand your concern. nsupdate will only update the 
records you tell it to update. So, if you have a "static" record, then 
don't target it with nsupdate and you should be fine.


When you dial a telephone number, do you worry that your dialing may 
have "consequences" against telephone numbers that you *didn't* dial? 
Seems very unlikely.


- Kevin
On 7/23/2013 7:21 AM, Manish Rane wrote:


In that case how about other entries from same zone? I m talking about 
any consequences on static entries or the ones which I dont want to me 
dynamic.


On 23 Jul 2013 16:45, "Kumar, Naveen, Vodafone Group" 
mailto:naveen.kuma...@vodafone.com>> wrote:




Manish,

You can configure the zone as dynamic, this way it can start
taking nsupdates,

Upon failed TCP monitor by nagios, it can fire nsupdate command
and update the A record accordingly.

Regards,

Naveen

*From:*bind-users-bounces+naveen.kumar=cw@lists.isc.org

[mailto:bind-users-bounces+naveen.kumar
=cw@lists.isc.org
] *On Behalf Of *Manish Rane
*Sent:* Tuesday, July 23, 2013 4:30 PM
*To:* Mark Andrews
*Cc:* bind-us...@isc.org 
*Subject:* Re: Can I change the zone file from command line?

Well, I am trying to configure DNS System Monitoring stuff with
Nagios plugins. This monitor the server status and if any of th
link fails remove the said IP from zone and reload the zone. This
entry would have low TTL so that traffic would be routed to new
entry instantly.

Lets say I have two ISPs terminated on my firewall and
www.example.com  with private IP
172.16.3.10 is natted with 1.2.3.4 and 5.6.7.8 with TTL value 300

Nagios plugin check_tcp would monitor those links or IPs on port
80 and if any of the link fails I can have by any mean edit the
zone file and remove the IP associated with failed link so that
traffic would never reach to that IP.

Upon recovery the plugin will show the result GREEN and I can
again have the A record added in zone file, thus reload the zone.
Due to the low TTL I believe there shouldn't be any issue for
populating those changes faster.

What say guys?


--
Thanks and Regards,
Manish R

On Tue, Jul 23, 2013 at 11:46 AM, Mark Andrews mailto:ma...@isc.org>> wrote:


In message
mailto:can3um4yrt%2bt7cp2ezywq-rm5ewx3-ygok9vkxvug4qbxcbp...@mail.gmail.com>>

, Mike Hale writes:
> This seems pretty straight forward.
>
> Use your standard bash tools to modify the file when necessary, then
> you should simply be able to call rndc reload ZONENAME in the
script.

Though why one would want to do this rather than just updating the
zone using DDNS is beyond me.   It's not like DDNS can't be made
secure by using TSIG.

Normalize the zone file using named-checkzone.
Use awk or similar to change the relevent entries and update the
SOA serial.
Use named-checkzone to confirm that the resulting file is still
valid then
if it is rename it and reload the zone.

named-checkzone -D -q zone file |
awk '$1 == "server" && $4 == "A" { print $1, $2, $3, $4, NEWIP}
$4 == "SOA" { $7 = $7 + 1; print }' > temp
named-checkzone -q zone temp && mv temp file && rndc reload zone

Mark


> On Mon, Jul 22, 2013 at 10:28 PM, Mihamina Rakotomandimby
> mailto:miham...@rktmb.org>> wrote:
> > Hello,
> >
> > I did not catch what you're trying to achieve.
> > Please give more details.
> >
> >
> > On 2013-07-23 08:25, Manish Rane wrote:
> >
> > Hi Folks,
> >
> > Wondering if I can edit/change the static zone file as a
result of certain
> > bash script. Well, I am trying to write a script which will
monitor the
> > server on certain ports and it if fails to connect to the
server it will
> > delete or add the entry from zone file so that traffic will be
routed to
> > another server, possible?
> >
> > OR does any one aware of such solution available in open source?
> >
> >
> >
> > ___
> > 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
> >
> >
> >
> > --
> > RMA.
> >
> >
> > ___
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> > unsubscribe from this list
> >
> > bind-users mailing list
> > 

Re: Question about cache reload

2013-07-23 Thread Lawrence K. Chen, P.Eng.


- Original Message -
> I have just set up DNSSEC on bind 9.9.3.  I had set up the zone and
> put a DS record out at the registrar.  Several days later I found
> that I had set up the keys incorrectly using only NSEC verses NSEC3
> so i changed the keys.  I deleted the old keys and DS record, and
> had bind resign everything and put out the new DS record.  I used
> some testing sites and things looked good.  I then got a message
> from an administrator at a remote site running bind in strict mode
> stating my DNSSEC was broken.  It turns out he had cached the old
> info and it had not updated.  From this I am guessing that bind does
> not flush cache if there is a problem like this, it just fails to
> resolve.
> 
> The other question I am attempting to research is what is the best
> way to do the yearly rekeying and updating of the DS records at the
> registrar to avoid this in the future.
> 

Maybe in preparation for the change, lower the validity period to reduce cache 
lifetimes.  Not sure if the full procedure for Emergency Key Rollover would 
work in this case.

Since there's something about mixing algorithms?  Because I had problems when I 
was switching from RSASHA1-NSEC3-SHA1 to RSASHA256... which is odd, because the 
registrar had apparently done itor maybe they had problems that they didn't 
pass along...though I didn't follow their scheme as closely (partly because I 
lack the ability to instantly update my DS records.)

... EDUCAUSE is in the process of transitioning the DNSSEC signature
... for the .edu zone from RSA-NSEC3-SHA1 (algorithm 7) to
... RSA/SHA-256 (algorithm 8). Here are the steps that will occur:
... 
.. The algorithm rollover will begin with pre-signing records
.. with new ZSK key, using the RSA/SHA-256 algorithm. This
.. period is expected to begin on November 19, 2011 and will
.. last for nine days.
.. 
.. The pre-signing period will be immediately followed by the
.. publication of the DNSKEY records for the new KSK and ZSK
.. keys in the .edu zone. Once resolvers have the new KSK’s
.. DNSKEY record cached, the DS record for the new KSK will
.. be published in the root zone and the previous DS record
.. will be removed.
.. 
.. The records in the .edu zone will be signed with both
.. old and new algorithms with both ZSK and KSK keys for a
.. period of 14 days. After this period, the old ZSK and the
.. old KSK will have their DNSKEY records removed from the
.. .edu zone. The old ZSK will continue signing for three
.. more days to allow time for all caching resolvers to have
.. purged the old ZSK’s DNSKEY record from their caches.
..
.. Immediately following this three-day period, the rollover
.. will conclude with a period when the signatures with the
.. old ZSK will be systematically and gradually removed
.. from the .edu zone. This period is expected to last
.. between four and seven days.

Lawrence
___
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: Question about cache reload

2013-07-23 Thread Lawrence K. Chen, P.Eng.


- Original Message -

> Firstly you should not use NSEC3 unless you NEED to use NSEC3, NSEC
> is more than sufficient for most zones.  NSEC3 is more expensive
> for both servers and clients.  99.999% of zones (forward and reverse)
> DO NOT need to use NSEC3.  They derive NO benefit from NSEC3 compared
> to using NSEC.  In most case NSEC3 is actually a negative as not
> only is is more computationally expensive it is harder to debug.
> 
> NSEC3 is pointless for IP6.ARPA, IN-ADDR.ARPA and any other similarly
> structured zones.  The structure defeats any attempt to prevent zone
> walking.
> 
> For most forward zones preventing zone walking does NOTHING except
> give warm fuzzy feelings.  It does NOT make your machines any safer.
> Yes I know that this is against all the advice you have received
> in the past but really it doesn't appreciably help and you are
> deluding yourself if you think it does.
> 
> Mark

I remember when I first started working on DNSSEC...on whether NSEC3 should be 
done or not.  signing the zone was taking either forever or forever-plus.  
Moving my master server from a V240 to a T2000 helped

But, we then got some outside secondaries.  And, initially they didn't support 
NSEC3.  That would have to wait until they upgraded their server hardware/OS 
before they would build bind with that support?  So, I thought that answered 
whether we would do NSEC3 or not.  But, then our IT Security group weighed 
inso we're doing NSEC3.  We'll just hold off on having outside secondaries.

Though since then, we've only had one major interruption of our 
connectivity...and its was due the packet inspection appliance that IT Security 
runs.  The log volume in it had filled up, so it stopped passing traffic.  It 
did expose some problems with in local DNS resolution, that someday I should do 
something about.

T2000 was still taking what was considered to be too longpeople around here 
expect that when I make complete their dns change request, that they can 
immediately look up host and see the new IP.  Ignoring that they queried all 
the caching servers on campus before the request was done, so the old info will 
be there for up to 1 day.  Some people will request that the TTL be lowered in 
advance of the change, though they don't necessarily allow a day between the 
two.

Later I had the choice of moving to a T5120 or an X4100, where I found that the 
X4100 was faster than the T5120.  My master server is currently an X4170.  And, 
later our automation includes flushing our zones from the caching servers  
Also have a script to flush other zones when needed, but that process can't 
tell what zones were updated...so it can't tell what zone to flush. (one is see 
if files associated with our signed zones changed, do signing, call rndc reload 
and then over time flush caching servers in some order...the other is if any 
file has changed, do rndc reload)

Wonder what I'll have when we scrap some 400+ Solaris servers ... by year end?

-- 
Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator
For: Enterprise Server Technologies (EST) -- & SafeZone Ally
Snail: Computing and Telecommunications Services (CTS)
Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102
Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: lkc...@ksu.edu
Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library
___
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: IPv4 not working reverse on > /24 cidr

2013-07-23 Thread /dev/rob0
On Mon, Jul 22, 2013 at 12:17:12PM -0400, Barry Margolin wrote:
> In article ,
>  Ryan Pavely  wrote:
> 
> > So that would suggest any time any block > a /24 is hosted you 
> > must actually host the parent zone, pointing to the larger cidr, 
> > and then have your normal files for each cider in that block.
> 
> Of course. How else do you expect DNS to figure out that it should 
> look in the RFC 1918 zone? The CNAMEs are the link between the 
> normal reverse DNS name and the CIDR-style name. There's nothing 
> automatic about RFC 1918.

ITYM RFC 2317, "Classless IN-ADDR.ARPA delegation":

https://tools.ietf.org/html/rfc2317
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
___
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


permissions for DNSSEC zone signing

2013-07-23 Thread David Newman
FreeBSD 9.1-RELEASE-p4, BIND 9.9.3-P1 ESV installed from ports

What are the correct directory and file permissions for DNSSEC static
zone signing with bind?

By default, everything in /var/named/etc/namedb is owned by bind except
for the master directory. For example:

drwxr-xr-x bind wheel dynamic
drwxr-xr-x bind bind managed-keys
drwxr-xr-x root wheel master
-rw-r--r-- bind wheel named.conf
-rw-r--r-- bind wheel named.root
-r--r--r-- bind wheel rndc.conf
drwxr-xr-x bind wheel slave
drwxr-xr-x bind wheel working

Without DNSSEC, this is fine. With DNSSEC enabled, there are permissions
errors in /var/log/messages after restarting named, because bind can't
create the jnl/jbk/signed files. For example:

Jul 23 14:57:16 hostname named[42000]: master/example.org.db.jbk:
create: permission denied

Here are the DNSSEC-specific bits from named.conf:
options {
..
managed-keys-directory "/etc/namedb/managed-keys";
dnssec-enable yes;
dnssec-lookaside auto;
dnssec-validation auto;
..
}

zone "example.org" {
type master;
file "master/example.org.db";
allow-query { any; };
allow-transfer { xfer; };
key-directory "/etc/namedb/managed-keys";
inline-signing yes;
auto-dnssec maintain;
};

There is a valid KSK and ZSK for this zone in managed-keys.

Changing ownership of the master directory results in a complaint when
restarting named that master wants to be owned by root.

Thanks in advance for clues on sorting out this permissions problem.

dn

___
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: resolving-problem

2013-07-23 Thread Mark Andrews

In message , "Ejaz" writes:
> 
> Thank you so much for your email and support, 
> 
> Pls, See, the dig + trace output when use ns1.nesma.net.sa,   at the end it
> say connection timedout. so please can you to find out the  problem is from
> where???
> 
> 
> [root@ns1 ~]# dig +trace www.fransiplus.com  , .
> 
> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> +trace 
> www.fransiplus.com
> ;; global options: +cmd
> .   504930  IN  NS  j.root-servers.net.
> .   504930  IN  NS  c.root-servers.net.
> .   504930  IN  NS  a.root-servers.net.
> .   504930  IN  NS  e.root-servers.net.
> .   504930  IN  NS  f.root-servers.net.
> .   504930  IN  NS  k.root-servers.net.
> .   504930  IN  NS  g.root-servers.net.
> .   504930  IN  NS  l.root-servers.net.
> .   504930  IN  NS  i.root-servers.net.
> .   504930  IN  NS  d.root-servers.net.
> .   504930  IN  NS  m.root-servers.net.
> .   504930  IN  NS  b.root-servers.net.
> .   504930  IN  NS  h.root-servers.net.
> ;; Received 512 bytes from 212.119.64.2#53(212.119.64.2) in 5388 ms

You can talk to your local nameserver and have got the set of root server
names.
 
> com.172800  IN  NS  m.gtld-servers.net.
> com.172800  IN  NS  c.gtld-servers.net.
> com.172800  IN  NS  a.gtld-servers.net.
> com.172800  IN  NS  l.gtld-servers.net.
> com.172800  IN  NS  g.gtld-servers.net.
> com.172800  IN  NS  d.gtld-servers.net.
> com.172800  IN  NS  k.gtld-servers.net.
> com.172800  IN  NS  f.gtld-servers.net.
> com.172800  IN  NS  b.gtld-servers.net.
> com.172800  IN  NS  e.gtld-servers.net.
> com.172800  IN  NS  h.gtld-servers.net.
> com.172800  IN  NS  j.gtld-servers.net.
> ;; Received 508 bytes from 192.33.4.12#53(192.33.4.12) in 1789 ms

You can talk to the root servers and they responded with a referral to the
com servers.

> fransiplus.com. 172800  IN  NS  ns1.alfransi.com.sa.
> fransiplus.com. 172800  IN  NS  ns2.alfransi.com.sa.
> ;; Received 87 bytes from 192.5.6.30#53(192.5.6.30) in 202 ms

You can talk to the com servers and they responded with a referral to
ns1.alfransi.com.sa and ns2.alfransi.com.sa.
 
> ;; connection timed out; no servers could be reached

You tried to talk to ns1.alfransi.com.sa (193.22.249.48) and
ns2.alfransi.com.sa (193.22.249.148) but they failed to respond to
you.  I would be looking at routing/firewall issues between you and
them.

They don't appear to be using a firewall which is blocking based
on source port (I can get a response using 53, 1023 and other source
ports).

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


Re: permissions for DNSSEC zone signing

2013-07-23 Thread Mark Andrews

In message <51ef00af.4090...@networktest.com>, David Newman writes:
> FreeBSD 9.1-RELEASE-p4, BIND 9.9.3-P1 ESV installed from ports
> 
> What are the correct directory and file permissions for DNSSEC static
> zone signing with bind?
> 
> By default, everything in /var/named/etc/namedb is owned by bind except
> for the master directory. For example:
> 
> drwxr-xr-x bind wheel dynamic
> drwxr-xr-x bind bind managed-keys
> drwxr-xr-x root wheel master
> -rw-r--r-- bind wheel named.conf
> -rw-r--r-- bind wheel named.root
> -r--r--r-- bind wheel rndc.conf
> drwxr-xr-x bind wheel slave
> drwxr-xr-x bind wheel working
> 
> Without DNSSEC, this is fine. With DNSSEC enabled, there are permissions
> errors in /var/log/messages after restarting named, because bind can't
> create the jnl/jbk/signed files. For example:
> 
> Jul 23 14:57:16 hostname named[42000]: master/example.org.db.jbk:
> create: permission denied
> 
> Here are the DNSSEC-specific bits from named.conf:
> options {
>   ..
> managed-keys-directory "/etc/namedb/managed-keys";
> dnssec-enable yes;
> dnssec-lookaside auto;
> dnssec-validation auto;
>   ..
> }
> 
> zone "example.org" {
> type master;
> file "master/example.org.db";
> allow-query { any; };
> allow-transfer { xfer; };
> key-directory "/etc/namedb/managed-keys";
> inline-signing yes;
> auto-dnssec maintain;
> };
> 
> There is a valid KSK and ZSK for this zone in managed-keys.
> 
> Changing ownership of the master directory results in a complaint when
> restarting named that master wants to be owned by root.

Rename the file to "dynamic/example.org.db" and update named.conf.
The directory "dynamic" has permissions set up for dynamic master files
which this zone is.

> Thanks in advance for clues on sorting out this permissions problem.
> 
> dn
> 
> ___
> 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: permissions for DNSSEC zone signing

2013-07-23 Thread David Newman


On 7/23/13 3:44 PM, Mark Andrews wrote:
> In message <51ef00af.4090...@networktest.com>, David Newman writes:
>> FreeBSD 9.1-RELEASE-p4, BIND 9.9.3-P1 ESV installed from ports
>>
>> What are the correct directory and file permissions for DNSSEC static
>> zone signing with bind?
>>
>> By default, everything in /var/named/etc/namedb is owned by bind except
>> for the master directory. For example:
>>
>> drwxr-xr-x bind wheel dynamic
>> drwxr-xr-x bind bind managed-keys
>> drwxr-xr-x root wheel master
>> -rw-r--r-- bind wheel named.conf
>> -rw-r--r-- bind wheel named.root
>> -r--r--r-- bind wheel rndc.conf
>> drwxr-xr-x bind wheel slave
>> drwxr-xr-x bind wheel working
>>
>> Without DNSSEC, this is fine. With DNSSEC enabled, there are permissions
>> errors in /var/log/messages after restarting named, because bind can't
>> create the jnl/jbk/signed files. For example:
>>
>> Jul 23 14:57:16 hostname named[42000]: master/example.org.db.jbk:
>> create: permission denied
>>
>> Here are the DNSSEC-specific bits from named.conf:
>> options {
>>  ..
>> managed-keys-directory "/etc/namedb/managed-keys";
>> dnssec-enable yes;
>> dnssec-lookaside auto;
>> dnssec-validation auto;
>>  ..
>> }
>>
>> zone "example.org" {
>> type master;
>> file "master/example.org.db";
>> allow-query { any; };
>> allow-transfer { xfer; };
>> key-directory "/etc/namedb/managed-keys";
>> inline-signing yes;
>> auto-dnssec maintain;
>> };
>>
>> There is a valid KSK and ZSK for this zone in managed-keys.
>>
>> Changing ownership of the master directory results in a complaint when
>> restarting named that master wants to be owned by root.
> 
> Rename the file to "dynamic/example.org.db" and update named.conf.
> The directory "dynamic" has permissions set up for dynamic master files
> which this zone is.

Thanks, Mark!

This is a *static* zone file but signing works as expected if:

1. the zone file is set up in a directory which bind can write to (e.g.,
/var/named/etc/namedb/dynamic, even for static zones); and

2. the zone file's serial number increments. (named did not create a
filename.jnl file until I incremented the zone file's serial number.)

Thanks very much for sorting out this permissions problem.

dn


> 
>> Thanks in advance for clues on sorting out this permissions problem.
>>
>> dn
>>
>> ___
>> 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: permissions for DNSSEC zone signing

2013-07-23 Thread Doug Barton

On 07/23/2013 04:48 PM, David Newman wrote:



On 7/23/13 3:44 PM, Mark Andrews wrote:

In message <51ef00af.4090...@networktest.com>, David Newman writes:

FreeBSD 9.1-RELEASE-p4, BIND 9.9.3-P1 ESV installed from ports


[...]


zone "example.org" {
 type master;
 file "master/example.org.db";
 allow-query { any; };
 allow-transfer { xfer; };
 key-directory "/etc/namedb/managed-keys";
 inline-signing yes;
 auto-dnssec maintain;
};

There is a valid KSK and ZSK for this zone in managed-keys.

Changing ownership of the master directory results in a complaint when
restarting named that master wants to be owned by root.


Rename the file to "dynamic/example.org.db" and update named.conf.
The directory "dynamic" has permissions set up for dynamic master files
which this zone is.


Thanks, Mark!

This is a *static* zone file but signing works as expected if:

1. the zone file is set up in a directory which bind can write to (e.g.,
/var/named/etc/namedb/dynamic, even for static zones); and

2. the zone file's serial number increments. (named did not create a
filename.jnl file until I incremented the zone file's serial number.)


The zone may be static but the "auto-dnssec maintain" process is 
equivalent to the dynamic updates process, so that is the correct 
directory.


Doug (who set up the permissions for named in FreeBSD ages ago)

___
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: resolving-problem

2013-07-23 Thread Liu Ganning

On 07/24/13 00:35, Shawn Bakhtiar wrote:
Do you run your name servers from behind a firewall, or is your 
firewall (iptables) turned on?


We run our name servers from behind a firewall, my network computers 
give the same problem when I run dig +trace www.fransiplus.com 



The only place I can run the dig +trace www.fransiplus.com without 
failing is on the external authoritative servers.


There is a good explanation of what this fails here:
https://otrs.menandmice.com/otrs/public.pl?Action=PublicFAQZoom;CategoryID=21;ItemID=75
I had the similar problem with Ejaz, and I had my problem resolved from 
your mail, the firewall!

Thanks!

--
Liu Ganning

___
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