Re: DNSSEC and upgrading/restoring

2014-01-28 Thread Alan Clegg

On Jan 27, 2014, at 7:32 PM, David Newman dnew...@networktest.com wrote:

 Asking again, in a different and more generic form: When rebuilding a
 bind 9.9.4 server running DNSSEC with auto maintain, are there any steps
 I need to take beyond just backing up /var/named/etc/namedb (this is on
 FreeBSD) and restoring?
 
 This server is authoritative and primary, and has slaves for multiple
 domains.
 
 I'm concerned about keeping keys, serial numbers, and any other dynamic
 info in sync.

Should be problem what-so-ever.

Just stop the old server, do the backup, restore it where your new system 
expects it then start the new one.  A brief outage of your master should be no 
issue is your slaves are working correctly.

Do make sure that the new version is built with the same options as the old one 
if you are replicating the file system locations of the data.  8-)

AlanC
-- 
Alan Clegg | +1-919-355-8851 | a...@clegg.com



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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: DNSSEC and upgrading/restoring

2014-01-28 Thread Thomas Schulz
 Asking again, in a different and more generic form: When rebuilding a
 bind 9.9.4 server running DNSSEC with auto maintain, are there any steps
 I need to take beyond just backing up /var/named/etc/namedb (this is on
 FreeBSD) and restoring?
 
 This server is authoritative and primary, and has slaves for multiple
 domains.
 
 I'm concerned about keeping keys, serial numbers, and any other dynamic
 info in sync.
 
 Thanks!
 
 dn

This may not apply to FreeBSD, but you should backup the main named.conf
if it is in some other directory than /var/named/etc/namedb. On my system
(Solaris) named.conf and a key file for managed keys for the root are in
/etc.

Tom Schulz
Applied Dynamics Intl.
sch...@adi.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


Forwarders Timeout

2014-01-28 Thread Phil Fagan
Is it possible to configure the forward (only|first) timeout?

So, first query a server listed in the forwarders statement and upon
receiving no resolution answer [ in ?configurable? seconds ] query
another server (e.g., based on cached information or hints file
configuration) (forward first).

Thanks,

-- 
Phil Fagan
Denver, CO
970-480-7618
___
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: Variable SOAs in negative responses

2014-01-28 Thread Matus UHLAR - fantomas

On 27.01.14 18:23, John Levine wrote:

A friend (really) asks this question: they have some DNSBLs, which get
a lot of queries.  Sometimes the answer has A or TXT records, meaning
the corresponding address is listed in the DNSBL, sometimes it's
NXDOMAIN which means the address isn't.

For addresses that aren't listed, some of the NXDOMAINs are a lot less
likely to change than others, e.g, the address of an outbound mail
server at a large mail provider is unlikely ever to be listed, but a
random host at a hosting provider in India, who knows.  So he'd like
to have the TTLs on some of those NXDOMAINs be longer than others, by
putting a different TTL in the SOA in the authority section.


If you know those IPs, why do you check them for being listed at all?
If any IP starts spamming, why to give it longer time to appear in the
blacklists? I don't think this makes sense at all...

--
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.
LSD will make your ECS screen display 16.7 million colors
___
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: Forwarders Timeout

2014-01-28 Thread Matus UHLAR - fantomas

On 28.01.14 10:08, Phil Fagan wrote:

Is it possible to configure the forward (only|first) timeout?


AFAIK not (yet). The forwarder selection is done in the same way as the
server selection by RTT meassuring.


--
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.
Windows found: (R)emove, (E)rase, (D)elete
___
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: Forwarders Timeout

2014-01-28 Thread Phil Fagan
That's kinda what I'm gleaning as well.

On Tue, Jan 28, 2014 at 12:43 PM, Matus UHLAR - fantomas
uh...@fantomas.sk wrote:
 On 28.01.14 10:08, Phil Fagan wrote:

 Is it possible to configure the forward (only|first) timeout?


 AFAIK not (yet). The forwarder selection is done in the same way as the
 server selection by RTT meassuring.


 --
 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.
 Windows found: (R)emove, (E)rase, (D)elete
 ___
 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



-- 
Phil Fagan
Denver, CO
970-480-7618
___
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: Variable SOAs in negative responses

2014-01-28 Thread Dave Warren

On 2014-01-28 11:28, Matus UHLAR - fantomas wrote:

On 27.01.14 18:23, John Levine wrote:

A friend (really) asks this question: they have some DNSBLs, which get
a lot of queries.  Sometimes the answer has A or TXT records, meaning
the corresponding address is listed in the DNSBL, sometimes it's
NXDOMAIN which means the address isn't.

For addresses that aren't listed, some of the NXDOMAINs are a lot less
likely to change than others, e.g, the address of an outbound mail
server at a large mail provider is unlikely ever to be listed, but a
random host at a hosting provider in India, who knows.  So he'd like
to have the TTLs on some of those NXDOMAINs be longer than others, by
putting a different TTL in the SOA in the authority section.


