date:20180423

Re: Administrivia.

2018-04-23 Thread Ray Bellis

On 23/04/2018 16:34, Chris Thompson wrote:

> To further increase our Schadenfreude, please do let the list know just
> how ISC managed to let that happen! Or will you be able to blame ARIN?

We're blaming ARIN :p

149.20/16 was previously delegated to us with its own DNSKEY / DS, and
then we used a separate DNSKEY / DS for the indivdual child /24's below
that.

The /16 got split (by ARIN) into individual /24 delegations, and they
copied the existing DS that covered the /16 into the new records...

Ray
___
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: Administrivia.

2018-04-23 Thread Chris Thompson


On Apr 23 2018, Ray Bellis wrote:


On 23/04/2018 14:18, Anand Buddhdev wrote:


If you repeat your query with the +cd option, you'll get a response.

DNSViz shows problems with the DNSSEC setup of this zone. The DS and
DNSKEY records don't match:

http://dnsviz.net/d/1.20.149.in-addr.arpa/dnssec/


Thanks for the heads up - I'll make sure our Ops team is aware.


To further increase our Schadenfreude, please do let the list know just
how ISC managed to let that happen! Or will you be able to blame ARIN?

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Administrivia.

2018-04-23 Thread Ray Bellis

On 23/04/2018 14:18, Anand Buddhdev wrote:

> If you repeat your query with the +cd option, you'll get a response.
> 
> DNSViz shows problems with the DNSSEC setup of this zone. The DS and
> DNSKEY records don't match:
> 
> http://dnsviz.net/d/1.20.149.in-addr.arpa/dnssec/

Thanks for the heads up - I'll make sure our Ops team is aware.

Ray

___
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: sporadic timeouts querying bind9

2018-04-23 Thread Klaus Darilion

This time with log file attached
Thanks
Klaus


