Re: Verizon Users Can't See Site

2010-09-14 Thread Torsten
Am Tue, 14 Sep 2010 05:15:16 + (UTC)
schrieb cybers...@comcast.net:

 
 
 
 Hello List, 
 
 
 
 I've run into an issue that has me stumped for the time being. I'm
 working on a website that is hosted on a delegated subdomain. The
 site is www-mbclive.mbc.irides.com. The mbc.irides.com subdomain is
 delegated to two Barracuda load balancers known as
 dns1.mbc.irides.com and dns2.mbc.irides.com. 
 
 
 
 DNS seems to work fine for the majority of our users, however, in the
 past week we've heard from many Verizon FIOS users that they are
 unable to visit the site due to resolution issues. One sent in a dig
 from his home computer and I was wondering why he doesn't receive an
 answer: 
 
 
 
 scott$ dig @71.252.0.12 www-mbclive.mbc.irides.com 
 
 ;  DiG 9.6.0-APPLE-P2  @71.252.0.12
 www-mbclive.mbc.irides.com ; (1 server found) 
 ;; global options: +cmd 
 ;; Got answer: 
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 62184 
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 
 
 ;; QUESTION SECTION: 
 ;www-mbclive.mbc.irides.com.    IN  A 
 
 ;; AUTHORITY SECTION: 
 www-mbclive.mbc.irides.com. 10  IN  SOA dns1.mbc.irides.com.
 1. 3600 3600 3600 3600 3600 
 
 ;; Query time: 20 msec 
 ;; SERVER: 71.252.0.12#53(71.252.0.12) 
 ;; WHEN: Mon Sep 13 21:31:08 2010 
 ;; MSG SIZE  rcvd: 86 
 
 
 
 Can anyone tell if there is a DNS issue on our end that may cause us
 to not play nice w/ Verizon? This issue just popped up in the last
 two weeks. Prior to that time visitors were not complaining. Any
 assistance is greatly appreciated. 
 

I'm having troubles getting an answer from both dns1.mbc.irides.com and
dns2.mbc.irides.com for www-mbclive.mbc.irides.com.

A dig query freezes for about 12 seconds before returning an answer.
Maybe there's a problem with a misconfigured firewall.

[...@localhost ~]$ traceroute -q 1 dns2.mbc.irides.com
traceroute to dns2.mbc.irides.com (209.252.251.240), 30 hops max, 60
byte packets 1  10.43.64.254 (10.43.64.254)  0.336 ms
 2  vl67.cr30.isham.de.easynet.net (194.64.6.252)  0.927 ms
 3  ge1-5.br2.isham.de.easynet.net (194.64.4.126)  0.695 ms
 4  ge3-0-2.gr10.isham.de.easynet.net (87.86.71.244)  0.632 ms
 5  te2-0-0.gr10.ixfra.de.easynet.net (87.86.77.95)  9.862 ms
 6  ge-5-1-4.edge3.frankfurt1.level3.net (212.162.40.77)  9.964 ms
 7  vlan79.csw2.Frankfurt1.Level3.net (4.68.23.126)  18.392 ms
 8  ae-72-72.ebr2.Frankfurt1.Level3.net (4.69.140.21)  10.387 ms
 9  ae-41-41.ebr2.washington1.level3.net (4.69.137.50)  98.620 ms
10  ae-5-5.ebr2.washington12.level3.net (4.69.143.222)  101.159 ms
11  ae-6-6.ebr2.chicago2.level3.net (4.69.148.146)  113.618 ms
12  ae-22-52.car2.chicago2.level3.net (4.69.138.165)  115.322 ms
13  paetec-comm.car2.chicago2.level3.net (4.71.250.34)  115.955 ms
14  gi-3-1-0.core01.chcgil01.paetec.net (66.155.191.97)  139.525 ms
15  po-4-0-0.core02.rochny01.paetec.net (64.80.253.217)  137.915 ms
16  gi-6-0-0.edge02.rochny01.paetec.net (66.155.216.183)  140.368 ms
17  *
18  *
19  *
20  *
21  *
22  *
23  *
24  *
25  *
26  *
27  *
28  *
29  *
30  *



Ciao
Torsten


 
 
 Thanks, 
 
 
 
 Brad
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Timeouts and retries on high speed Lans

