Re: CARP+Pfsync+Bind
On Thu, 6 Oct 2005 22:15:25 +0100 ed [EMAIL PROTECTED] wrote: Works fine on on the 2 domains where it's been implemented, of which I handled the conversion from BIND style to djbdns. No problems on UDP lookups alone, including some deep CNAMEs, which are just not required, but I'll deal with those at a later date. I haven't seen any problems since the change. Lookup times have improved, I can't state if this is due to the lack of TCP or the file system overheads with zone files, but I expect a mixture of the two. If you look at netstat on your tinydns boxes you'll notice that something is listening on tcp/53. That something is dnscache so you should allow tcp/53 in to your dns caches. --- Lars Hansson
Re: CARP+Pfsync+Bind
Quoting ed [EMAIL PROTECTED]: Zone transfers are on tcp/53, DNS lookups are 53/udp, so: pass in on $ext_if proto udp from any to $DNS port 53 keep state and if required: pass in on $ext_if proto tcp from $ext_net to $DNS port 53 keep state I use TinyDNS here, so we don't really need to transfer zones as its handled with a single data file. CARP can be good with DNS. Ok. This 2 servers DNS masters. But if the one server will master(CARP master,not dns) and other CARP slave, zones sends only from CARP master and I need some sync tool such as rsync to syncing zones files between 2 master DNS servers(one master CARP and one slave CARP)? Or if I want to do load balancing with CARP, how it affect on BIND?
Re: CARP+Pfsync+Bind
On Thu, 6 Oct 2005 19:52:31 -0400 Dave Anderson [EMAIL PROTECTED] wrote: Responses long enough so that required information is truncated should be rare, so perhaps you've been lucky and not encountered any yet. I understand fully what you are saying, but I just don't want to serve DNS via TCP. I'm as sure as I can be that no replies exceed 512 bytes. If it ever becomes a problem I'll use tcpserver to provide it, but it's been fine for a long time, and it's safe, at least in my case, to assume TCP is for zone transfers, YMMV. -- Regards, Ed http://www.usenix.org.uk
Re: CARP+Pfsync+Bind
Then, you can forget about DNSSEC for example ... Lio -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de ed Envoyi : vendredi 7 octobre 2005 19:25 Cc : misc@openbsd.org Objet : Re: CARP+Pfsync+Bind On Thu, 6 Oct 2005 19:52:31 -0400 Dave Anderson [EMAIL PROTECTED] wrote: Responses long enough so that required information is truncated should be rare, so perhaps you've been lucky and not encountered any yet. I understand fully what you are saying, but I just don't want to serve DNS via TCP. I'm as sure as I can be that no replies exceed 512 bytes. If it ever becomes a problem I'll use tcpserver to provide it, but it's been fine for a long time, and it's safe, at least in my case, to assume TCP is for zone transfers, YMMV. -- Regards, Ed http://www.usenix.org.uk
Re: CARP+Pfsync+Bind
On Thu, 6 Oct 2005 16:55:05 +0400 Vladimir Potapov [EMAIL PROTECTED] wrote: We have 1 server on which running firewall and DNS master service. And we planned to install another server for load balancing and redudancy. 2 servers(each have running PF and BIND) will balancing load (or one will master and other slave) for DNS and PF. Does anyone protect DNS service via CARP and PFsync? Does it work? Whether there can be problems(for example, with zones transfers, dns queries Zone transfers are on tcp/53, DNS lookups are 53/udp, so: pass in on $ext_if proto udp from any to $DNS port 53 keep state and if required: pass in on $ext_if proto tcp from $ext_net to $DNS port 53 keep state I use TinyDNS here, so we don't really need to transfer zones as its handled with a single data file. CARP can be good with DNS. -- Regards, Ed http://www.usenix.org.uk
Re: CARP+Pfsync+Bind
** Reply to message from ed [EMAIL PROTECTED] on Thu, 6 Oct 2005 14:04:20 +0100 Zone transfers are on tcp/53, DNS lookups are 53/udp, so: That's not quite the whole story: 53/tcp is also used when the response to a query is too big for a single UDP packet (the resolver sends a UDP query and gets a 'truncated' UDP reply, so the resolver retries the query using TCP) -- you should always pass both UDP and TCP for port 53 to avoid occasional obscure failures. pass in on $ext_if proto udp from any to $DNS port 53 keep state and if required: pass in on $ext_if proto tcp from $ext_net to $DNS port 53 keep state Dave -- Dave Anderson [EMAIL PROTECTED]
Re: CARP+Pfsync+Bind
On Thu, 2005-10-06 at 14:04:20 +0100, ed proclaimed... I use TinyDNS here, so we don't really need to transfer zones as its handled with a single data file. CARP can be good with DNS. 53/tcp *is* required to answer normal queries. Since you're drinking djb's koolaid, see http://cr.yp.to/djbdns/tcp.html#why 512-bytes uncommon or a mistake? I think not.
Re: CARP+Pfsync+Bind
On Thu, 6 Oct 2005 15:49:02 -0400 Dave Anderson [EMAIL PROTECTED] wrote: That's not quite the whole story: 53/tcp is also used when the response to a query is too big for a single UDP packet (the resolver sends a UDP query and gets a 'truncated' UDP reply, so the resolver retries the query using TCP) -- you should always pass both UDP and TCP for port 53 to avoid occasional obscure failures. Works fine on on the 2 domains where it's been implemented, of which I handled the conversion from BIND style to djbdns. No problems on UDP lookups alone, including some deep CNAMEs, which are just not required, but I'll deal with those at a later date. I haven't seen any problems since the change. Lookup times have improved, I can't state if this is due to the lack of TCP or the file system overheads with zone files, but I expect a mixture of the two. -- Regards, Ed http://www.usenix.org.uk
Re: CARP+Pfsync+Bind
** Reply to message from ed [EMAIL PROTECTED] on Thu, 6 Oct 2005 22:15:25 +0100 On Thu, 6 Oct 2005 15:49:02 -0400 Dave Anderson [EMAIL PROTECTED] wrote: That's not quite the whole story: 53/tcp is also used when the response to a query is too big for a single UDP packet (the resolver sends a UDP query and gets a 'truncated' UDP reply, so the resolver retries the query using TCP) -- you should always pass both UDP and TCP for port 53 to avoid occasional obscure failures. Works fine on on the 2 domains where it's been implemented, of which I handled the conversion from BIND style to djbdns. No problems on UDP lookups alone, including some deep CNAMEs, which are just not required, but I'll deal with those at a later date. I haven't seen any problems since the change. Lookup times have improved, I can't state if this is due to the lack of TCP or the file system overheads with zone files, but I expect a mixture of the two. According to RFC 1035 section 4.2.1 you're riding for a fall: Messages carried by UDP are restricted to 512 bytes (not counting the IP or UDP headers). Longer messages are truncated and the TC bit is set in the header. RFC 2671 modifies this by specifying a method for using UDP packets containing more than 512 bytes, but the maximum size is still limited. RFC 2181 section 9 is quite clear: The TC bit should be set in responses only when an RRSet is required as a part of the response, but could not be included in its entirety. The TC bit should not be set merely because some extra information could have been included, but there was insufficient room. This includes the results of additional section processing. In such cases the entire RRSet that will not fit in the response should be omitted, and the reply sent as is, with the TC bit clear. If the recipient of the reply needs the omitted data, it can construct a query for that data and send that separately. Where TC is set, the partial RRSet that would not completely fit may be left in the response. When a DNS client receives a reply with TC set, it should ignore that response, and query again, using a mechanism, such as a TCP connection, that will permit larger replies. Responses long enough so that required information is truncated should be rare, so perhaps you've been lucky and not encountered any yet. Dave -- Dave Anderson [EMAIL PROTECTED]
Re: CARP+Pfsync+Bind
On Thu, 6 Oct 2005 15:07:23 -0500 eric [EMAIL PROTECTED] wrote: On Thu, 2005-10-06 at 14:04:20 +0100, ed proclaimed... I use TinyDNS here, so we don't really need to transfer zones as its handled with a single data file. CARP can be good with DNS. 53/tcp *is* required to answer normal queries. TCP for for DNS lookups are probably going to incur latency. I'd rather just block that off and ensure that the DNS being provided does not leak excess 512 bytes. This might cause some problems with huge round robin lists, but we can all use pf round robin at the level should we require a huge address list. Since you're drinking djb's koolaid, see http://cr.yp.to/djbdns/tcp.html#why 512-bytes uncommon or a mistake? I think not. DJB woke a large portion of the world when he released djbdns, I'd not knock it, and it's pretty good advice at the above URL. -- Regards, Ed http://www.usenix.org.uk
Re: CARP+Pfsync+Bind
On Thu, 2005-10-06 at 22:15:52 +0100, ed proclaimed... TCP for for DNS lookups are probably going to incur latency. I'd rather just block that off and ensure that the DNS being provided does not leak excess 512 bytes. This might cause some problems with huge round robin lists, but we can all use pf round robin at the level should we require a huge address list. You really should be pumping gas at a gas station or something. Clearly you're not intersted in doing things correctly. DJB woke a large portion of the world when he released djbdns, I'd not knock it, and it's pretty good advice at the above URL. And the advice refers to an RFC (which was not written by djb) that specifically states that TCP can be used. I'm not knocking djb, I use qmail. I used to use tinydns, but then there were a whole world of problems with no ipv6 support natively, etc., and I just didn't want to bother anymore.