Am 23.04.2018 um 14:55 schrieb Klaus Darilion via bind-users:
> Hi all!
> 
> Upgrading to Ubuntu 16.04 with Bind 9.10.3 did not solved the problem.
> 
> I enabled debug log (trace 2) and query logging. Unless my monitoring
> traffic (~20 Queries every second) the server is idle.
> 
> The server is a xen domU (on a idle hypervisor) with 4 vCPUs and 20G RAM.
> 
> Here the logs from my checker script:
> Apr 23 10:35:17 tld-all-tst1 darilion: OK:
> Apr 23 10:35:18 tld-all-tst1 darilion: OK:
> Apr 23 10:35:24 tld-all-tst1 darilion: FAILED - timeout (3 sec) or
> network error querying SOA for hu
> Apr 23 10:35:31 tld-all-tst1 darilion: FAILED - timeout (3 sec) or
> network error querying SOA for hu
> Apr 23 10:35:32 tld-all-tst1 darilion: OK:
> Apr 23 10:35:33 tld-all-tst1 darilion: OK:
> 
> Hence, no responses from Bind between 10:35:18 and 10:35:32
> 
> The debug log during this time is attached. It seems Bind hangs from
> 10:35:19.126 to 10:35:30.036, maybe at the end of writing the zone file.
> The zone file is around 2.2G.
> 
> The query log also show nothing during this time:
> 23-Apr-2018 10:35:18.760 queries: info: client 127.0.0.1#54902 (at):
> query: at IN SOA - (83.136.32.84)
> 23-Apr-2018 10:35:30.037 queries: info: client 127.0.0.1#53148 (hu):
> query: hu IN SOA - (83.136.32.84)
> 
> Continuous Write performance of the disk is ~130MB/s. To me it seems
> that Bind is somehow blocked at the end of the zone dump and hence not
> answering queries anymore.
> 
> May this be possible? Is somewhere documented how Bind as slave applies
> the incoming IXFR to the loaded zone, the journal  Are there any
> locking operations in bind?
> 
> Thanks
> Klaus
> 
> 
> 
> 
> 
> 
> 
> Am 15.03.2018 um 14:45 schrieb Klaus Darilion:
>> Hi!
>>
>> I use bind 9.9.5.dfsg-3ubuntu0.17 with around 20 slave zones (from small
>> to huge).
>>
>> I query the SOA of every configured zone once a second to monitor bind.
>>
>> Once a day my script reports timeouts (3 seconds) querying a SOA. This
>> server is a test server, hence it is idle except the monitoring checks.
>>
>> When inspecting the logs the timeouts are always very close to NOTIFYs
>> and zone transfers. Are there any known issues that e.g. bind may
>> suspend queries wile applying the zone transfer? Any other ideas what
>> could be the reason?
>>
>> Thanks
>> Klaus
>> ___
>> 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
> 
23-Apr-2018 10:34:54.954 general: debug 1: zone_timer: zone si/IN: enter
23-Apr-2018 10:34:54.954 general: debug 1: zone_maintenance: zone si/IN: enter
23-Apr-2018 10:34:54.954 general: debug 1: queue_soa_query: zone si/IN: enter
23-Apr-2018 10:34:54.954 general: debug 1: zone_settimer: zone si/IN: enter
23-Apr-2018 10:34:54.954 general: debug 1: soa_query: zone si/IN: enter
23-Apr-2018 10:34:54.956 general: debug 1: refresh_callback: zone si/IN: enter
23-Apr-2018 10:34:54.956 general: debug 1: refresh_callback: zone si/IN: 
serial: new 1524474022, old 1524474022
23-Apr-2018 10:34:54.956 general: debug 1: queue_soa_query: zone si/IN: enter
23-Apr-2018 10:34:55.455 general: debug 1: soa_query: zone si/IN: enter
23-Apr-2018 10:34:55.463 general: debug 1: refresh_callback: zone si/IN: enter
23-Apr-2018 10:34:55.463 general: debug 1: refresh_callback: zone si/IN: 
serial: new 1524474022, old 1524474022
23-Apr-2018 10:34:55.463 general: debug 1: queue_soa_query: zone si/IN: enter
23-Apr-2018 10:34:55.463 general: debug 1: soa_query: zone si/IN: enter
23-Apr-2018 10:34:55.464 general: debug 1: refresh_callback: zone si/IN: enter
23-Apr-2018 10:34:55.465 general: debug 1: refresh_callback: zone si/IN: 
serial: new 1524474022, old 1524474022
23-Apr-2018 10:34:55.465 general: debug 1: queue_soa_query: zone si/IN: enter
23-Apr-2018 10:34:55.963 general: debug 1: soa_query: zone si/IN: enter
23-Apr-2018 10:34:55.971 general: debug 1: refresh_callback: zone si/IN: enter
23-Apr-2018 10:34:55.971 general: debug 1: refresh_callback: zone si/IN: 
serial: new 1524474022, old 1524474022
23-Apr-2018 10:34:55.972 general: debug 1: zone_settimer: zone si/IN: enter
23-Apr-2018 10:35:01.608 general: debug 1: zone_timer: zone nl/IN: enter
23-Apr-2018 10:35:01.608 general: debug 1: zone_maintenance: zone nl/IN: enter
23-Apr-2018 10:35:01.609 general: debug 1: zone_dump: zone nl/IN: enter
23-Apr-2018 10:35:01.609 general: debug 1: zone_settimer: zone nl/IN: enter
23-Apr-2018 10:35:01.609 general: debug 1: zone_gotwritehandle: zone nl/IN: 
enter
23-Apr-2018 10:35:01.609

Re: Administrivia.

2018-04-23 Thread Anand Buddhdev

On 23/04/2018 15:02, G.W. Haywood via bind-users wrote:

> Below is from our own DNS server; I get the same response from all the
> public servers that I've tried.
> 
> 8<--
> mail6:~$ >>> dig -x 149.20.1.60
> 
> ; <<>> DiG 9.9.5-9+deb8u14-Debian <<>> -x 149.20.1.60
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26391
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

If you repeat your query with the +cd option, you'll get a response.

DNSViz shows problems with the DNSSEC setup of this zone. The DS and
DNSKEY records don't match:

http://dnsviz.net/d/1.20.149.in-addr.arpa/dnssec/

Regards,
Anand
___
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

Administrivia.

2018-04-23 Thread G.W. Haywood via bind-users


Hi there,

It looks like something has recently changed in the ISC DNS.

8<--
Apr 20 09:00:36 mail6 sm-mta[20203]: NOQUEUE: connect from lists.isc.org 
[149.20.1.60]
Apr 20 13:00:22 mail6 sm-mta[29448]: NOQUEUE: connect from lists.isc.org 
[149.20.1.60]
Apr 21 13:00:15 mail6 sm-mta[28060]: NOQUEUE: connect from lists.isc.org 
[149.20.1.60]
Apr 22 13:00:10 mail6 sm-mta[30898]: NOQUEUE: connect from [149.20.1.60]
Apr 22 13:09:26 mail6 sm-mta[31397]: NOQUEUE: connect from [149.20.1.60]
Apr 22 13:24:27 mail6 sm-mta[32126]: NOQUEUE: connect from [149.20.1.60]
8<--