2010-09-14 Thread Howard Wilkinson
I have been working on building out a couple of large data centres and
have been struggling with how to set up the systems so that we get a high
resilience, highly responsive DNS service in the presence of failing
equipment.

The configuration we have adopted includes a layer of BIND 9.6.x servers
that act as pure name server caches. We have six of these servers in each
data centre paired to provide service on VIPs so that if one of the pair
fails the other cache takes over.

Our resolv.conf is of the following form.

search xxx.com yyy.com
nameserver 10.1.1.1
nameserver 10.1.2.1
nameserver 10.1.3.1
options timeout:1 attempts:15 no-check-names rotate

The name servers are thus on different networks within the DCs.

Our first problem arises because the timeouts seem to be taken serially on
each server rather than the rotate applying between each name server
request. Is this what I should have expected i.e. a 15 second timeout
before the next server is tried in sequence.

The second problem we face is that even if we could get a one second
timeout this orders of magnitude too slow for names that should be
resolved within our local name space. In other words for lookups within
the xxx.com and yyy.com domains I would like to see timeouts in the
micro-second range.

Thinking further about this problem I have been considering whether the
resolver should be multi-threaded or parallelised in some way so that it
tries all fo the servers at once and accepts the first to respond. I have
come to the conclusion that this would be too difficult to make resilient
in the general use of the resolver code, but would make sense if the
lwresd layer is added to the equation.

Which brings me on to the use of lwresd, this would reduce the incidence
of problems with non-responsive servers in that it would detect and switch
to an alternative server on the first failed attempt. However, this still
means that if lwresd has not detected the down server then we get a stall
in response within the data centre.

So my questions are:

1. Does anybody have any experience in building such systems and
suggestions on how we should tune the clients and servers to make the
system less fragile in the presence of hardware, software and network
failures.

2. Is is possible with lwresd as it is written today to get the effect of
precognition - i.e. can I get lwresd to notice that a server has gone down
or has come back up without it needing to be triggered by a resolv
request.

3. Does anybody know if I can configure lwresd to expect particular zones
to be resolved within very small windows and use this to fail over to the
next server.

And for discussion I wonder if there would be room to add to the resolver
code and or lwresd additional options of the form

options zone-timeout: xxx.com:1usec

or something similar, whereby the resolver could be told that if the cache
does not respond within this time about that particular zone then it can
be assumed that the server is misbehaving.

Thank you for your attention

Regards, Howard.

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


RE: Verizon Users Can't See Site

2010-09-14 Thread Lightner, Jeff
From our ATT based network it works but the individual server digs (dns1  
dns2) were significantly slower than the dig in which I didn't specify a 
server.

$ dig @dns2.mbc.irides.com www-mbclive.mbc.irides.com
;  DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2  @dns2.mbc.irides.com 
www-mbclive.mbc.irides.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 62957
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www-mbclive.mbc.irides.com.IN  A

;; ANSWER SECTION:
www-mbclive.mbc.irides.com. 10  IN  A   216.250.250.131

;; Query time: 52 msec
;; SERVER: 209.252.251.240#53(209.252.251.240)
;; WHEN: Tue Sep 14 07:14:02 2010
;; MSG SIZE  rcvd: 60

(arg: 2) dig @dns1.mbc.irides.com www-mbclive.mbc.irides.com


$ dig @dns1.mbc.irides.com www-mbclive.mbc.irides.com
;  DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2  @dns1.mbc.irides.com 
www-mbclive.mbc.irides.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 5716
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www-mbclive.mbc.irides.com.IN  A

;; ANSWER SECTION:
www-mbclive.mbc.irides.com. 10  IN  A   216.250.250.131

;; Query time: 24 msec
;; SERVER: 216.250.250.136#53(216.250.250.136)
;; WHEN: Tue Sep 14 07:14:31 2010
;; MSG SIZE  rcvd: 60


$ dig www-mbclive.mbc.irides.com
;  DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2  www-mbclive.mbc.irides.com
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 30953
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;www-mbclive.mbc.irides.com.IN  A

;; ANSWER SECTION:
www-mbclive.mbc.irides.com. 10  IN  A   216.250.250.131

;; AUTHORITY SECTION:
mbc.irides.com. 86000   IN  NS  dns2.mbc.irides.com.
mbc.irides.com. 86000   IN  NS  dns1.mbc.irides.com.

