Confused about query_source(-v6) address statement

2019-10-18 Thread Robert Senger via bind-users
Hi there,

I found these two inconsistent statements in the net about how bind9's
query_source_(-v6) address statements work: 

From: https://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_15.htm
"Note that query-source applies only to UDP-based queries; TCP-based
queries always choose the source address according to the routing table
and use a random source port."

From: https://www.dns-school.org/Documentation/bind-arm/Bv9ARM.ch06.html
"The address specified in the query-source option is used for both UDP
and TCP queries, but the port applies only to UDP queries. TCP queries
always use a random unprivileged port."

Which one is true? I only neet the source address to be set (both udp
and tcp, for source based routing of dns queries), not the port.

Thanks for clarification,

Robert


-- 
Robert Senger


___
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 ZSK key rollover, why is my zone double signed?

2015-09-07 Thread Robert Senger
Hi Holger,

thanks, I just checked and can confirm your results, everything is fine
now. No manual action done.

But when I look at the dnsviz.net's analysis, I see this

http://dnsviz.net/d/microscopium.de/Ve0Nnw/dnssec/

15 hours ago (analyzed 2015-09-07 04:07:59 UTC), and this

http://dnsviz.net/d/microscopium.de/dnssec/

4 hours ago (analyzed 2015-09-07 15:03:18 UTC).

Your checks at Mon Sep 07 11:50:31 CEST 2015 are in between these two
analyzes.

Doesn't the first analysis show a double signed zone?

However, I'll leave it like it is for now, and see what happens next
week ;)

Thanks again,

Robert



Am Montag, den 07.09.2015, 12:48 +0200 schrieb Holger Zuleger:
> On 05.09.2015 11:53, Robert Senger wrote:
> > Hi all,
> > 
> > I am having trouble with the DNSSEC ZSK rollover for one of my zones.
> > Key rollover for all zones was scheduled at Thursday September 3,
> > 22:00:00 CEST. While everything worked well for most zones, one zone
> > became double signed. Below I've pasted public keys for one good and for
> > the double signed zone, and links to dnsviz.net that show what has
> > happened.
> >
> 
> > Double signed zone:
> > 
> > root@prokyon:/etc/bind# cat Kmicroscopium.de.+008+18903.key 
> > ; This is a zone-signing key, keyid 18903, for microscopium.de.
> > ; Created: 20150827010002 (Thu Aug 27 03:00:02 2015)
> > ; Publish: 2015082718 (Thu Aug 27 20:00:00 2015)
> > ; Activate: 2015082720 (Thu Aug 27 22:00:00 2015)
> > ; Inactive: 2015090320 (Thu Sep  3 22:00:00 2015)
> > ; Delete: 2015091020 (Thu Sep 10 22:00:00 2015)
> > microscopium.de. IN DNSKEY 256 3 8 
> > AwEAAcH+5fi77XDBXYagvneBQNiPGGrohgXXf5t0DY1+rt6GUzBkEIle 
> > QdonDdjWmyHoANUZ/VStOgpZJFGQrp3LxtgtvZZbFq9EfQ4waMWQWY36 
> > pxhDyac1X72dm3Eb+378GnR8SeIT+/NJDOEr9+yWrOd/FEM7le3JJyV5 
> > qQrgP70R9QsMHRbttOJxd0qAHWod/vrY3uegx54i3REVpZwtxS3nhuUl 
> > kqxMbILTFiDV6LpI4bAasTc7Es08vs2op0fy/wT36x0ma2SttgWDOL+e 
> > jLqgWF5qiMYqrXScggPOTTaMiW0rPBKntpqkifl0G56IOOKAkVzqk4ME C3Ve3tBcY0M=
> > root@prokyon:/etc/bind# cat Kmicroscopium.de.+008+03234.key 
> > ; This is a zone-signing key, keyid 3234, for microscopium.de.
> > ; Created: 20150903110745 (Thu Sep  3 13:07:45 2015)
> > ; Publish: 2015090318 (Thu Sep  3 20:00:00 2015)
> > ; Activate: 2015090320 (Thu Sep  3 22:00:00 2015)
> > ; Inactive: 2015091020 (Thu Sep 10 22:00:00 2015)
> > ; Delete: 2015091720 (Thu Sep 17 22:00:00 2015)
> > microscopium.de. IN DNSKEY 256 3 8 
> > AwEAAdT8E9n/mCorGHF4u4GBJnQ+4QzRDXQlhZjCLhRCxNAVWKaaLBYJ 
> > Vzx0uvtc8/W7+wX/Sax/S5EK1ym/74tzXH7q323t8gLEt78ZERHF5zEU 
> > DAvGEa+/Evf/h1M72FLOFjVpAhHfSc3JKfUYi8hrws7kZ4twMsEIepso 
> > dSMfa9N7WpQPkfjIAaY/kSxVcapCvKzmleiSU1Q2hRvduOwfTjE90xxg 
> > OfGzA7C+sCIT09pqtemluzYdOs1NaONrkaUD3ad+InqAne/a8xhnjZfD 
> > Nz57oxaYsffgiMahUVNTzMZukLbn30soRatdGEgEFmYvpSrrgDX3ceu3 3sNSzDhwIKE=
> I'm pretty much sure that this zone is *not* double signed.
> Using dig I'm getting this:
> 
> $ dig +dnssec +multi +nocrypto soa microscopium.de
> 
> ; <<>> DiG 9.11.0pre-alpha <<>> +dnssec +multi +nocrypto soa microscopium.de
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6796
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 1460
> ; COOKIE: c8bb9ae44c57653ceb701b8b55ed5cfb6c8039aa6b918c0e (good)
> ;; QUESTION SECTION:
> ;microscopium.de. IN SOA
> 
> ;; ANSWER SECTION:
> microscopium.de.  3453 IN SOA mydnssec.eu. hostmaster.microscopium.de. (
>   2015082120 ; serial
>   14400  ; refresh (4 hours)
>   3600   ; retry (1 hour)
>   604800 ; expire (1 week)
>   3600   ; minimum (1 hour)
>   )
> microscopium.de.  3453 IN RRSIG SOA 8 2 3600 (
>   20150914082528 20150907072528 3234 
> microscopium.de.
>   [omitted] )
> 
> ;; Query time: 0 msec
> ;; SERVER: 127.0.1.1#53(127.0.1.1)
> ;; WHEN: Mon Sep 07 11:46:35 CEST 2015
> ;; MSG SIZE  rcvd: 433
> 
> 
> So the key used for signing "regular" RR sets is the one with tag 3234.
> 
> 
> $ dig +dnssec +multi +nocrypto dnskey microscopium.de
> 
> ; <<>> DiG 9.11.0pre-alpha <<>> +dnssec +multi +nocrypto dnskey
> microscopium.de
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, 