Our picky servers started blocking list mail.  Thinking it might right
itself, at first I ignored it.  Then I tweaked some filtering rules to
let list messages through.

Below is from our own DNS server; I get the same response from all the
public servers that I've tried.

8<--
mail6:~$ >>> dig -x 149.20.1.60

; <<>> DiG 9.9.5-9+deb8u14-Debian <<>> -x 149.20.1.60
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26391
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;60.1.20.149.in-addr.arpa.  IN  PTR
[...]
8<--

No problem as far as I'm concerned, I just hope whoever needs to know
about this knows about this (and that I haven't missed something. :)

--

73,
Ged.
___
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: sporadic timeouts querying bind9

2018-04-23 Thread Klaus Darilion via bind-users

Hi all!

Upgrading to Ubuntu 16.04 with Bind 9.10.3 did not solved the problem.

I enabled debug log (trace 2) and query logging. Unless my monitoring
traffic (~20 Queries every second) the server is idle.

The server is a xen domU (on a idle hypervisor) with 4 vCPUs and 20G RAM.

Here the logs from my checker script:
Apr 23 10:35:17 tld-all-tst1 darilion: OK:
Apr 23 10:35:18 tld-all-tst1 darilion: OK:
Apr 23 10:35:24 tld-all-tst1 darilion: FAILED - timeout (3 sec) or
network error querying SOA for hu
Apr 23 10:35:31 tld-all-tst1 darilion: FAILED - timeout (3 sec) or
network error querying SOA for hu
Apr 23 10:35:32 tld-all-tst1 darilion: OK:
Apr 23 10:35:33 tld-all-tst1 darilion: OK:

Hence, no responses from Bind between 10:35:18 and 10:35:32

The debug log during this time is attached. It seems Bind hangs from
10:35:19.126 to 10:35:30.036, maybe at the end of writing the zone file.
The zone file is around 2.2G.

The query log also show nothing during this time:
23-Apr-2018 10:35:18.760 queries: info: client 127.0.0.1#54902 (at):
query: at IN SOA - (83.136.32.84)
23-Apr-2018 10:35:30.037 queries: info: client 127.0.0.1#53148 (hu):
query: hu IN SOA - (83.136.32.84)

Continuous Write performance of the disk is ~130MB/s. To me it seems
that Bind is somehow blocked at the end of the zone dump and hence not
answering queries anymore.

May this be possible? Is somewhere documented how Bind as slave applies
the incoming IXFR to the loaded zone, the journal  Are there any
locking operations in bind?

Thanks
Klaus







Am 15.03.2018 um 14:45 schrieb Klaus Darilion:
> Hi!
> 
> I use bind 9.9.5.dfsg-3ubuntu0.17 with around 20 slave zones (from small
> to huge).
> 
> I query the SOA of every configured zone once a second to monitor bind.
> 
> Once a day my script reports timeouts (3 seconds) querying a SOA. This
> server is a test server, hence it is idle except the monitoring checks.
> 
> When inspecting the logs the timeouts are always very close to NOTIFYs
> and zone transfers. Are there any known issues that e.g. bind may
> suspend queries wile applying the zone transfer? Any other ideas what
> could be the reason?
> 
> Thanks
> Klaus
> ___
> 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

Limit Wildcard Entry with RPZ?

2018-04-23 Thread Stelzner, Tore

Hello,
a department would like to use the application Sandstorm. This application 
needs a wildcard DNS entry. But with this every hostname would get an IP 
address, even such an entry as "we-dont-like-to-work-here". It seems to be 
possible to set a prefix to the random hostname created by Sandstorm (like 
"sandstorm-*").

And now to my questions:
- Would it be possible to limit the possible hostnames to something like 
"sandstorm-[a-z0-9]{32}.department.tu-darmstadt.de" with a RPZ rule?
- Would DNSSEC still be possible?

Even so I read a lot about RPZ in this mailinglist I never used it myself so 
far. But I will start my investigation now.
Thank you, Tore

-- 
Tore Stelzner
Technische Universität Darmstadt, Kommunikationssysteme
Hochschulrechenzentrum, Hochschulstr. 1, 64289 Darmstadt
Tel. +49 6151 16-71037, Fax +49 6151 16-71188, http://www.hrz.tu-darmstadt.de

___
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: Administrivia.

Re: Administrivia.

Re: Administrivia.

Re: sporadic timeouts querying bind9

Re: Administrivia.

Administrivia.

Re: sporadic timeouts querying bind9

Limit Wildcard Entry with RPZ?

8 matches

Site Navigation

Mail list logo

Footer information