;; Query time: 29 msec
;; SERVER: 10.0.4.99#53(10.0.4.99)
;; WHEN: Tue Sep 14 07:14:41 2010
;; MSG SIZE  rcvd: 98

-Original Message-
From: bind-users-bounces+jlightner=water@lists.isc.org 
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of 
Torsten
Sent: Tuesday, September 14, 2010 2:23 AM
To: cybers...@comcast.net
Cc: bind-users@lists.isc.org
Subject: Re: Verizon Users Can't See Site

Am Tue, 14 Sep 2010 05:15:16 + (UTC)
schrieb cybers...@comcast.net:

 
 
 
 Hello List, 
 
 
 
 I've run into an issue that has me stumped for the time being. I'm
 working on a website that is hosted on a delegated subdomain. The
 site is www-mbclive.mbc.irides.com. The mbc.irides.com subdomain is
 delegated to two Barracuda load balancers known as
 dns1.mbc.irides.com and dns2.mbc.irides.com. 
 
 
 
 DNS seems to work fine for the majority of our users, however, in the
 past week we've heard from many Verizon FIOS users that they are
 unable to visit the site due to resolution issues. One sent in a dig
 from his home computer and I was wondering why he doesn't receive an
 answer: 
 
 
 
 scott$ dig @71.252.0.12 www-mbclive.mbc.irides.com 
 
 ;  DiG 9.6.0-APPLE-P2  @71.252.0.12
 www-mbclive.mbc.irides.com ; (1 server found) 
 ;; global options: +cmd 
 ;; Got answer: 
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 62184 
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 
 
 ;; QUESTION SECTION: 
 ;www-mbclive.mbc.irides.com.IN  A 
 
 ;; AUTHORITY SECTION: 
 www-mbclive.mbc.irides.com. 10  IN  SOA dns1.mbc.irides.com.
 1. 3600 3600 3600 3600 3600 
 
 ;; Query time: 20 msec 
 ;; SERVER: 71.252.0.12#53(71.252.0.12) 
 ;; WHEN: Mon Sep 13 21:31:08 2010 
 ;; MSG SIZE  rcvd: 86 
 
 
 
 Can anyone tell if there is a DNS issue on our end that may cause us
 to not play nice w/ Verizon? This issue just popped up in the last
 two weeks. Prior to that time visitors were not complaining. Any
 assistance is greatly appreciated. 
 

I'm having troubles getting an answer from both dns1.mbc.irides.com and
dns2.mbc.irides.com for www-mbclive.mbc.irides.com.

A dig query freezes for about 12 seconds before returning an answer.
Maybe there's a problem with a misconfigured firewall.

[...@localhost ~]$ traceroute -q 1 dns2.mbc.irides.com
traceroute to dns2.mbc.irides.com (209.252.251.240), 30 hops max, 60
byte packets 1  10.43.64.254 (10.43.64.254)  0.336 ms
 2  vl67.cr30.isham.de.easynet.net (194.64.6.252)  0.927 ms
 3  ge1-5.br2.isham.de.easynet.net (194.64.4.126)  0.695 ms
 4  ge3-0-2.gr10.isham.de.easynet.net (87.86.71.244)  0.632 ms
 5  te2-0-0.gr10.ixfra.de.easynet.net (87.86.77.95)  9.862 ms
 6  ge-5-1-4.edge3.frankfurt1.level3.net (212.162.40.77)  9.964 ms
 7  vlan79.csw2.Frankfurt1.Level3.net (4.68.23.126)  18.392 ms
 8  ae-72-72.ebr2.Frankfurt1.Level3.net (4.69.140.21)  10.387 ms
 9  ae-41-41.ebr2.washington1.level3.net (4.69.137.50)  98.620 ms
10  

Re: Timeouts and retries on high speed Lans

2010-09-14 Thread Kalman Feher
So the cache servers are HA behind something (F5 LTM, Cisco local director,
something else). Are the authoritative servers? It would seem sensible to do
the same with them. That way a timeout only occurs if the whole HA cluster
is unavailable.
You can alleviate even that situation by seeding the cache servers every
(TTL-some value) minutes. Or slaving the domain on the cache servers.