DNSSEC ZSK key rollover, why is my zone double signed?

2015-09-05 Thread Robert Senger
Hi all,

I am having trouble with the DNSSEC ZSK rollover for one of my zones.
Key rollover for all zones was scheduled at Thursday September 3,
22:00:00 CEST. While everything worked well for most zones, one zone
became double signed. Below I've pasted public keys for one good and for
the double signed zone, and links to dnsviz.net that show what has
happened.


Good zone:

root@prokyon:/etc/bind# cat Kfamilie-senger.net.+008+07938.key 
; This is a zone-signing key, keyid 7938, for familie-senger.net.
; Created: 20150827010022 (Thu Aug 27 03:00:22 2015)
; Publish: 2015082718 (Thu Aug 27 20:00:00 2015)
; Activate: 2015082720 (Thu Aug 27 22:00:00 2015)
; Inactive: 2015090320 (Thu Sep  3 22:00:00 2015)
; Delete: 2015091020 (Thu Sep 10 22:00:00 2015)
familie-senger.net. IN DNSKEY 256 3 8 
AwEAAeANWhUDx4ERwloTfLcfvMfnQzkNUHmr36Nh94RiunIpL3+NNnx/ 
3NFBwcJ+OLvGwuK4ThV25oBeajGzrnaYdRN8y1hGV8fwdp0F9eGDJw0C 
Xddef7YyMtw5ZWG6iPzsHNfaJqsPeyQXtjwMMfqg2KFi2sxhjmzvmUVF 
9qgjArTnCMX2A7ti79Sqcjhkim/Roizj92B8iw9RYix/GIUXvezSzZ7l 
1IBh+EA42UGgGbbWRqBZ3zgX7B0O5DrWflcyT4pAQz//h/T2FPhzvn5G 
BlksjSKIqdHPK+PcxbvvjNpiZ5liQlZdV513dxN30AdF64WyNI10DDK8 fVOyaAf9Zxc=
root@prokyon:/etc/bind# cat Kfamilie-senger.net.+008+00885.key 
; This is a zone-signing key, keyid 885, for familie-senger.net.
; Created: 20150903110815 (Thu Sep  3 13:08:15 2015)
; Publish: 2015090318 (Thu Sep  3 20:00:00 2015)
; Activate: 2015090320 (Thu Sep  3 22:00:00 2015)
; Inactive: 2015091020 (Thu Sep 10 22:00:00 2015)
; Delete: 2015091720 (Thu Sep 17 22:00:00 2015)
familie-senger.net. IN DNSKEY 256 3 8 
AwEAAfAthkzFH24mynoF2FYzf/ezaVpl1h/3JQJyRHUkQTbY6EszhM8d 
dgisbgkXjcd47HcPQMb2cAddQfLUQpcwNpgV6ugvYG7obmPQ4VrQHT5l 
S5S7rUTz2o7S6Af9se0aszxFI9322NAInU4B2tHBj9WiWP/vSLec48i4 
79f5j3kXNZB2uGQV757mc20d9G2xTiP8xmDW2ywvnM8mXFPfCAnCYx0j 
LsmzCG4BSVtWrT9gQJIvbeM7ODHZgUAEAhfHhtcYQpD58miTkUFD8nDp 
/iAu3FTq9AlyoJmAqD4HhYNZsSWdzUCJBxsl7+xi+Ts12yXLeRKk3NKd gVqr7IUcmSE=