If you know those IPs, why do you check them for being listed at all?


John's question was from the point of view of the DNSBL operator. How 
would a DNSBL operator stop users of that DNSBL from performing lookups 
on certain IPs, and why would they bother?



If any IP starts spamming, why to give it longer time to appear in the
blacklists? I don't think this makes sense at all...


Because a lot of IPs simply are not candidates for listing at certain 
types of DNSBL sites. Too big to block is a thing.


A more straightforward example: If your DNSBL is designed to only list 
IPs that are running vulnerable web scripts *and* are not also 
legitimate mail servers, then Google's outbound MX will *never* be 
candidates for listing (regardless of how much they spew) and therefore 
a very large TTL'd NXDOMAIN would be appropriate. Frankly, any 
legitimate mail server would be a candidate for a large-TTL'd-NXDOMAIN 
for this type of list, not just big players like Google.


If a DNSBL operator knows that certain IPs are not candidates for 
listing (or at least not candidates for automated listing), why not let 
DNS caches keep that information for as long as possible?


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

Usenet is like a herd of performing elephants with diarrhea --
massive, difficult to redirect, awe-inspiring, entertaining, and a
source of mind-boggling amounts of shit when you least expect it.


___
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: Variable SOAs in negative responses

2014-01-28 Thread John Levine
For addresses that aren't listed, some of the NXDOMAINs are a lot less
likely to change than others, e.g, the address of an outbound mail
server at a large mail provider is unlikely ever to be listed, but a
random host at a hosting provider in India, who knows.  So he'd like
to have the TTLs on some of those NXDOMAINs be longer than others, by
putting a different TTL in the SOA in the authority section.

If you know those IPs, why do you check them for being listed at all?

The DNSBL operator knows the IPs belong to large mail providers.  The
clients don't, and are checking them because they're getting mail from
them.


If any IP starts spamming, why to give it longer time to appear in the
blacklists? I don't think this makes sense at all...

Most DNSBLs try to avoid false positives.  The chances that Gmail (or
whoever) would suddenly start sending so much spam that it would swamp
the real mail and make them worth listing are extremely low.

I realize there are DNSBLs that list on the merest whiff of spam and
don't care if they block legitimate mail.  That's not what we're
talking about here.

R's,
John
___
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: Variable SOAs in negative responses

2014-01-28 Thread Mark Andrews

In message 52e8258e.3060...@hireahit.com, Dave Warren writes:
 On 2014-01-28 11:28, Matus UHLAR - fantomas wrote:
  On 27.01.14 18:23, John Levine wrote:
  A friend (really) asks this question: they have some DNSBLs, which get
  a lot of queries.  Sometimes the answer has A or TXT records, meaning
  the corresponding address is listed in the DNSBL, sometimes it's
  NXDOMAIN which means the address isn't.
 
  For addresses that aren't listed, some of the NXDOMAINs are a lot less
  likely to change than others, e.g, the address of an outbound mail
  server at a large mail provider is unlikely ever to be listed, but a
  random host at a hosting provider in India, who knows.  So he'd like
  to have the TTLs on some of those NXDOMAINs be longer than others, by
  putting a different TTL in the SOA in the authority section.
 
  If you know those IPs, why do you check them for being listed at all?
 
 John's question was from the point of view of the DNSBL operator. How 
 would a DNSBL operator stop users of that DNSBL from performing lookups 
 on certain IPs, and why would they bother?
 
  If any IP starts spamming, why to give it longer time to appear in the
  blacklists? I don't think this makes sense at all...
 
 Because a lot of IPs simply are not candidates for listing at certain 
 types of DNSBL sites. Too big to block is a thing.
 
 A more straightforward example: If your DNSBL is designed to only list 
 IPs that are running vulnerable web scripts *and* are not also 
 legitimate mail servers, then Google's outbound MX will *never* be 
 candidates for listing (regardless of how much they spew) and therefore 
 a very large TTL'd NXDOMAIN would be appropriate. Frankly, any 
 legitimate mail server would be a candidate for a large-TTL'd-NXDOMAIN 
 for this type of list, not just big players like Google.

Which if the recursive servers are following RFC 2308 will be truncated to
~3 hours.
 
 If a DNSBL operator knows that certain IPs are not candidates for 
 listing (or at least not candidates for automated listing), why not let 
 DNS caches keep that information for as long as possible?
 
 -- 
 Dave Warren
 http://www.hireahit.com/
 http://ca.linkedin.com/in/davejwarren
 
 Usenet is like a herd of performing elephants with diarrhea --
 massive, difficult to redirect, awe-inspiring, entertaining, and a
 source of mind-boggling amounts of shit when you least expect it.
 
 
 ___
 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


Dynamic update the ip addresses list defined within acl clause

2014-01-28 Thread Pika.Aman
Hi there, 

I would like to ask if there exists any way to dynamic update the ip addresses 
in the list of the ACL clause without reload or re-start the bind server? 
Hoping someone can help me! Thank you!! 

-- 
Pika Aman
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

___
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