On 14/09/10 11:34 AM, Howard Wilkinson how...@cohtech.com wrote:

 I have been working on building out a couple of large data centres and
 have been struggling with how to set up the systems so that we get a high
 resilience, highly responsive DNS service in the presence of failing
 equipment.
 
 The configuration we have adopted includes a layer of BIND 9.6.x servers
 that act as pure name server caches. We have six of these servers in each
 data centre paired to provide service on VIPs so that if one of the pair
 fails the other cache takes over.
 
 Our resolv.conf is of the following form.
 
 search xxx.com yyy.com
 nameserver 10.1.1.1
 nameserver 10.1.2.1
 nameserver 10.1.3.1
 options timeout:1 attempts:15 no-check-names rotate
 
 The name servers are thus on different networks within the DCs.
 
 Our first problem arises because the timeouts seem to be taken serially on
 each server rather than the rotate applying between each name server
 request. Is this what I should have expected i.e. a 15 second timeout
 before the next server is tried in sequence.
 
 The second problem we face is that even if we could get a one second
 timeout this orders of magnitude too slow for names that should be
 resolved within our local name space. In other words for lookups within
 the xxx.com and yyy.com domains I would like to see timeouts in the
 micro-second range.
 
 Thinking further about this problem I have been considering whether the
 resolver should be multi-threaded or parallelised in some way so that it
 tries all fo the servers at once and accepts the first to respond. I have
 come to the conclusion that this would be too difficult to make resilient
 in the general use of the resolver code, but would make sense if the
 lwresd layer is added to the equation.
 
 Which brings me on to the use of lwresd, this would reduce the incidence
 of problems with non-responsive servers in that it would detect and switch
 to an alternative server on the first failed attempt. However, this still
 means that if lwresd has not detected the down server then we get a stall
 in response within the data centre.
 
 So my questions are:
 
 1. Does anybody have any experience in building such systems and
 suggestions on how we should tune the clients and servers to make the
 system less fragile in the presence of hardware, software and network
 failures.
 
 2. Is is possible with lwresd as it is written today to get the effect of
 precognition - i.e. can I get lwresd to notice that a server has gone down
 or has come back up without it needing to be triggered by a resolv
 request.
 
 3. Does anybody know if I can configure lwresd to expect particular zones
 to be resolved within very small windows and use this to fail over to the
 next server.
 
 And for discussion I wonder if there would be room to add to the resolver
 code and or lwresd additional options of the form
 
 options zone-timeout: xxx.com:1usec
 
 or something similar, whereby the resolver could be told that if the cache
 does not respond within this time about that particular zone then it can
 be assumed that the server is misbehaving.
 
 Thank you for your attention
 
 Regards, Howard.
 
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal Feher 

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


Re: Verizon Users Can't See Site

2010-09-14 Thread cyberseal