See dnsviz: http://dnsviz.net/d/familie-senger.net/dnssec/



Double signed zone:

root@prokyon:/etc/bind# cat Kmicroscopium.de.+008+18903.key 
; This is a zone-signing key, keyid 18903, for microscopium.de.
; Created: 20150827010002 (Thu Aug 27 03:00:02 2015)
; Publish: 2015082718 (Thu Aug 27 20:00:00 2015)
; Activate: 2015082720 (Thu Aug 27 22:00:00 2015)
; Inactive: 2015090320 (Thu Sep  3 22:00:00 2015)
; Delete: 2015091020 (Thu Sep 10 22:00:00 2015)
microscopium.de. IN DNSKEY 256 3 8 
AwEAAcH+5fi77XDBXYagvneBQNiPGGrohgXXf5t0DY1+rt6GUzBkEIle 
QdonDdjWmyHoANUZ/VStOgpZJFGQrp3LxtgtvZZbFq9EfQ4waMWQWY36 
pxhDyac1X72dm3Eb+378GnR8SeIT+/NJDOEr9+yWrOd/FEM7le3JJyV5 
qQrgP70R9QsMHRbttOJxd0qAHWod/vrY3uegx54i3REVpZwtxS3nhuUl 
kqxMbILTFiDV6LpI4bAasTc7Es08vs2op0fy/wT36x0ma2SttgWDOL+e 
jLqgWF5qiMYqrXScggPOTTaMiW0rPBKntpqkifl0G56IOOKAkVzqk4ME C3Ve3tBcY0M=
root@prokyon:/etc/bind# cat Kmicroscopium.de.+008+03234.key 
; This is a zone-signing key, keyid 3234, for microscopium.de.
; Created: 20150903110745 (Thu Sep  3 13:07:45 2015)
; Publish: 2015090318 (Thu Sep  3 20:00:00 2015)
; Activate: 2015090320 (Thu Sep  3 22:00:00 2015)
; Inactive: 2015091020 (Thu Sep 10 22:00:00 2015)
; Delete: 2015091720 (Thu Sep 17 22:00:00 2015)
microscopium.de. IN DNSKEY 256 3 8 
AwEAAdT8E9n/mCorGHF4u4GBJnQ+4QzRDXQlhZjCLhRCxNAVWKaaLBYJ 
Vzx0uvtc8/W7+wX/Sax/S5EK1ym/74tzXH7q323t8gLEt78ZERHF5zEU 
DAvGEa+/Evf/h1M72FLOFjVpAhHfSc3JKfUYi8hrws7kZ4twMsEIepso 
dSMfa9N7WpQPkfjIAaY/kSxVcapCvKzmleiSU1Q2hRvduOwfTjE90xxg 
OfGzA7C+sCIT09pqtemluzYdOs1NaONrkaUD3ad+InqAne/a8xhnjZfD 
Nz57oxaYsffgiMahUVNTzMZukLbn30soRatdGEgEFmYvpSrrgDX3ceu3 3sNSzDhwIKE=

