Re: Is it possible to use one KSK for multiple domains?
On Wed, Nov 19, 2008 at 09:55:52PM +0100, Adam Tkac [EMAIL PROTECTED] wrote a message of 17 lines which said: If I understand correctly what RFC 4034, section 2.1.1 says ... If bit 7 has value 1, then the DNSKEY record holds a DNS zone key, and the DNSKEY RR's owner name MUST be the name of a zone... it is impossible. Each zone has to have his own KSK and ZSK pair, hasn't it? [Warning: still struggling with the subtleties of KSK/ZSK.] The text you quote is for DNS publication. But you typically do not put KSK in the DNS, no? I would say, quoting Tolkien: one ZSK per zone, but only one KSK to sign them all. [AFNIC manages six TLD so the answer interests us, too.] ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Is it possible to use one KSK for multiple domains?
On Wed, 2008-11-19 at 21:55 +0100, Adam Tkac wrote: does anyone know if is it possible to sign multiple domains with one KSK? Adam, I suspect your question may need to be more specific. Are you asking about the signing process itself, or rather about how certain aspects of this process need to be exposed in the DNS? The RFC-fragment you cite seems to me to require that each signed zone needs its set of [KZ]SK exposed in the DNS, but to be silent on whether a single key can be reused by appearing as RDATA in the DNSKEY RRsets of multiple zones. I haven't read 4033/4034 thoroughly, so it's possible I may have misunderstood completely. Best regards, Niall O'Reilly ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Workaround Solaris's kernel bug
Thomas Schulz wrote: Change 2489 says to define ISC_SOCKET_USE_POLLWATCH to workaround a Solaris kernel bug about /dev/poll. How do I know if I should define this? Should I just assume that if I am running Sloaris 8 then I need to define ISC_SOCKET_USE_POLLWATCH? Is there any down side to defining this if it is not needed? Tom Schulz Applied Dynamics Intl. [EMAIL PROTECTED] ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Tom, This is CR 6724237 http://bugs.opensolaris.org/view_bug.do?bug_id=6724237 Which was first introduced in Solaris 8. At this time there is no patch for Solaris 8, 9 or 10 and therefore ISC_SOCKET_USE_POLLWATCH should be defined when building BIND 9 for those systems. Stacey Marshall Sun Microsystems Ltd. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Zone not propogating to slaves
I am getting on one of my slaves (69.25.129.117) yet on the other I get
the zone to come across from the master. Just a quirk here is that the
.117 slave has to be recycled before the zone comes across yet the .118
comes across when the master is recycle and a change has occurred in one
of the zones. By the way until this zone I have not had problems with
zones coming across to either slave although I have had to do a recycle
to the .117 to get them there.
Anyone know why I am getting this not authoritative message and no
zone file on .118 all of a sudden?
Thanks,
Steve
This is the log message in the 69.25.129.119 Master
client 69.25.129.117#1305: transfer of 'manzanitavacation.com/IN': AXFR
started
client 69.25.129.117#1305: transfer of 'manzanitavacation.com/IN': AXFR
ended
This is the log message in the 69.25.129.118 slave
client 69.25.129.117#1304: received notify for zone
'manzanitavacation.com': not authoritative
This is the log message in the 69.25.129.117 slave
zone manzanitavacation.com/IN: Transfer started.
transfer of 'manzanitavacation.com/IN' from 69.25.129.119#53: connected
using 69.25.129.117#1305
zone manzanitavacation.com/IN: transferred serial 2008111901
transfer of 'manzanitavacation.com/IN' from 69.25.129.119#53: Transfer
completed: 1 messages, 8 records, 251 bytes, 0.109 secs (2302 bytes/sec)
zone manzanitavacation.com/IN: sending notifies (serial 2008111901)
=[1]== named.conf for 69.25.129.117 Slave =
options {
directory C:\WINDOWS\system32\dns\etc\named;
pid-file C:\WINDOWS\system32\dns\etc\named\run\named.pid;
dump-file
C:\WINDOWS\system32\dns\etc\named\dump\named_dump.db;
statistics-file
C:\WINDOWS\system32\dns\etc\named\stats\named.stats;
zone-statistics yes;
forwarders { 63.251.161.33; 216.231.41.2; };
allow-query {any;};
recursion yes;
//allow-recursion {69.25.129.119;};
allow-transfer {69.25.129.119;};
listen-on-v6 { any; };
};
// log to named\log\named.log events from info UP in severity (no debug)
// defaults to use 3 files in rotation
// failure messages up to this point are in the event log
logging{
channel my_log{
file
C:\WINDOWS\system32\dns\etc\named\log\named.log versions 3 size 250k;
severity info;
};
category default{
my_log;
};
};
#
zone manzanitavacation.com. in {
type slave;
file
c:\windows\system32\dns\etc\named\zones\db.manzanitavacation.com.zone;
masters { 69.25.129.119; };
allow-notify {69.25.129.117;69.25.129.118; };
};
=[1]=
=[2]== named.conf for 69.25.129.119 Master =
options {
directory C:\WINDOWS\system32\dns\etc;
dump-file C:\WINDOWS\system32\dns\etc\named\dump\nameddump.db;
statistics-file
C:\WINDOWS\system32\dns\etc\named\stats\named.stats;
pid-file C:\WINDOWS\system32\dns\etc\named\run\named.pid;
recursion yes;
zone-statistics yes;
forwarders { 63.251.161.33 ; 63.251.161.1; };
#forward first;
listen-on-v6 { any; };
dnssec-enable yes;
};
key rndc-key { algorithm hmac-md5; secret ??; };
controls {
inet 127.0.0.1 port 953 allow { localhost; } keys {
rndc-key; };
};
logging{
channel my_log{
file
C:\WINDOWS\system32\dns\etc\named\log\named.log versions 3 size 250k;
severity info;
};
category default{
my_log;
};
};
#
zone manzanitavacation.com. in {
type master;
file
c:\windows\system32\dns\etc\named\zones\manzanitavacation.com.zone;
};
=[3]== named.conf for 69.25.129.118 Slave ==
options {
directory C:\WINDOWS\system32\dns\etc\named;
pid-file C:\WINDOWS\system32\dns\etc\named\run\named.pid;
dump-file
C:\WINDOWS\system32\dns\etc\named\dump\named_dump.db;
statistics-file
C:\WINDOWS\system32\dns\etc\named\stats\named.stats;
zone-statistics yes;
forwarders { 63.251.161.33; 216.231.41.2; };
allow-query {any;};
recursion yes;
//allow-recursion {69.25.129.119;};
allow-transfer {69.25.129.119;};
listen-on-v6 { any; };
};
// log to named\log\named.log events from info UP in severity (no debug)
// defaults to use 3 files in rotation
// failure messages up to this point are in the event log
logging{
channel my_log{
file
C:\WINDOWS\system32\dns\etc\named\log\named.log versions 3 size 250k;
Re: Is it possible to use one KSK for multiple domains?
On Thu, Nov 20, 2008 at 11:55:17AM +, Chris Thompson [EMAIL PROTECTED] wrote a message of 33 lines which said: The text you quote is for DNS publication. But you typically do not put KSK in the DNS, no? Sure you do. How could a validator use it if you didn't? Because it is published as a trust anchor? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Help understanding lame server error
Have you tried looking up the client IP from another line in the logs from the same time? -Original Message- From: Scott Haneda [EMAIL PROTECTED] Date: Thu, 20 Nov 2008 00:45:26 To: BIND Users Mailing Listbind-users@lists.isc.org Subject: Re: Help understanding lame server error On Nov 19, 2008, at 6:19 PM, Kevin Darcy wrote: Scott Haneda wrote: I have a good deal if lame server errors in my logs, which I am not entirely understanding. 19-Nov-2008 15:36:34.657 lame-servers: info: lame server resolving '170.73.234.209.in-addr.arpa' (in '73.234.209.in-addr.arpa'?): 209.234.64.192#53 73.234.209.in-addr.arpa has been delegated to ns1.networkiowa.com (address 209.234.64.192), but that nameserver is not responding authoritatively for the zone. This is referred to technically as being lame. Fortunately one of the other delegated nameservers (storm.weather.net) *is* responding authoritatively. So the zone is not completely broken. But named is logging this as a warning. You can configure logging to ignore these lame-server conditions. Generally I want to know, as there are cases where I mess up, and something bad happens. I watch the logs, and know to fix it. So I am not so much minding the data in my logs, but more just wanting to understand what is causing these lookups. 19-Nov-2008 15:36:34.955 lame-servers: info: lame server resolving '127.52.195.166.in-addr.arpa' (in '52.195.166.in-addr.arpa'?): 209.183.48.20#53 19-Nov-2008 15:36:34.975 lame-servers: info: lame server resolving '221.250.53.206.in-addr.arpa' (in '250.53.206.in-addr.arpa'?): 209.43.20.115#53 19-Nov-2008 15:36:34.989 lame-servers: info: lame server resolving '127.52.195.166.in-addr.arpa' (in '52.195.166.in-addr.arpa'?): 209.183.52.20#53 19-Nov-2008 15:36:35.050 lame-servers: info: lame server resolving '127.52.195.166.in-addr.arpa' (in '52.195.166.in-addr.arpa'?): 209.183.48.21#53 I assume, without looking, that the causes for these are similar to the example above. Yes, I have thousands of these entries. I usually use another NS to point my email server to, that one has become a little flakey, so I moved to using my own local NS on the same machine as the email server. My server is not allowing recursions, other than to localnets. about the only thing hitting it is an email server. So I am not clear on why these lookups are happening, or why they are coming from all these other IP's Most email software these days, as a default, performs reverse- lookups of connecting client addresses as a form of spam detection (because it's common knowledge that spammers are genetically incapable of populating reverse records). It is thus perfectly normal to see a lot of reverse-lookup traffic from email servers. Correct, but that is what is strange. I am very familiar with my email sever, and I am not doing reverse PTR record checking. I am of course using some DNSBL's and DNSWL's as well, but no reverse checking. Further, I have allowed only localnets to check recursively on this NS. I know my IP range, and what machines would be hitting it. BTW, if you want to determine where all of these reverse lookups were coming from, you could just turn on query logging. Why guess when you can tell for sure? This is the core of my question, maybe someone can point me to docs, or help me understand a log line. In the example above, I see field 1 is the date, field 2 is the time, field 3 looks like the error description, field 4 is the level, and then there are the rest of the bits. However, I thought the last part, was an IP and a port, telling me, that IP, asked on port 53, for a lookup of my server. So in this case, why do I need to look at the query log, when I believe, this log tells me who is doing the lookup. If this really was the email server doing this lookup, all the lines should share the same IP in common. So let's assume that for a second, this is a reverse record lookup, that means my email server is asking of my NS for a record/response. Should I not see my IP in those log lines? Here is another example, I think not a reverse lookup for sure: 20-Nov-2008 00:36:38.470 lame-servers: info: lame server resolving 'szi.szi.sv.gov.yu' (in 'szi.sv.gov.yu'?): 195.178.32.2#53 Doesn't that mean that 195.178.32.2 requested a lookup from my NS for szi.szi.sv.gov.yu? I have an email server, and a bunch of web servers, the web servers do not have DNS lookups on, so those are not asking anything of my DNS server. The only thing that should be, is the email server, but that is not adding up, since I do not have reverse lookup checking enabled. I can think of one thing, which is my web stats server, which I would think, does resolve IP's to host names, in order to show a report of what domains are going to websites. That being said, I would think, that I should see the source of the
Re: socket: too many open file descriptors
At Thu, 20 Nov 2008 04:30:00 -0800 (PST), pollex [EMAIL PROTECTED] wrote: 9.3.4-P1.1 still seems to be a Debian specific version, but if this is featurewise equivalent to 9.3.5-P1, you should at least upgrade to 9.3.5-P2 (and build it with a large value of ISC_SOCKET_MAXSOCKETS). In fact, I'd rather more strongly recommend 9.3.6. First off, there was a typo in my previous response: ISC_SOCKET_MAXSOCKETS should have been ISC_SOCKET_FDSETSIZE. how is the exact command line to compile with 4096 FDs? ./configure --ISC_SOCKET_MAXSOCKETS='4096'? Replacing the macro name with the correct one, and assuming you're using a bsh variant such as zsh and bash: % STD_CDEFINES='-DISC_SOCKET_FDSETSIZE=4096' ./configure But again, I'd rather strongly recommend 9.3.6. Then you won't have to care about ISC_SOCKET_MAXSOCKETS or any other annoying details about FD consumption in the first place. There should be no reason for someone considering an upgrade to 9.3.5-P2 not to rather use 9.3.6. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