- Torsten t...@the-damian.de wrote:

 Am Tue, 14 Sep 2010 08:23:03 +0200
 schrieb Torsten t...@the-damian.de:
 
  Am Tue, 14 Sep 2010 05:15:16 + (UTC)
  schrieb cybers...@comcast.net:
  
   
   
   
   Hello List, 
   
   
   
   I've run into an issue that has me stumped for the time being.
 I'm
   working on a website that is hosted on a delegated subdomain. The
   site is www-mbclive.mbc.irides.com. The mbc.irides.com subdomain
 is
   delegated to two Barracuda load balancers known as
   dns1.mbc.irides.com and dns2.mbc.irides.com. 
   
   
   
   DNS seems to work fine for the majority of our users, however, in
   the past week we've heard from many Verizon FIOS users that they
 are
   unable to visit the site due to resolution issues. One sent in a
 dig
   from his home computer and I was wondering why he doesn't receive
 an
   answer: 
   
   
   
   scott$ dig @71.252.0.12 www-mbclive.mbc.irides.com 
   
   ;  DiG 9.6.0-APPLE-P2  @71.252.0.12
   www-mbclive.mbc.irides.com ; (1 server found) 
   ;; global options: +cmd 
   ;; Got answer: 
   ;; -HEADER- opcode: QUERY, status: NOERROR, id: 62184 
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
 ADDITIONAL:
   0 
   
   ;; QUESTION SECTION: 
   ;www-mbclive.mbc.irides.com.    IN  A 
   
   ;; AUTHORITY SECTION: 
   www-mbclive.mbc.irides.com. 10  IN  SOA
 dns1.mbc.irides.com.
   1. 3600 3600 3600 3600 3600 
   
   ;; Query time: 20 msec 
   ;; SERVER: 71.252.0.12#53(71.252.0.12) 
   ;; WHEN: Mon Sep 13 21:31:08 2010 
   ;; MSG SIZE  rcvd: 86 
   
   
   
   Can anyone tell if there is a DNS issue on our end that may cause
 us
   to not play nice w/ Verizon? This issue just popped up in the
 last
   two weeks. Prior to that time visitors were not complaining. Any
   assistance is greatly appreciated. 
   
  
  I'm having troubles getting an answer from both dns1.mbc.irides.com
  and dns2.mbc.irides.com for www-mbclive.mbc.irides.com.
  
  A dig query freezes for about 12 seconds before returning an
 answer.
  Maybe there's a problem with a misconfigured firewall.
  
  [...@localhost ~]$ traceroute -q 1 dns2.mbc.irides.com
  traceroute to dns2.mbc.irides.com (209.252.251.240), 30 hops max,
 60
  byte packets 1  10.43.64.254 (10.43.64.254)  0.336 ms
   2  vl67.cr30.isham.de.easynet.net (194.64.6.252)  0.927 ms
   3  ge1-5.br2.isham.de.easynet.net (194.64.4.126)  0.695 ms
   4  ge3-0-2.gr10.isham.de.easynet.net (87.86.71.244)  0.632 ms
   5  te2-0-0.gr10.ixfra.de.easynet.net (87.86.77.95)  9.862 ms
   6  ge-5-1-4.edge3.frankfurt1.level3.net (212.162.40.77)  9.964 ms
   7  vlan79.csw2.Frankfurt1.Level3.net (4.68.23.126)  18.392 ms
   8  ae-72-72.ebr2.Frankfurt1.Level3.net (4.69.140.21)  10.387 ms
   9  ae-41-41.ebr2.washington1.level3.net (4.69.137.50)  98.620 ms
  10  ae-5-5.ebr2.washington12.level3.net (4.69.143.222)  101.159 ms
  11  ae-6-6.ebr2.chicago2.level3.net (4.69.148.146)  113.618 ms
  12  ae-22-52.car2.chicago2.level3.net (4.69.138.165)  115.322 ms
  13  paetec-comm.car2.chicago2.level3.net (4.71.250.34)  115.955 ms
  14  gi-3-1-0.core01.chcgil01.paetec.net (66.155.191.97)  139.525 ms
  15  po-4-0-0.core02.rochny01.paetec.net (64.80.253.217)  137.915 ms
  16  gi-6-0-0.edge02.rochny01.paetec.net (66.155.216.183)  140.368
 ms
  17  *
  18  *
  19  *
  20  *
  21  *
  22  *
  23  *
  24  *
  25  *
  26  *
  27  *
  28  *
  29  *
  30  *
  
 
 
 I just noticed that the problem might as well be the very short TTL
 of
 the NS A Records of 10 seconds.

Thanks Torsten, the low TTL's have to do with us using the LB's in a failover 
environment between two locations. Today I was given access to a Linux box on 
the Verizon network that is using their DNS server 71.252.0.12, which is 
affected by this problem. Digs and pings to www-mbclive.mbc.irides.com from 
this device fail. What can I do to better test and pinpoint the cause of the 
failure?


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

BIND 9.7.1 + DLZ + DNSSEC: Possible?

2010-09-14 Thread Kevin Mai
Hi, 

My name is Kevin and I'm working with the Argentina ccTLD team to upgrade our 
local NS systems and our goal is to load the .ar, .com.ar and subsequent zones 
using DLZ. Our other task was to deploy DNSSEC here and start signing our TLDs, 
but according to the e-mails I've read (dated 2006 mostly) it's not very clear 
if it's already been possible (it's been 4 years since those e-mails were 
written). 

For that reason, I'd need to know if anyone has deployed DNSSEC and signed 
zones and then stored those RRSIG, NSEC and DNSKEY records on a MySQL backend 
using DLZ as a way to get those entries dinamically. 

I'd really appreciate your replies :) 

Many thanks and have a great afternoon! 

Best Regards, 

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

Re: BIND 9.7.1 + DLZ + DNSSEC: Possible?

2010-09-14 Thread Kevin Mai
We have an average of around 11 QPS but we update zones daily (our servers 
store NS delegations mostly and government sites) so it's a daily task to 
approve new domains and update/reload zones. 