See dnsviz: http://dnsviz.net/d/microscopium.de/dnssec/


For both zones, the old key (top) became inactive on Sep 3 22:00:00, and
the new key (bottom) took over. After a few days, all (at least those
checked y dnssviz.net) RRs were signed by the new key, with the old
signature removed. But in the zone that became double signed, the old
key's signatures for the RRs weren't removed. Why? 

Everything is configured identically for both zones, an I can't see any
reason why one zone became double signed. I've never triggered manual
signing for any zone.

Any hints what might have happened here? If you need more information,
let me know (the logs only show not very helpful information).

Cheers, 

Robert


-- 
Robert Senger


___
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 ZSK rollover

2015-08-29 Thread Robert Senger
Thanks, that's what I wanted to know. I'll leave it like it is now.

Robert 


Am Freitag, den 28.08.2015, 21:24 + schrieb Evan Hunt:
> On Fri, Aug 28, 2015 at 07:24:23PM +0200, Robert Senger wrote:
> > Is that the intended behaviour, or do I miss a point to get the zones
> > resigned in one single action (and transfered with one single IXFR)
> > rather than getting each RR resigned separately?
> 
> It is intentional; it spreads out the work of resigning over a longer
> period of time to reduce the load on the server. (And a lot of people
> prefer smaller IXFRs anyway.)
> 
> You can adjust the resigning interval, or force a full resign with
> "rndc sign".
> 

-- 
Robert Senger


___
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


DNSSEC ZSK rollover

2015-08-28 Thread Robert Senger
Hi all,

after upgrading from Debian Wheezy to Jessie, the dnssec-tools package
(including rollerd for automatic ZSK key rollover) is no longer
available.

So I've set up bind9 to do the signing:

zone "mydomain.de" in
{   
  
 type master;
 auto-dnssec maintain;
 inline-signing yes;
 file "/etc/bind/zone.external.de.mydomain";
 allow-transfer { key my-transfer-key; };
};  


I added the required timing information to the ZSKs (P/A/I/D), and set
up a cron run script that generates the new keys for prepublication when
it's time.

It almost works as expected, but unlike ZSK rollover with rollerd, zones
are not completely resigned with the new ZSK upon it's activation.
Instead, every RR is resigned at separate times. It takes about a day or
so until all RR are signed with the new ZSK. The old ZSK is still
published in the zone, so there are no DNSSEC failures. 

But this behaviour results in an IXFR zone transfer to the secondary
nameservers every time a RR is resigned. 

Is that the intended behaviour, or do I miss a point to get the zones
resigned in one single action (and transfered with one single IXFR)
rather than getting each RR resigned separately?

Cheers,

Robert  

-- 
Robert Senger


___
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: Identify source of "rndc reconfig" command?

2015-08-28 Thread Robert Senger
Thank you all for your help! I found that the reconfig command was
called by a script executed by wide-dhcpv6-client. In wheezy, this
script was called once when the ipv6 address of the public ppp interface
changed, in Jessie it was called every 30 minutes for whatever reason.
Fixed that.

Cheers,

Robert

Am Montag, den 24.08.2015, 23:01 +0200 schrieb Robert Senger:
> Hi all,
> 
> after upgrading from Debian Wheezy to Jessie, bind9 receives "rndc
> reconfig" commands every 30 minutes. I've never seen this before. Some
> of my own scripts run "rndc restart/reload" after fiddling with network
> interfaces, but none of these is the source of the observed 30 minutes
> interval. There are also no cron jobs.
> 
> In the bind9 logs I see this:
> 
> 24-Aug-2015 22:53:43.431 general: info: received control channel command 
> 'reconfig'
> 24-Aug-2015 22:53:43.458 general: info: loading configuration from 
> '/etc/bind/named.conf'
> ... [more than 350 lines reconfig log]
> 
> Running tcpdump on the lo interface gives me this:
> 
> root@prokyon:/etc/bind# tcpdump -i lo port 953
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
> 21:23:35.071602 IP localhost.48466 > localhost.953: Flags [S], seq 
> 3862717043, win 43690, options [mss 65495,sackOK,TS val 196635776 ecr 
> 0,nop,wscale 5], length 0
> 21:23:35.071699 IP localhost.953 > localhost.48466: Flags [S.], seq 
> 2391140312, ack 3862717044, win 43690, options [mss 65495,sackOK,TS val 
> 196635776 ecr 196635776,nop,wscale 5], length 0
> 21:23:35.071821 IP localhost.48466 > localhost.953: Flags [.], ack 1, win 
> 1366, options [nop,nop,TS val 196635776 ecr 196635776], length 0
> 21:23:35.075355 IP localhost.48466 > localhost.953: Flags [P.], seq 1:148, 
> ack 1, win 1366, options [nop,nop,TS val 196635777 ecr 196635776], length 147
> 21:23:35.075435 IP localhost.953 > localhost.48466: Flags [.], ack 148, win 
> 1399, options [nop,nop,TS val 196635777 ecr 196635777], length 0
> 21:23:35.115513 IP localhost.953 > localhost.48466: Flags [P.], seq 1:180, 
> ack 148, win 1399, options [nop,nop,TS val 196635787 ecr 196635777], length 
> 179
> 21:23:35.115583 IP localhost.48466 > localhost.953: Flags [.], ack 180, win 
> 1399, options [nop,nop,TS val 196635787 ecr 196635787], length 0
> 21:23:35.116084 IP localhost.48466 > localhost.953: Flags [P.], seq 148:320, 
> ack 180, win 1399, options [nop,nop,TS val 196635787 ecr 196635787], length 
> 172
> 21:23:35.116130 IP localhost.953 > localhost.48466: Flags [.], ack 320, win 
> 1433, options [nop,nop,TS val 196635787 ecr 196635787], length 0
> 21:23:37.092444 IP localhost.953 > localhost.48466: Flags [P.], seq 180:363, 
> ack 320, win 1433, options [nop,nop,TS val 196636281 ecr 196635787], length 
> 183
> 21:23:37.094097 IP localhost.48466 > localhost.953: Flags [F.], seq 320, ack 
> 363, win 1433, options [nop,nop,TS val 196636281 ecr 196636281], length 0
> 21:23:37.130367 IP localhost.953 > localhost.48466: Flags [.], ack 321, win 
> 1433, options [nop,nop,TS val 196636291 ecr 196636281], length 0
> 21:23:37.829134 IP localhost.953 > localhost.48466: Flags [F.], seq 363, ack 
> 321, win 1433, options [nop,nop,TS val 196636465 ecr 196636281], length 0
> 21:23:37.829288 IP localhost.48466 > localhost.953: Flags [.], ack 364, win 
> 1433, options [nop,nop,TS val 196636465 ecr 196636465], length 0
> 
> Is there a way to identify the source of these reconfig commands? It's
> really annoying as it messes up the log with 350 useless lines every 30
> minutes.
> 
> Thanks!
> 
> Robert
>  
> 

-- 
Robert Senger


___
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


Identify source of "rndc reconfig" command?

2015-08-24 Thread Robert Senger
Hi all,

after upgrading from Debian Wheezy to Jessie, bind9 receives "rndc
reconfig" commands every 30 minutes. I've never seen this before. Some
of my own scripts run "rndc restart/reload" after fiddling with network
interfaces, but none of these is the source of the observed 30 minutes
interval. There are also no cron jobs.

In the bind9 logs I see this:

24-Aug-2015 22:53:43.431 general: info: received control channel command 
'reconfig'
24-Aug-2015 22:53:43.458 general: info: loading configuration from 
'/etc/bind/named.conf'
... [more than 350 lines reconfig log]

Running tcpdump on the lo interface gives me this:

root@prokyon:/etc/bind# tcpdump -i lo port 953
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
21:23:35.071602 IP localhost.48466 > localhost.953: Flags [S], seq 3862717043, 
win 43690, options [mss 65495,sackOK,TS val 196635776 ecr 0,nop,wscale 5], 
length 0
21:23:35.071699 IP localhost.953 > localhost.48466: Flags [S.], seq 2391140312, 
ack 3862717044, win 43690, options [mss 65495,sackOK,TS val 196635776 ecr 
196635776,nop,wscale 5], length 0
21:23:35.071821 IP localhost.48466 > localhost.953: Flags [.], ack 1, win 1366, 
options [nop,nop,TS val 196635776 ecr 196635776], length 0
21:23:35.075355 IP localhost.48466 > localhost.953: Flags [P.], seq 1:148, ack 
1, win 1366, options [nop,nop,TS val 196635777 ecr 196635776], length 147
21:23:35.075435 IP localhost.953 > localhost.48466: Flags [.], ack 148, win 
1399, options [nop,nop,TS val 196635777 ecr 196635777], length 0
21:23:35.115513 IP localhost.953 > localhost.48466: Flags [P.], seq 1:180, ack 
148, win 1399, options [nop,nop,TS val 196635787 ecr 196635777], length 179
21:23:35.115583 IP localhost.48466 > localhost.953: Flags [.], ack 180, win 
1399, options [nop,nop,TS val 196635787 ecr 196635787], length 0
21:23:35.116084 IP localhost.48466 > localhost.953: Flags [P.], seq 148:320, 
ack 180, win 1399, options [nop,nop,TS val 196635787 ecr 196635787], length 172
21:23:35.116130 IP localhost.953 > localhost.48466: Flags [.], ack 320, win 
1433, options [nop,nop,TS val 196635787 ecr 196635787], length 0
21:23:37.092444 IP localhost.953 > localhost.48466: Flags [P.], seq 180:363, 
ack 320, win 1433, options [nop,nop,TS val 196636281 ecr 196635787], length 183
21:23:37.094097 IP localhost.48466 > localhost.953: Flags [F.], seq 320, ack 
363, win 1433, options [nop,nop,TS val 196636281 ecr 196636281], length 0
21:23:37.130367 IP localhost.953 > localhost.48466: Flags [.], ack 321, win 
1433, options [nop,nop,TS val 196636291 ecr 196636281], length 0
21:23:37.829134 IP localhost.953 > localhost.48466: Flags [F.], seq 363, ack 
321, win 1433, options [nop,nop,TS val 196636465 ecr 196636281], length 0
21:23:37.829288 IP localhost.48466 > localhost.953: Flags [.], ack 364, win 
1433, options [nop,nop,TS val 196636465 ecr 196636465], length 0

Is there a way to identify the source of these reconfig commands? It's
really annoying as it messes up the log with 350 useless lines every 30
minutes.

Thanks!

Robert
 

-- 
Robert Senger


___
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 run two name servers on one host with two IP addresses?

2015-08-20 Thread Robert Senger
There are a number of providers out there offering secondary dns
services for free or for a few bucks/month. Even DNSSEC is possible for
free.


Am Mittwoch, den 19.08.2015, 17:53 -0500 schrieb Tom Browder:
> I have a single server with access to several IP addresses from my
> dedicated host provider.  They do not provide DNS service so I
> currently use my domain registrar.
> 
> I would like  to run my own DNS server but I only have the one server
> (with 5 IP addresses).  Is it possible (and permitted) to run DNS with
> just one real server?
> 
> Thanks.
> 
> Best regards,
> 
> -Tom
> ___
> 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

-- 
Robert Senger


___
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: dynamic update of split view acl

2015-02-28 Thread Robert Senger
Hi Matt,

in my understanding, "rndc reload  in " reloads the zone
file only, not the configuration where the "matched-clients { }"
statement is listed. So, you'll have to run a full config reload if you
change the "matched-clients { }" list.

I just wonder why you want to move a client's ip from one view to the
other?

Cheers,
 
Robert

 Am Samstag, den 28.02.2015, 04:27 -0800 schrieb Matt Calder:
> .57.0.0/24 is still matched
> by view1. Is there any way to accomplish this?

-- 
Robert Senger 
PGP/GPG Public Key ID: 24E78B5E


signature.asc
Description: This is a digitally signed message part
___
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

DNSSEC: validation with "dnssec-must-be-secure" AND "dnssec-lookaside" fails

2015-02-26 Thread Robert Senger
Hi all,

I am struggling with weird behaviour of bind9 acting as authenticating
resolver, when querying DNSSEC enabled domains that are using DLV. My
registrar is still unable to sign DS records.

Everything works fine if only "dnssec-lookaside auto" option is set in
the resolver's named.conf.options file. When running "dig +dnssec
domain.tld", I get a correct answer with the "ad" flag set.

But after enabling "dnssec-must-be-secure domain.tld", the lookup fails
with lots of error messages in the log saying DNSKEY lookup failed for
domain.tld.

Then I added the domain.tld's key (the KSK) into the named.conf.options
file, in a "trusted-keys" section. Then, the lookups succeed again, with
"ad" flag set.

I wonder what happens here.

Can it be the case, that DLV generally works, but not for domains listed
in "dnssec-must-be-secure" statements?

I am running bind 9.8.4 on Debian.

Cheers,

Robert


-- 
Robert Senger 
PGP/GPG Public Key ID: 24E78B5E


signature.asc
Description: This is a digitally signed message part
___
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