We have a good DB infrastructure built in and the fact of having a MySQL server 
that can replicate is a good reason to have DLZ as the backend. 

The other issue we face is signing the zone files, as we are looking forward to 
harden security and sign the .ar ccTLD and the other TLDs (.com.ar, .mil.ar, 
.gov.ar, net.ar, etc). We can sign zone files, but how do we sign database 
entries? 


De: Scott Haneda talkli...@newgeo.com 
Para: Kevin Mai k...@mrecic.gov.ar 
CC: bind-users@lists.isc.org 
Enviados: Martes, 14 de Septiembre 2010 16:40:05 
Asunto: Re: BIND 9.7.1 + DLZ + DNSSEC: Possible? 


On Sep 14, 2010, at 12:15 PM, Kevin Mai  k...@mrecic.gov.ar  wrote: 






My name is Kevin and I'm working with the Argentina ccTLD team to upgrade our 
local NS systems and our goal is to load the .ar, .com.ar and subsequent zones 
using DLZ. Our other task was to deploy DNSSEC here and start signing our TLDs, 
but according to the e-mails I've read (dated 2006 mostly) it's not very clear 
if it's already been possible (it's been 4 years since those e-mails were 
written). 

For that reason, I'd need to know if anyone has deployed DNSSEC and signed 
zones and then stored those RRSIG, NSEC and DNSKEY records on a MySQL backend 
using DLZ as a way to get those entries dinamically. 

I'd really appreciate your replies :) 


I've been dealing with DLZ systems for the better part of a few years now. 
Unless something has changed I am not aware of in the last 12 months, I can 
offer a few suggestions. 


Make sure you test load. Find the fastest reading DB backend you are 
comfortable with. Then performance test it. The load of a medium to heavy 
system on the database is significant. 


Doing 1000's of DNS lookups per second on a non DLZ system is generally not too 
hard to build out. Doing 1000's of selects on a database, DLZ or not, is 
significantly more challenging. 


Keep in mind, 1 lookup generally is not 1 database lookup in DLZ, but will take 
a few to get the final answer. 


I find DLZ really shines when you are adding and removing domains often and 
need instant access to those changes. If you are not making many changes to 
your records, the performance hit is not worth the ease of records management 
you gained. 


If reloading named starts to take too long, DLZ will come into play. You will 
more than likely want to look at ways of distributing multiple DLZ systems. 


There is a competing product for which I have no experience with. I'm sure you 
can find it in google. I would explore the pros and cons of any alternative 
system as well as BIND/named standalone, and of course a DLZ backed method. 


I have never had to implement signed zones before. If that data is within the 
zone, I see no reason why DLZ would not be able to return the correct response. 
-- 
Scott * If you contact me off list replace talklists@ with scott@ * 

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

RE: DNSSEC, views trusted keys...

2010-09-14 Thread Timothe Litt
This is getting very involved - or I'm getting confused.  Maybe
both :-)

I've tried to work out how this can work, but each solution 
seems to uncover another question.  I don't want to experiment 
to get to seems to work, only to find the next problem much later...

There doesn't seem to be much description of stub zones in the ARM.

I take it that a stub zone will fetch data from the zone using non-
recursive queries, but the view can provide recursive service to
queries zones served elsewhere?

I gather that they contain just an SOA and NS records.  Presumeably
This means I have to create a new set of zone files for the master -
E.g. grep for SOA and self (but not delegating) NS records.  

How are these maintained?  It wouldn't be too bad if the master
stub server would grab SOA  NS changes from the full zone  
propogate them to the primary copy of the stub zone.  But the
full zone is in a different view from the stub...  If this
is to work, these queries would have to be non-recursive for
the match-recursive view selection to support it.

Since we know that the server is authoritative for each zone, it
would seem that the stub should always have a 'masters' clause that 
points itself (even if the non-stub zone is in fact a slave).  
Otherwise there's a good chance that resolving a query would go
across the wire to some other server, ignoring the local data.
But then update-forwarding won't work, will it?

It would be helpful if someone expert in all the interactions could
trace out the flows (where starts, goes, how destination/view selected) for:
   o Initializing the stub zones on the master and their replication to the
slaves
   o Adding or removing a nameserver for the full zone (Specifically, how
this propagates to the stub)
   o A client's recursive query 
   o Dynamic update
   o Zone notifies/refreshes (full and stub)

Sorry if I'm being opaque -- though if we expect DNSSEC to be used, I won't
be the only person trying to get this work!

-
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 

  
-Original Message-
From: Chris Buxton [mailto:chris.p.bux...@gmail.com] 
Sent: Saturday, September 11, 2010 22:41
To: Phil Mayers
Cc: bind-users@lists.isc.org
Subject: Re: DNSSEC, views  trusted keys...


On Sep 11, 2010, at 2:34 AM, Phil Mayers wrote:

 On 09/10/2010 11:12 PM, Timothe Litt wrote:
 
 So it looks like the new (r-internal) view is starting at the root when
it
 resolves -- ignoring what it has data for locally.   It sorta works for
 
 You'll need a:
 
 zone name {
  type forward;
  forward only;
  forwarders {
ips;
  };
 };
 
 It won't automatically detect that another view contains the zone and
redirect it; you have to tell it.

Use a stub zone instead of a forward zone, so that the query will actually
reach the authoritative view. With a forward zone, the query is recursive,
so will be picked up by the recursive view - the view will query itself and
not receive an answer.

zone zone.name {
type stub;
file /path/to/recursive-view-data/zone.name;
masters { 127.0.0.1; }; // or whatever the correct IP is to reach
the internal view };

Chris Buxton
BlueCat Networks



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


Re: BIND 9.7.1 + DLZ + DNSSEC: Possible?

2010-09-14 Thread Kalman Feher
Sign them offline or out of band using a database trigger to initiate the
signing. Your schema might need to change a little though.

For a ccTLD, your private key should probably be secure and offline anyway.
Zone updates should be reasonably automatable using either the BIND dnssec
tools or any of the other toolsets out there.. OpenDNSSEC is the another I¹m
familiar with, but there are more.

Getting that signed zone back into your database is the trick. I¹m not that
familiar with the DLZ backend, but if it can slave a zone from any DNS
server, then you set it up as a secondary to whatever is signing your zones.
If that can¹t be done, you¹ll need to parse the zone file to insert the
records into your live domain table.


On 14/09/10 9:46 PM, Kevin Mai k...@mrecic.gov.ar wrote:

 We have an average of around 11 QPS but we update zones daily (our servers
 store NS delegations mostly and government sites) so it's a daily task to
 approve new domains and update/reload zones.
 
 We have a good DB infrastructure built in and the fact of having a MySQL
 server that can replicate is a good reason to have DLZ as the backend.
 
 The other issue we face is signing the zone files, as we are looking forward
 to harden security and sign the .ar ccTLD and the other TLDs (.com.ar,
 .mil.ar, .gov.ar, net.ar, etc). We can sign zone files, but how do we sign
 database entries?
 
 
 De: Scott Haneda talkli...@newgeo.com
 Para: Kevin Mai k...@mrecic.gov.ar
 CC: bind-users@lists.isc.org
 Enviados: Martes, 14 de Septiembre 2010 16:40:05
 Asunto: Re: BIND 9.7.1 + DLZ + DNSSEC: Possible?
 
 On Sep 14, 2010, at 12:15 PM, Kevin Mai k...@mrecic.gov.ar wrote:
 
 My name is Kevin and I'm working with the Argentina ccTLD team to upgrade our
 local NS systems and our goal is to load the .ar, .com.ar and subsequent
 zones using DLZ. Our other task was to deploy DNSSEC here and start signing
 our TLDs, but according to the e-mails I've read (dated 2006 mostly) it's not
 very clear if it's already been possible (it's been 4 years since those
 e-mails were written).
 
 For that reason, I'd need to know if anyone has deployed DNSSEC and signed
 zones and then stored those RRSIG, NSEC and DNSKEY records on a MySQL backend
 using DLZ as a way to get those entries dinamically.
 
 I'd really appreciate your replies :)
 
 I've been dealing with DLZ systems for the better part of a few years now.
 Unless something has changed I am not aware of in the last 12 months, I can
 offer a few suggestions.
 
 Make sure you test load. Find the fastest reading DB backend you are
 comfortable with. Then performance test it. The load of a medium to heavy
 system on the database is significant.
 
 Doing 1000's of DNS lookups per second on a non DLZ system is generally not
 too hard to build out. Doing 1000's of selects on a database, DLZ or not, is
 significantly more challenging.
 
 Keep in mind, 1 lookup generally is not 1 database lookup in DLZ, but will
 take a few to get the final answer.
 
 I find DLZ really shines when you are adding and removing domains often and
 need instant access to those changes. If you are not making many changes to
 your records, the performance hit is not worth the ease of records management
 you gained. 
 
 If reloading named starts to take too long, DLZ will come into play. You will
 more than likely want to look at ways of distributing multiple DLZ systems.
 
 There is a competing product for which I have no experience with. I'm sure you
 can find it in google. I would explore the pros and cons of any alternative
 system as well as BIND/named standalone, and of course a DLZ backed method.
 
 I have never had to implement signed zones before. If that data is within the
 zone, I see no reason why DLZ would not be able to return the correct
 response. 

-- 
Kal Feher 

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

Re: Verizon Users Can't See Site

2010-09-14 Thread Hauke Lampe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14.09.2010 19:32, cybers...@comcast.net wrote:

 Today I was given access to a Linux box on the Verizon network that is using 
 their DNS server 71.252.0.12, which is affected by this problem.

Your nameserver software is case-sensitive where it should not be:

dig +norec www-mbclive.mbc.irides.com. @216.250.250.136
- - correct answer

dig +norec www-mbclive.mbc.irides.COM. @216.250.250.136
- - NODATA answer

If Verizon's DNS resolvers use 0x20[1] or modify the character case in
any way, they cannot find the right answer.

You should complain to your DNS LB vendor. Their implementation appears
to be too minimalistic.

dig +norec version.bind txt ch @216.250.250.136
;; Question section mismatch: got version.bind/TXT/IN
;; connection timed out; no servers could be reached



Hauke.


[1] Use of Bit 0x20 in DNS Labels to Improve Transaction Identity
http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkyP3pAACgkQKIgAG9lfHFMnlwCfaySh4IgRYz/gxDsRwxdolheH
uNsAoL7VdmEZpSJFXn3eNeS0XLT0oHQJ
=Le9O
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Verizon Users Can't See Site

2010-09-14 Thread cyberseal

- Hauke Lampe la...@hauke-lampe.de wrote:

 On 14.09.2010 19:32, cybers...@comcast.net wrote:
 
  Today I was given access to a Linux box on the Verizon network that
 is using their DNS server 71.252.0.12, which is affected by this
 problem.
 
 Your nameserver software is case-sensitive where it should not be:
 
 dig +norec www-mbclive.mbc.irides.com. @216.250.250.136
 - - correct answer
 
 dig +norec www-mbclive.mbc.irides.COM. @216.250.250.136
 - - NODATA answer
 
 If Verizon's DNS resolvers use 0x20[1] or modify the character case
 in
 any way, they cannot find the right answer.
 
 You should complain to your DNS LB vendor. Their implementation
 appears
 to be too minimalistic.
 
 dig +norec version.bind txt ch @216.250.250.136
 ;; Question section mismatch: got version.bind/TXT/IN
 ;; connection timed out; no servers could be reached

Hauke, my hat's off to you...I think you nailed it...many, many thanks. I will 
buy you a beer and a trip around Nurburgring the next time I'm in Germany!

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


Re: BIND 9.7.1 + DLZ + DNSSEC: Possible?

2010-09-14 Thread Evan Hunt
 
 My name is Kevin and I'm working with the Argentina ccTLD team to upgrade
 our local NS systems and our goal is to load the .ar, .com.ar and
 subsequent zones using DLZ. Our other task was to deploy DNSSEC here and
 start signing our TLDs, but according to the e-mails I've read (dated
 2006 mostly) it's not very clear if it's already been possible (it's been
 4 years since those e-mails were written). 

As far as I know, DLZ has not yet been taught to understand DNSSEC.

I haven't confirmed this personally, but I'll hazard a guess based on
what I've seen of the code.  DLZ might be able to provide normal answers
and RRSIGs when the name exists, but for NXDOMAIN and NOERROR/NODATA
answers, I wouldn't expect it to provide NSEC records correctly in all
cases, and I'm sure it would fail with NSEC3.

If you're planning to use this for a hidden zone master or some such,
where it would only be answering AXFRs, I think it could probably do
that.

Incidentally, BIND 10 can serve authoritative data from a database
back-end; it currently supports SQLite3 and we're planning to add a MySQL
data source driver.  But it won't be ready for production use for
another year or so.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users