From: sysadmin To: list@NOSPAM.org Subject: Re: Avoid Phishing using DNS Date: Tue, 27 Jan 2009 18:15:50 -0200 > http://www.digriz.org.uk/dns-malware-blacklisting > > It's something I knocked together this afternoon and probably has > inaccuracies throughout. Let me know if you see anything. Nice setup! I don't saw anything wrong, but I'm not a right person to correct a english text, because it is not my "default" language ;) Regards, Marlon From: sysadmin To: list@NOSPAM.org Subject: "redirect" queries Date: Wed, 28 Jan 2009 00:00:02 -0200 Hi, It's possible setup MaraDNS to point to a specific A record instead return a "server fail" ? For example when a user made a typo in browser www.maradnss.com redirect to a webserver that will show a page with a "typo error message". Regards, Marlon Date: Wed, 28 Jan 2009 00:32:13 -0600 Subject: Re: "redirect" queries From: Sam Trenholme To: sysadmin No; it's a commonly requested feature. I might even get around to implementing it some day with Deadwood (the code I'm working on now). Money is always a good thing. Hint hint. :) :) :) - Sam Note: If you send me a MaraDNS-related support question via private email, I will probably not answer your question (giving you one of my form replies instead), and reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be dealt with and kept confidential. 2009/1/27 sysadmin : > Hi, > > It's possible setup MaraDNS to point to a specific A record instead return > a "server fail" ? > > For example when a user made a typo in browser www.maradnss.com redirect to a > webserver that will show a page with a "typo error message". > > > Regards, > > > Marlon > Date: Wed, 28 Jan 2009 11:16:54 -0600 From: Arrakis To: list@NOSPAM.org Subject: MaraDNS & NX Domains Is there a way to configure MaraDNS to act like BIND does so when a user requests a non-existent domain we can show them a custom error page? Thank you Arrakis Date: Wed, 28 Jan 2009 12:19:42 -0600 Subject: Re: MaraDNS & NX Domains From: Sam Trenholme To: Arrakis , list@NOSPAM.org No; it's a commonly requested feature. I might even get around to implementing it some day with Deadwood (the code I'm working on now). Money is always a good thing. Hint hint. :) :) :) Note also that there is at least one searchable archive of the MaraDNS mailing list online that will give you an answer to common questions like this one: http://marc.info/?l=maradns-list This will save you time. - Sam Note: If you send me a MaraDNS-related support question via private email, I will probably not answer your question (giving you one of my form replies instead), and reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be dealt with and kept confidential. 2009/1/28 Arrakis : > Is there a way to configure MaraDNS to act like BIND does > so when a user requests a non-existent domain we can show > them a custom error page? > > Thank you > Arrakis > To: list@NOSPAM.org From: Alexander Clouter Subject: Re: MaraDNS & NX Domains Date: Thu, 29 Jan 2009 12:22:36 +0000 * Arrakis [Wed, 28 Jan 2009 11:16:54 -0600]: > > Is there a way to configure MaraDNS to act like BIND does > so when a user requests a non-existent domain we can show > them a custom error page? > Please just use an HTTP proxy server, you also get a stack of other advantages from doing so too. Try to avoid using a transparent proxy (it only breaks things and is not scalable at all) but instead use WPAD files dished out via DNS and DHCP. Cheers -- Alexander Clouter .sigmonster says: Q: What is green and lives in the ocean? A: Moby Pickle. Subject: upstream_server do not work From: Deutschem To: list@NOSPAM.org Date: Thu, 29 Jan 2009 17:04:14 +0100 hi, i want the following: upstream_servers = {} upstream_servers["."] = "x.x.x.1" upstream_servers["com."] = "x.x.x.2" that do not work ! no, i have no root_servers defined and yes, all upstream servers work fine please help thank you. Date: Thu, 29 Jan 2009 10:45:29 -0600 Subject: Re: upstream_server do not work From: Sam Trenholme To: Deutschem Which version of MaraDNS? This syntax does work in the 1.2 branch of MaraDNS. - Sam Note: If you send me a MaraDNS-related support question, I will probably not answer your question (giving you one of my form replies instead), and reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be dealt with and kept confidential. 2009/1/29 Deutschem : > hi, > > i want the following: > > upstream_servers = {} > upstream_servers["."] = "x.x.x.1" > upstream_servers["com."] = "x.x.x.2" > > that do not work ! > > no, i have no root_servers defined > and > yes, all upstream servers work fine > > please help > > thank you. > > Date: Thu, 29 Jan 2009 11:29:45 -0600 Subject: Re: MaraDNS & NX Domains From: Sam Trenholme To: list@NOSPAM.org > Please just use an HTTP proxy server, you also get a stack of other > advantages from doing so too. True. However, XeroBank has very kindly offered to sponsor adding this feature to MaraDNS, so I should start work on it today. This helps for the cases of people who can't handle WPAD files for whatever reason. > Try to avoid using a transparent proxy (it only breaks things and is not > scalable at all) but instead use WPAD files dished out via DNS and DHCP. Seconded. One of the ISPs here in Mexico uses a Squid transparent proxy and it causes headaches and slows the internet to a crawl at times. - Sam Date: Thu, 29 Jan 2009 18:39:11 +0100 From: Deutschem@NOSPAM.de Subject: Re: upstream_server do not work To: list@NOSPAM.org -------- Original-Nachricht -------- > Datum: Thu, 29 Jan 2009 10:45:29 -0600 > Von: Sam Trenholme > An: Deutschem > CC: list@NOSPAM.org > Betreff: Re: upstream_server do not work > Which version of MaraDNS? This syntax does work in the 1.2 branch of > MaraDNS. > > - Sam > > Note: If you send me a MaraDNS-related support question, I will > probably not answer your question (giving you one of my form replies > instead), and reserve the right to post your support email to the > Mara-DNS mailing list so that the community at large can examine your > issue. MaraDNS security vulnerability reports, however, will be dealt > with and kept confidential. > > 2009/1/29 Deutschem : > > hi, > > > > i want the following: > > > > upstream_servers = {} > > upstream_servers["."] = "x.x.x.1" > > upstream_servers["com."] = "x.x.x.2" > > > > that do not work ! > > > > no, i have no root_servers defined > > and > > yes, all upstream servers work fine > > > > please help > > > > thank you. > > > > -- NUR NOCH BIS 31.01.! GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 EURO/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a Date: Thu, 29 Jan 2009 18:39:30 +0100 From: Deutschem@NOSPAM.de Subject: Re: upstream_server do not work To: list@NOSPAM.org 1.2.12 -------- Original-Nachricht -------- > Datum: Thu, 29 Jan 2009 10:45:29 -0600 > Von: Sam Trenholme > An: Deutschem > CC: list@NOSPAM.org > Betreff: Re: upstream_server do not work > Which version of MaraDNS? This syntax does work in the 1.2 branch of > MaraDNS. > > - Sam > > Note: If you send me a MaraDNS-related support question, I will > probably not answer your question (giving you one of my form replies > instead), and reserve the right to post your support email to the > Mara-DNS mailing list so that the community at large can examine your > issue. MaraDNS security vulnerability reports, however, will be dealt > with and kept confidential. > > 2009/1/29 Deutschem : > > hi, > > > > i want the following: > > > > upstream_servers = {} > > upstream_servers["."] = "x.x.x.1" > > upstream_servers["com."] = "x.x.x.2" > > > > that do not work ! > > > > no, i have no root_servers defined > > and > > yes, all upstream servers work fine > > > > please help > > > > thank you. > > > > Date: Thu, 29 Jan 2009 12:02:32 -0600 Subject: Re: upstream_server do not work From: Sam Trenholme To: list@NOSPAM.org > 1.2.12 >> > upstream_servers = {} >> > upstream_servers["."] = "x.x.x.1" >> > upstream_servers["com."] = "x.x.x.2" >> > >> > Doesn't work Use 1.3.07.09; this will fix your problem: http://www.maradns.org/download/1.3/1.3.07.09/maradns-1.3.07.09.tar.bz2 http://sourceforge.net/projects/maradns - Sam Note: If you send me a MaraDNS-related support question, I will probably not answer your question (giving you one of my form replies instead), and reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be dealt with and kept confidential. Date: Thu, 29 Jan 2009 10:45:51 -0800 Subject: zoneserver logging of originating IP From: h3 To: list@NOSPAM.org In trying to troubleshoot some issues with secondaries that are not managed by me, it would be helpful to know the IP address axfr requests are coming from, but all I see in the logs (regardless of the verbose_level setting in mararc) is something like this: Jan 28 16:20:58 kuromi /usr/sbin/zoneserver: Log: Root directory changed Jan 28 16:20:58 kuromi /usr/sbin/zoneserver: Log: Socket opened on TCP port 53 Jan 28 16:20:58 kuromi /usr/sbin/zoneserver: Log: Root privileges dropped Jan 28 16:20:58 kuromi /usr/sbin/zoneserver: Log: Awaiting data on port 53 Jan 28 16:20:58 kuromi /usr/sbin/zoneserver: Log: Message received, processing Jan 28 16:20:58 kuromi /usr/sbin/zoneserver: Log: Awaiting data on port 53 Jan 28 16:20:58 kuromi /usr/sbin/zoneserver: Log: Message received, processing Jan 28 16:20:58 kuromi /usr/sbin/zoneserver: Log: Awaiting data on port 53 Jan 28 16:20:58 kuromi /usr/sbin/zoneserver: Log: Message received, processing How can I get zoneserver to log the IP address of the request? I even spent some time trying to get zoneserver to work with xinetd since there were some cryptic messages that this works but no implementation details were provided and I had no success - any pointers on that front? Thanks, Harry Subject: Re: upstream_server do not work From: Deutschem To: list@NOSPAM.org Date: Fri, 30 Jan 2009 11:24:21 +0100 Yes, the new version do that job. thank you. Am Donnerstag, den 29.01.2009, 12:02 -0600 schrieb Sam Trenholme: > > 1.2.12 > > >> > upstream_servers = {} > >> > upstream_servers["."] = "x.x.x.1" > >> > upstream_servers["com."] = "x.x.x.2" > >> > > >> > Doesn't work > > Use 1.3.07.09; this will fix your problem: > > http://www.maradns.org/download/1.3/1.3.07.09/maradns-1.3.07.09.tar.bz2 > > http://sourceforge.net/projects/maradns > > - Sam > > Note: If you send me a MaraDNS-related support question, I will > probably not answer your question (giving you one of my form replies > instead), and reserve the right to post your support email to the > Mara-DNS mailing list so that the community at large can examine your > issue. MaraDNS security vulnerability reports, however, will be dealt > with and kept confidential. Date: Sun, 1 Feb 2009 11:20:04 -0600 Subject: Re: zoneserver logging of originating IP From: Sam Trenholme To: list@NOSPAM.org > In trying to troubleshoot some issues with secondaries that are not > managed by me, it would be helpful to know the IP address axfr > requests are coming from This is a legitimate feature request. I'll look in to implementing it if I can get a sponsor to help me for a small fee. > I even > spent some time trying to get zoneserver to work with xinetd since > there were some cryptic messages that this works but no implementation > details were provided and I had no success - any pointers on that > front? This I can explain. A few years ago, someone wanted to have inetd support for zoneserver, so I implemented it. It made the code much more messy, but I was a younger and more naive (or, perhaps, less cynical) programmer and implemented it. People didn't seem very interested in it, so I removed support for it between then 1.0 and 1.2 release, since I wanted to add other features to zoneserver, such as csv2 support and generic DNS-over-TCP support. The obsolete 1.0 release of MaraDNS should still support this, but you won't get csv2 support nor DNS-over-TCP: http://www.maradns.org/download/1.0/ IP logging should be easy (and I'll welcome either a small amount of money to sponsor me implementing it or a patch that implements it); restoring inetd support should also be possible, but will take a much bigger patch or a somewhat larger but still small amount of money for me to implement. - Sam Note: If you send me a MaraDNS-related support question, and are unwilling to compensate me for my time, I will probably not answer your question (giving you one of my form replies instead), and reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be dealt with and kept confidential. From: Tom Harrison To: list@NOSPAM.org Subject: Hostnames on an internal subnet that also resolve in public DNS Date: Mon, 9 Feb 2009 16:33:25 -0500 Hello -- re MaraDNS 1.2.12.08 running on Ubuntu/Debian... I need intercommunication of a cluster of servers living in a private network (10.x.x.x), but also need to get to the address of the hosts via public DNS. So, for example, web1.example.com might resolve to 10.0.0.1, routable only within the subnet, but from an external location (our office) would resolve to a publicly routable IP like 98.76.544.321. Within the subnet the servers also need to get at public addresses too, like google.com. I have all of this working with the config below. However, some of the addresses for our domain are not in the subnet, e.g. our office "corp.example.com"; these are public addresses that can be resolved by the upstream servers. Is there a way to configure MaraDNS so that a "miss" on a name like "corp.example.dom" is passed along thus resolving to its public address? mararc: ipv4_bind_addresses = "10.252.110.37" chroot_dir = "/etc/maradns" hide_disclaimer = "YES" recursive_acl = "10.0.0.0/8" upstream_servers = {} upstream_servers["."] = "172.16.0.23" csv2 = {} csv2["example.com."] = "db.example.com" db.example.com: master.example.com. 10.252.110.37 web1.example.com. 10.252.46.6 Subject: Date: Tue, 10 Feb 2009 11:26:24 -0500 From: "Summers, William" To: I'm having a build error on OpenBSD 4.4/amd64.=20 Here it is:=20 cc -DVERSION=3D\"\" -DCOMPILED=3D\"\" -o maradns MaraDNS.c = MaraBigHash.o recursive.o timestamp.o read_kvars.o MaraAnyChain.o udpsuccess.o ../libs/JsStr.o ../libs/JsStrOS.o ../libs/JsStrCP.o ../libs/MaraHash.o ../qual/qual_timestamp.o ../dns/Queries.o ../dns/Compress.o ../dns/bobbit.o ../dns/Decompress.o ../parse/ParseMaraRc.o ../parse/ParseCsv1.o ../parse/ParseIpAcl.o ../parse/Parse_ipv6.o ../parse/Csv2_read.o ../parse/Csv2_main.o ../parse/Csv2_parse.o ../parse/Csv2_rr_soa.o ../parse/Csv2_rr_aaaa.o ../parse/Csv2_rr_a.o ../parse/Csv2_rr_wks.o ../parse/Csv2_database.o ../parse/Csv2_rr_txt.o ../parse/Csv2_esc_txt.o ../rng/rng-api-fst.o ../rng/rng-alg-fst.o -lpthread udpsuccess.o(.text+0x4d6): In function `udpsuccess': : undefined reference to `long_packet' collect2: ld returned 1 exit status *** Error code 1 Stop in /root/src/maradns/maradns-1.3.07.09/server (line 55 of Makefile). The authoritative server builds/runs fine (with a couple of simple tweaks.) The error occurs only in the recursive code.=20 William Summers Network Administrator Information Technology Services Deerfield Academy Subject: build error Date: Tue, 10 Feb 2009 12:21:33 -0500 From: "Summers, William" To: Solved =20 =20 I had built an authonly binary earlier. A =20 make clean =20 let me build the recursive binary without a hitch.=20 =20 =20 William Summers Network Administrator Information Technology Services Deerfield Academy Date: Tue, 10 Feb 2009 11:28:30 -0600 Subject: MaraDNS sponsorship possibility: OpenBSD support From: Sam Trenholme To: list@NOSPAM.org > I'm having a build error on OpenBSD 4.4/amd64. MaraDNS (the last snapshot) builds fine on Ubuntu Linux 8.10/amd64. If you have a patch that resolves this issue, send it to the mailing list. Also, I am willing to look at and resolve this issue if someone is willing to sponsor MaraDNS support on OpenBSD. Prices are reasonable and I can download an OpenBSD 4.3 32-bit VMware image at chrysaor.info to work on; for a little more, I am willing to download and install OpenBSD 4.4 64-bit in a VMware image. Thank you for your support; sponsorship makes continued MaraDNS development possible. - Sam Date: Tue, 10 Feb 2009 11:37:40 -0600 Subject: Re: Hostnames on an internal subnet that also resolve in public DNS From: Sam Trenholme To: list@NOSPAM.org > I need intercommunication of a cluster of servers living in a private > network (10.x.x.x), but also need to get to the address of the hosts via > public DNS. So, for example, web1.example.com might resolve to 10.0.0.1, > routable only within the subnet, but from an external location (our office) > would resolve to a publicly routable IP like 98.76.544.321. Within the > subnet the servers also need to get at public addresses too, like > google.com. I have all of this working with the config below. This is a feature that MaraDNS does not support. If you wish to see MaraDNS have this feature, I would love to have someone sponsor adding this feature to MaraDNS. I will, in addition to adding this feature to MaraDNS, add you to the MaraDNS sponsors list and even put a note about your sponsorship at the bottom of the MaraDNS main web page: http://maradns.org/sponsors.html http://maradns.org/ Please email me in private to discuss prices, which are currently surprisingly reasonable. Sponsorship makes continued MaraDNS development possible. - Sam Date: Tue, 10 Feb 2009 12:59:48 -0500 From: Ken Lyons - Graphix Wizard/Data-Forms To: list@NOSPAM.org Subject: [Fwd: Re: Hostnames on an internal subnet that also resolve in public I just run two DNS servers, (two running copies of maradns), one for public and one private resolving. I setup the server to have two Internal network addresses, i.e. 10.x.x.10 (53) = public DNS resolv 10.x.x.11 (53) = private DNS resolv And use the firewall to route who gets what... all WAN side request go to public and all LAN side go to private (or just setup local computers to go directly to the private dns address) Ken Lyons Tom Harrison wrote: > Hello -- re MaraDNS 1.2.12.08 running on Ubuntu/Debian... > > I need intercommunication of a cluster of servers living in a private > network (10.x.x.x), but also need to get to the address of the hosts > via public DNS. So, for example, web1.example.com might resolve to > 10.0.0.1, routable only within the subnet, but from an external > location (our office) would resolve to a publicly routable IP like > 98.76.544.321. Within the subnet the servers also need to get at > public addresses too, like google.com. I have all of this working > with the config below. > > However, some of the addresses for our domain are not in the subnet, > e.g. our office "corp.example.com"; these are public addresses that > can be resolved by the upstream servers. Is there a way to configure > MaraDNS so that a "miss" on a name like "corp.example.dom" is passed > along thus resolving to its public address? > > mararc: > ipv4_bind_addresses = "10.252.110.37" > chroot_dir = "/etc/maradns" > hide_disclaimer = "YES" > recursive_acl = "10.0.0.0/8" > upstream_servers = {} > upstream_servers["."] = "172.16.0.23" > csv2 = {} > csv2["example.com."] = "db.example.com" > > db.example.com: > master.example.com. 10.252.110.37 > web1.example.com. 10.252.46.6 > > > -- Ken Lyons / e/Solutions / IT Services *GraphixWizard/Data-Forms* */Toll Free/* 800.447.3676 */Direct/* 407.656.9742 */Fax/* 407.656.3353 kenl@NOSPAM.com hosting.graphixwizard.com From: Tom Harrison To: list@NOSPAM.org Subject: Re: Hostnames on an internal subnet that also resolve in public DNS Date: Wed, 11 Feb 2009 09:25:54 -0500 Thanks Ken, Running an additional DNS server is not practical in our environment (which is Amazon EC2) for several reasons. Amazon EC2 provides their own internal server to resolve their own internal addresses, as well as recursive DNS requests for public addresses from within the cloud. Also our SOA name server for publicly routable names and addresses is hosted elsewhere. I could accomplish everything I need by updating /etc/hosts on all of the servers, but this is not practical when you have multiple domains and an increasingly large number of servers that come and go. Having a single point of management, MaraDNS, becomes essential. So maybe my question could be rephrased as follows. Is it possible to configure MaraDNS to provide the same functionality of /etc/hosts? Specifically: 1) preferential name resolution to a locally routable address of a some hosts on our domains, 2) gracefully passes unresolved requests along to the public/recursive DNS server provided by our ISP, 3) even if some of the addresses are on the same domain as those we manage with MaraDNS. Thanks all! Tom On Feb 10, 2009, at 8:23 AM, Ken Lyons - Graphix Wizard/Data-Forms wrote: > I just run two DNS servers, (two running copies of maradns), one for > public and one private resolving. > I setup the server to have two Internal network addresses, i.e. > 10.x.x.10 (53) = public DNS resolv > 10.x.x.11 (53) = private DNS resolv > And use the firewall to route who gets what... > all WAN side request go to public and all LAN side go to private > (or just setup local computers to go directly to the private dns > address) > > Ken Lyons > > > > Tom Harrison wrote: >> >> Hello -- re MaraDNS 1.2.12.08 running on Ubuntu/Debian... >> >> I need intercommunication of a cluster of servers living in a >> private network (10.x.x.x), but also need to get to the address of >> the hosts via public DNS. So, for example, web1.example.com might >> resolve to 10.0.0.1, routable only within the subnet, but from an >> external location (our office) would resolve to a publicly routable >> IP like 98.76.544.321. Within the subnet the servers also need to >> get at public addresses too, like google.com. I have all of this >> working with the config below. >> >> However, some of the addresses for our domain are not in the >> subnet, e.g. our office "corp.example.com"; these are public >> addresses that can be resolved by the upstream servers. Is there a >> way to configure MaraDNS so that a "miss" on a name like >> "corp.example.dom" is passed along thus resolving to its public >> address? >> >> mararc: >> ipv4_bind_addresses = "10.252.110.37" >> chroot_dir = "/etc/maradns" >> hide_disclaimer = "YES" >> recursive_acl = "10.0.0.0/8" >> upstream_servers = {} >> upstream_servers["."] = "172.16.0.23" >> csv2 = {} >> csv2["example.com."] = "db.example.com" >> >> db.example.com: >> master.example.com. 10.252.110.37 >> web1.example.com. 10.252.46.6 >> >> >> Date: Wed, 11 Feb 2009 09:59:39 -0500 From: Ken Lyons - Graphix Wizard/Data-Forms To: list@NOSPAM.org Subject: Re: Hostnames on an internal subnet that also resolve in public DNS I don't know of anyway Mara can do that... This feature is often asked for, but I don't know of any workaround without changing the code or donating to Sam (best approach). == As before I use two dns copies in that instance. Mara by default is both authoritive and recursive.. if domain.com is listed, mara assumes that it will have all records for that domain and all subdomains. So if a certain subdomain doesn't exists it's going to return a Serv Fail instead of passing it on to the upstream DNS. If the domain isn't in mara it will gladly resolve it using the upstream DNS. ?? (Delegate specific subdomains to another DNS?) Maybe Sam knows if there is a switch that could have Mara change from ServFail ouput and jump to a recursive request instead... --giving the results you want. www.domain.com in mara, resolves, unknown.domain.com... would be ServFailed, but uses upstream to resolve, passing result. I don't believe there is one, but I don't know everything about mara. As far as the /etc/hosts.... why not just make a single hosts file and have each system update using wget or rsync, etc. Then it still single management point. Ken Tom Harrison wrote: > Thanks Ken, > > Running an additional DNS server is not practical in our environment > (which is Amazon EC2) for several reasons. Amazon EC2 provides their > own internal server to resolve their own internal addresses, as well > as recursive DNS requests for public addresses from within the cloud. > Also our SOA name server for publicly routable names and addresses is > hosted elsewhere. > > I could accomplish everything I need by updating /etc/hosts on all of > the servers, but this is not practical when you have multiple domains > and an increasingly large number of servers that come and go. Having a > single point of management, MaraDNS, becomes essential. > > So maybe my question could be rephrased as follows. Is it possible to > configure MaraDNS to provide the same functionality of /etc/hosts? > Specifically: > > 1) preferential name resolution to a locally routable address of a > some hosts on our domains, > > 2) gracefully passes unresolved requests along to the public/recursive > DNS server provided by our ISP, > > 3) even if some of the addresses are on the same domain as those we > manage with MaraDNS. > > Thanks all! > > Tom > > On Feb 10, 2009, at 8:23 AM, Ken Lyons - Graphix Wizard/Data-Forms wrote: > >> I just run two DNS servers, (two running copies of maradns), one for >> public and one private resolving. >> I setup the server to have two Internal network addresses, i.e. >> 10.x.x.10 (53) = public DNS resolv >> 10.x.x.11 (53) = private DNS resolv >> And use the firewall to route who gets what... >> all WAN side request go to public and all LAN side go to private >> (or just setup local computers to go directly to the private dns >> address) >> >> Ken Lyons >> >> >> >> Tom Harrison wrote: >>> >>> Hello -- re MaraDNS 1.2.12.08 running on Ubuntu/Debian... >>> >>> I need intercommunication of a cluster of servers living in a >>> private network (10.x.x.x), but also need to get to the address of >>> the hosts via public DNS. So, for example, web1.example.com might >>> resolve to 10.0.0.1, routable only within the subnet, but from an >>> external location (our office) would resolve to a publicly routable >>> IP like 98.76.544.321. Within the subnet the servers also need to >>> get at public addresses too, like google.com. I have all of this >>> working with the config below. >>> >>> However, some of the addresses for our domain are not in the subnet, >>> e.g. our office "corp.example.com"; these are public addresses that >>> can be resolved by the upstream servers. Is there a way to >>> configure MaraDNS so that a "miss" on a name like "corp.example.dom" >>> is passed along thus resolving to its public address? >>> >>> mararc: >>> ipv4_bind_addresses = "10.252.110.37" >>> chroot_dir = "/etc/maradns" >>> hide_disclaimer = "YES" >>> recursive_acl = "10.0.0.0/8" >>> upstream_servers = {} >>> upstream_servers["."] = "172.16.0.23" >>> csv2 = {} >>> csv2["example.com."] = "db.example.com" >>> >>> db.example.com: >>> master.example.com. 10.252.110.37 >>> web1.example.com. 10.252.46.6 >>> >>> >>> > > Date: Wed, 11 Feb 2009 13:12:16 -0600 Subject: Re: Hostnames on an internal subnet that also resolve in public DNS From: Sam Trenholme To: Tom Harrison OK, to clarify, what MaraDNS can't do (but what people have frequently asked for over the years) is have it so a given host name resolves differently depending on the IP someone has. > So maybe my question could be rephrased as follows. Is it possible to > configure MaraDNS to provide the same functionality of /etc/hosts? [...] > 3) even if some of the addresses are on the same domain as those we manage > with MaraDNS. Yes, MaraDNS can do this. In particular: It is possible to have MaraDNS resolve foo.example.com with the authoritative nameserver, but use recursion to resolve bar.example.com. This is done something like this: Make a zone called foo.invalid.example.com or what not. Then add entries to the zonefile that aren't part of this zone, such as "foo.example.com" or "www.amazon.com.phisher.nasty.example.net" For example, this 4-line mararc file will allow on to have IP addresses in the file named "db.list" similar to /etc/hosts: ipv4_bind_addresses = "127.0.0.1" recursive_acl = "127.0.0.1/8" csv2 = {} csv2["foo.invalid.example.com."] = "db.list" The file "db.list" can now look like /etc/hosts (but with the name before the IP): foo.example.com. 10.2.3.4 weirdname.local.foo. 10.2.3.5 etc. If you want a single name to have multiple IP addresses, that's also easy: foo.example.com. 10.2.3.5 foo.example.com. 10.2.3.4 You can even have non-A records: foo.example.com. TXT 'Foo!' Date: Mon, 16 Feb 2009 21:33:13 -0500 From: Milan Kupcevic To: list@NOSPAM.org Subject: [MARA] Zoneserver mararc dns_port patch This is a multi-part message in MIME format. --------------010700090409050304090807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Zoneserver should use dns_port variable from mararc to listen on, otherwise it should use port 53. --------------010700090409050304090807-- Date: Tue, 17 Feb 2009 01:08:47 -0500 (EST) From: milan@NOSPAM.harvard.edu To: list@NOSPAM.org Subject: [MARA] Zoneserver mararc dns_port patch Zoneserver should use dns_port variable from mararc to listen on, otherwise it should use port 53. diff -urN ./tcp/zoneserver.c ../maradns-Q.20090216.1/tcp/zoneserver.c --- ./tcp/zoneserver.c 2009-02-16 15:39:26.000000000 -0500 +++ ../maradns-Q.20090216.1/tcp/zoneserver.c 2009-02-16 19:28:31.000000000 -0500 @@ -76,6 +76,8 @@ to */ int udp_forward_server = 0; +int dns_port = 53; /* The default port for the zoneserver to listen on */ + int no_cname_warnings = 1; /* So we can link to MaraBigHash.o */ /* Signal handler for handling the exit of a child */ @@ -247,7 +249,7 @@ return 12; } -/* Bind to TCP port 53. +/* Bind to TCP dns_port. Input: pointer to socket to bind on, js_string with the dotted-decimal ip address to bind to Output: JS_ERROR on error, JS_SUCCESS on success @@ -281,7 +283,7 @@ /* Choose an IP and port to bind to */ memset(&dns_tcp,0,sizeof(dns_tcp)); dns_tcp.sin_family = AF_INET; - dns_tcp.sin_port = htons(53); + dns_tcp.sin_port = htons(dns_port); if((dns_tcp.sin_addr.s_addr = ip) == INADDR_NONE) return JS_ERROR; @@ -299,7 +301,7 @@ if(listen(*sock,250) == -1) return JS_ERROR; - /* We are now on TCP port 53. Leave */ + /* We are now on TCP dns_port. Leave */ return JS_SUCCESS; } @@ -1166,10 +1168,18 @@ mlog(L_CHROOT_SUCCESS); /* "Root directory changed" */ - /* Bind to port 53 + /* Bind to dns_port To Do: use capset to give us privledged bind abilities without needing to be root. */ + + /* Set the dns_port */ + dns_port = read_numeric_kvar("dns_port",53); + if(dns_port < 1 || dns_port > 65530) { + harderror("dns_port must be between 1 and 65530"); + exit(1); + } + if(inetd != 1) { /* If we are a standalone server */ ipv4pair *bind_addresses; int bind_address_iterate; @@ -1214,7 +1224,7 @@ dup2(stream1[1],2); /* Stderr redirection */ if(tcpbind(&sock, bind_addresses[bind_address_iterate].ip) == JS_ERROR) - harderror(L_BIND); /* "Problem binding to port 53.\nMost likely, another process is already listening on port 53" */ + harderror(L_BIND); /* "Problem binding to dns_port.\nMost likely, another process is already listening on dns_port" */ break; } bind_address_iterate++; @@ -1268,7 +1278,7 @@ } if(libtcp_create_bind_addrs() == JS_ERROR) harderror("libtcp_create_synthip_addrs"); - mlog(L_SOCKET_SUCCESS); /* "Socket opened on TCP port 53" */ + mlog(L_SOCKET_SUCCESS); /* "Socket opened on TCP dns_port" */ } /* Drop the elevated privileges */ @@ -1425,7 +1435,7 @@ 7: Both zone transfer and forward with recursion enabled */ if(verbose >= 2) - mlog(L_WAITING); /* "Awaiting data on port 53" */ + mlog(L_WAITING); /* "Awaiting data on dns_port" */ connection = gettcp(&sock,zonetransfer_acl,tcpconvert_acl, recursive_acl,500,&permissions); if(connection == JS_ERROR) To: list@NOSPAM.org From: Alexander Clouter Subject: Re: Zoneserver mararc dns_port patch Date: Tue, 17 Feb 2009 09:36:34 +0000 Hi, * milan@NOSPAM.harvard.edu [Tue, 17 Feb 2009 01:08:47 -0500 (EST)]: > > + /* Set the dns_port */ > + dns_port = read_numeric_kvar("dns_port",53); > + if(dns_port < 1 || dns_port > 65530) { > + harderror("dns_port must be between 1 and 65530"); > + exit(1); > + } Only to satisfy my curiousity, why '> 65530' and not '> 65535', otherwise known as 2^16 - 1? Cheers -- Alexander Clouter .sigmonster says: Reality is for people who lack imagination. Date: Tue, 17 Feb 2009 08:55:46 -0500 (EST) From: Milan Kupcevic To: Alexander Clouter Subject: Re: Zoneserver mararc dns_port patch On Tue, 17 Feb 2009, Alexander Clouter wrote: > Hi, > > * milan@NOSPAM.harvard.edu [Tue, 17 Feb 2009 01:08:47 -0500 (EST)]: > > > > + /* Set the dns_port */ > > + dns_port = read_numeric_kvar("dns_port",53); > > + if(dns_port < 1 || dns_port > 65530) { > > + harderror("dns_port must be between 1 and 65530"); > > + exit(1); > > + } > > Only to satisfy my curiousity, why '> 65530' and not '> 65535', > otherwise known as 2^16 - 1? > > Cheers > Zoneserver should act the same as MaraDNS acts. Take a look at /server/MaraDNS.c. Why MaraDNS limits listening ports to 1--65530 range is a mistery of itself. Milan Date: Fri, 20 Feb 2009 14:39:10 -0600 Subject: Re: Zoneserver mararc dns_port patch From: Sam Trenholme To: list@NOSPAM.org > Only to satisfy my curiousity, why '> 65530' and not '> 65535', > otherwise known as 2^16 - 1? I like having a "cushion of error" to stop things hitting the limits of values; this helps minimize possible security problems. I would like to thank Milan Kupcevic for submitting this patch; I will look at it next week sometime. William Summers provided me with a patch to compile MaraDNS under OpenBSD last week; I finally integrated this patch in to the "HEAD branch" of MaraDNS and it can be seen in a snapshot I uploaded yesterday (20090219): http://www.maradns.org/download/1.3/snap/200902 - Sam Date: Tue, 24 Feb 2009 10:37:48 -0600 Subject: Re: [MARA] Zoneserver mararc dns_port patch From: Sam Trenholme To: milan@NOSPAM.harvard.edu > Zoneserver should use dns_port variable from mararc to listen on, > otherwise it should use port 53. > > > diff -urN ./tcp/zoneserver.c ../maradns-Q.20090216.1/tcp/zoneserver.c > --- ./tcp/zoneserver.c 2009-02-16 15:39:26.000000000 -0500 > +++ ../maradns-Q.20090216.1/tcp/zoneserver.c 2009-02-16 This patch doesn't patch cleanly against the version of zoneserver in MaraDNS-1.3.13: 10:28:43 maradns-1.3.14 $ patch -p1 < ../Zoneserver/zoneserver.patch patching file tcp/zoneserver.c Hunk #1 succeeded at 76 with fuzz 1. Hunk #2 FAILED at 249. Hunk #3 FAILED at 283. Hunk #4 FAILED at 301. Hunk #5 FAILED at 1168. Hunk #6 FAILED at 1224. Hunk #7 FAILED at 1278. Hunk #8 FAILED at 1435. 7 out of 8 hunks FAILED -- saving rejects to file tcp/zoneserver.c.rej I only support adding new features to the development branch of MaraDNS; namely MaraDNS 1.3.13. If you want this patch to be accepted, please refactor the patch so it works with MaraDNS 1.3.13. The only changes I make to the 1.2.12 and 1.3.07 branches to MaraDNS are critical errors; mostly only security fixes. I don't have time to refactor this patch myself; I am working on the SQA tests for Deadwood (read the blog at http://maradns.blogspot.com for frequent updates). - Sam Note: If you send me a MaraDNS-related support question via private email, I will ask you to sponsor MaraDNS before I will address your concern. Thank you for your understanding. Date: Tue, 24 Feb 2009 11:17:03 -0600 Subject: Re: [MARA] Zoneserver mararc dns_port patch From: Sam Trenholme To: Milan Kupcevic , list@NOSPAM.org > It patches cleanly against version 1.3.13 downloaded from > http://maradns.org/download/1.3/snap/200902/maradns-Q.20090216.1.tar.bz2 OK, I got a corrupted copy of the patch. I will see if I can get a clean copy from the mailing list archives (Gmail corrupts patches unless they are attached as files): - Sam Date: Tue, 24 Feb 2009 18:20:32 +0100 From: Remco Rijnders To: Sam Trenholme Subject: Re: [MARA] Zoneserver mararc dns_port patch -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sam Trenholme schreef: > OK, I got a corrupted copy of the patch. I will see if I can get a > clean copy from the mailing list archives (Gmail corrupts patches > unless they are attached as files): ... and attached files are stripped out by the mailing list software. I'll have a look to see if this can be worked around. - -- Jabber / GT: remmy@NOSPAM.xs4all.nl ICQ: 760542 MSN: remco@NOSPAM.com PGP-key: 0xE4E2CDAB -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmkLGAACgkQP0wYCuTizauYMQCfSDJr6KxgXjyQ+ROdi0VdZPpR EYkAn3/9x/djypeOaBThaPvRvrMg/Ltx =s+d5 -----END PGP SIGNATURE----- Date: Tue, 24 Feb 2009 11:56:17 -0600 Subject: Re: [MARA] Zoneserver mararc dns_port patch From: Sam Trenholme To: Remco Rijnders OK, I've got the patch to apply. I will now do some testing to see if the patch breaks anything, and release a MaraDNS snapshot later on today. Thank you for your contributions to MaraDNS. - Sam Date: Tue, 24 Feb 2009 12:42:04 -0600 Subject: Re: [MARA] Zoneserver mararc dns_port patch From: Sam Trenholme To: Remco Rijnders > OK, I've got the patch to apply. =A0I will now do some testing to see if > the patch breaks anything, and release a MaraDNS snapshot later on > today. Done. http://www.maradns.org/download/1.3/snap/200902 Testing would be appreciated (It passed the standard automated regression and -Wall is as quiet as a mouse in both CentOS 5.2 and Ubuntu 8.10 64-bit) :) - Sam From: Tim-Ole Alexander Golz To: list@NOSPAM.org Subject: Mara does not resolve ncs.gov Date: Mon, 2 Mar 2009 11:50:49 +0100 Hi, there, I have two Maradns installed as internal DNS with forwarding for external addresses: ipv4_alias = {} ipv4_alias["icann"] = "198.41.0.4,128.9.0.107,192.33.4.12,128.8.10.90,192.203.230.10,192.5.5.241,192.112.36.4,128.63.2.53,192.36.148.17,192.58.128.30,193.0.14.129,198.32.64.12,202.12.27.33 " ipv4_alias["osrc"] = "82.198.193.1 199.166.24.1,205.189.73.102,199.166.24.3,207.126.103.16,195.117.6.10,205.189.73.10,204.57.55.100,213.196.2.97 " ipv4_alias["alternic"] = "160.79.129.192,24.6.78.12,160.79.133.70,65.15.8.202,216.162.42.240,195.224.64.190,160.79.133.66,216.162.42.185 " ipv4_alias["opennic"] = "131.161.247.226,209.151.84.102,64.247.218.140,64.247.218.149,209.104.33.250,209.104.63.249,209.151.84.103,199.175.137.211,207.6.128.246,65.243.92.254 " ipv4_alias["localhost"] = "127.0.0.0/8" ipv4_alias["private"] = "192.168.119.0/24" zone_transfer_acl = "127.0.0.1" recursive_acl = "localhost,private" random_seed_file = "/dev/urandom" root_servers = {} root_servers["."] = "icann" But Mara doesnt resolve ncs.gov: vcontrol.itnotez.de:/etc/maradns# host -v www.ncs.gov Query about www.ncs.gov for record types A Trying www.ncs.gov ... Query failed, 0 answers, status: server failure www.ncs.gov A record not found, server failure vcontrol.itnotez.de:/etc/maradns# host -v ncs.gov Query about ncs.gov for record types A Trying ncs.gov ... Query failed, 0 answers, status: server failure ncs.gov A record not found, server failure The log just says: Mar 2 11:47:00 vcontrol maradns.etc_maradns_mararc: Log: Message received, processing Mar 2 11:47:04 vcontrol maradns.etc_maradns_mararc: Query from: 192.168.119.1 Ancs.gov. Mar 2 11:47:04 vcontrol maradns.etc_maradns_mararc: Log: No reply from remote servers Mara is 1.2.12.04-1etch2 on Debian Etch. Is there a solution for this? I wont install MaraDNS from other sources because I dont want to break the integrity of the aptitude- System; otherwise the server is working well. Thanx a lot in advance! Tim-Ole Golz From: Tim-Ole Alexander Golz To: list@NOSPAM.org Subject: Re: Mara does not resolve ncs.gov Date: Mon, 2 Mar 2009 16:26:32 +0100 Hi, all there, sorry, that was my fault - a place somewhere very, very deep in my brain I surely *knew* about the problems with version 1.2.12.04 on Debian Etch - but since I am working on Citrix Xen for that special two Maras I forgot it ... so, usually I had all my other Debianservers fairly updated. I now followed the advisory given by Sam at another place, another time: http://woodlane.webconquest.com/pipermail/list/2007-September/000041.html and now Mara works again like a charm. I apologize for the stupid thread :-( greetings Tim-Ole Date: Mon, 2 Mar 2009 10:55:33 -0600 Subject: Re: Mara does not resolve ncs.gov From: Sam Trenholme To: list@NOSPAM.org > sorry, that was my fault - a place somewhere very, very deep in my brain I > surely *knew* about the problems with version 1.2.12.04 on Debian Etch Yeah, one of my long-standing annoyances is that Debian ships outdated, buggy versions of MaraDNS. There have been no changes between MaraDNS 1.2.12.04 and 1.2.12.09 except for bug fixes, but Debian's retarded policies mean that "apt-get install" gives you an obsolete version of MaraDNS. I appreciate Debian making MaraDNS available on their list of available software, since it gives MaraDNS more exposure, but if you have an issue with an outdated release of MaraDNS, file a bug with Debian's bug reporting system; if they get enough bug reports, they might actually update to 1.2.12.09. Personally, I don't care for Debian; it has the issues all-volunteer organizations have: Inconsistent release schedules, no clearly-defined EOL date (RHEL/CentOS 5 has one: March 31, 2014), and it covers a lot more than RHEL does, but a lot covered isn't very well-covered. For example, Debian, unlike RHEL, comes with MaraDNS, but the version is an outdated version because there are control freaks who aren't sure that subsequent 1.2.12 releases are bugfix-only changes without looking at the patches themselves, but won't take the time to look at the patches. I will start making RHEL/CentOS packages for MaraDNS (again), since RHEL/CentOS 5 is the primary development platform for MaraDNS. Indeed, I might set up a CentOS repository with MaraDNS, fvwm1, xloadimage, xlock, and xdaliclock (these four "outdated" 1990s Linux GUI programs are an integral part of my MaraDNS development environment) Take care, - Sam Date: Mon, 2 Mar 2009 09:52:16 -0800 From: Rick Moen To: list@NOSPAM.org Subject: Re: Mara does not resolve ncs.gov Quoting Sam Trenholme (strenholme.usenet@NOSPAM.com): > I appreciate Debian making MaraDNS available on their list of > available software, since it gives MaraDNS more exposure, but if you > have an issue with an outdated release of MaraDNS, file a bug with > Debian's bug reporting system; if they get enough bug reports, they > might actually update to 1.2.12.09. Actually, Debian-stable ("lenny") provides MaraDNS 1.3.07.09. The current bug report assumes use of an obsolete branch of Debian. Date: Mon, 2 Mar 2009 12:04:43 -0600 Subject: Re: Mara does not resolve ncs.gov From: Sam Trenholme To: list@NOSPAM.org > Actually, Debian-stable ("lenny") provides MaraDNS 1.3.07.09. > > The current bug report assumes use of an obsolete branch of Debian. Excellent; since Debian Etch is marked "old stable" I think issues like this will come up less. Is there any kind of estimated EOL timeline for Lenny? - Sam (I actually have a Debian 5.0 server VMware image floating around and maradns.org uses Debian) Date: Mon, 2 Mar 2009 10:55:28 -0800 From: Rick Moen To: list@NOSPAM.org Subject: Re: Mara does not resolve ncs.gov Quoting Sam Trenholme (strenholme.usenet@NOSPAM.com): > Is there any kind of estimated EOL timeline for Lenny? Not that I know of. People who want deterministic release and EOL schedules on a Debian-family distribution generally move to *buntu. Personally, I've always considered running any incarnation of Debian-stable to be inappropriate, as running (by contrast) Debian-testing with optional access to Debian-unstable packages* is a more satisfactory solution, including on production servers. (The usual objection is that there's not a high guarantee of quality on Testing, but this turns out in practice to seldom cause problems, and in general only minor and easily solved ones, unlike with other commonly encountered rolling distribution branches such as Rawhide or Cooker. I.e., the quarantining script that populates Testing does an adequate job of keeping you just far enough from the bleeding edge for comfort. My opinion, yours for a small fee and disclaimer of reverse-engineering rights.) *If ever curious about how to do this, please ask. It's not very involved. Date: Mon, 2 Mar 2009 11:09:50 -0800 From: Rick Moen To: list@NOSPAM.org Subject: Re: Mara does not resolve ncs.gov I wrote: > Quoting Sam Trenholme (strenholme.usenet@NOSPAM.com): > > > Is there any kind of estimated EOL timeline for Lenny? > > Not that I know of. However, the "Lenny" release notes include this reminder: "Typically only two stable releases are supported at any given time." This is in the context of a note that the Debian Project generally continues security support for one year after a branch's release, as long as there isn't a second stable release within that year. Basically, the normal upgrade from one stable branch to the next is so reliable and in fact automatic, given periodic use of apt-get or aptitide, that the Debian Project feels that you'd remain on an obsolete former stable branch only through going out of your way to apply local policies that are generally against your interest. Or, to put it another way, if you've decided that Debian-stable is the desired amount of distance from the bleeding edge, then for heaven's sake, leave your /etc/apt/sources.list entries pegged to "stable": Don't set them to "etch", thereby sabotaging the intended maintenance regime and deliberately no-downtime upgrade path from one stable branch to the next. Date: Mon, 2 Mar 2009 13:47:17 -0600 Subject: Re: Mara does not resolve ncs.gov From: Sam Trenholme To: list@NOSPAM.org >> Quoting Sam Trenholme (strenholme.usenet@NOSPAM.com): >> >> > Is there any kind of estimated EOL timeline for Lenny? >> >> Not that I know of. > > However, the "Lenny" release notes include this reminder: > > "Typically only two stable releases are supported at any given time." Makes sense. OK, in light of this: * Etch is "out of date" and it's not a surprise that its copy of MaraDNS is out of date. * Debian makes it easy to update from one stable release to the next; people using Etch can (in theory) easily update to Lenny. * Debian stable stays stable but Debian doesn't do what RedHat does: They don't support a given release for seven years. They expect people to update more frequently than that. This is somewhat different from the way RHEL/CentOS do things. To wit: * When RedHat releases a release of RHEL, that release is supported, without any major changes, for seven years. Updates that add new features are done for three years, and security fixes are done for four more years. * Usually, this means little changes for those seven years. During the first three years of support, RedHat adds new features, such as drivers for new hardware for the kernel used by the operating system. For the last four years of support, the only updates are security updates and other minor bigfix-only changes. * This isn't hard and fast. For example, in RHEL 4 and RHEL 5, RedHat has updated Firefox from Firefox 1.5.XX to Firefox 3, since Firefox 1.5 is not compatible with modern websites, RHEL's customers wanted an up-to-date web browser, and it was getting harder and harder to backport security fixes for current versions of Firefox to the 1.5 version of Firefox. I might even look at the Debian 5 VMware image I downloaded yesterday; I mainly downloaded it to fill up some space on a backup DVD I burned yesterday, but also to more easily get Debian running in case someone decides to pay me to more fully support Debian (I also downloaded OpenBSD and Ubuntu server, for the same reasons) To bring this back to topic, people reading my blog will see I'm doing a lot of SQA testing with Deadwood, the code that will, one of these years, become the next-generation recursive resolver for MaraDNS. The code is currently a non-recursive DNS cache; I have just today discovered what looks to be some issues with some elements getting cached, an issue I will work on this week. People can look at the MaraDNS blog to see the work I've been doing: http://maradns.blogspot.com http://www.maradns.org/blog - Sam Date: Mon, 2 Mar 2009 16:36:51 -0800 From: Rick Moen To: list@NOSPAM.org Subject: Re: Mara does not resolve ncs.gov Quoting Sam Trenholme (strenholme.usenet@NOSPAM.com): > * Debian makes it easy to update from one stable release to the next; > people using Etch can (in theory) easily update to Lenny. It's actually a key part of each Debian release manager's job to make sure that the stable -> stable migration _does_ work smoothly. The release of that new "stable" branch isn't supposed to occur until that has been verified to be the case, among other requirements. (Debian sysadmins should be doing resyncs to the package mirrors every week or two, anyway. So, the stable -> stable switchover happens effectively automatically, the only noticeable difference from other package updates being more new packages downloaded than usual. It's not uncommon to hear a sysadmin say he/she was unaware it happened until days or weeks later, in fact. Local customisations get reapplied, daemons stop and then restart with the new versions, and there's essentially zero downtime: It's a live-production upgrade.) This is a different way of thinking (and of maintaining systems) from what applies with most other distros, and very commonly misunderstood. The Debian Project (for whom I don't speak) does very little to clarify the situation: Part of the reason, I'd speculate, is that most of Debian's 1000+ developers simply don't care about the Stable branch in the first place, as they don't run it. Date: Mon, 2 Mar 2009 19:56:53 -0600 Subject: Re: Mara does not resolve ncs.gov From: Sam Trenholme To: list@NOSPAM.org > It's actually a key part of each Debian release manager's job to make > sure that the stable -> stable migration _does_ work smoothly. =A0The > release of that new "stable" branch isn't supposed to occur until that > has been verified to be the case, among other requirements. Do they even make sure there are conversion scripts that convert all relevant configuration files from one version of a given daemon to the next version? For example, the BIND 4 -> BIND 8 config file conversion was non-trivial; in addition, I think Apache made some pretty significant changes from Apache 1 -> Apache 2. If Debian even automagically converts configuration files, that's *really* slick. - Sam (Yes, working on Deadwood; I did find an error in the code but the problem I saw earlier today was in my test, not in Deadwood. I'll release a new Deadwood snapshot tomorrow, as I have been doing almost every day these last couple of weeks) Date: Mon, 2 Mar 2009 23:52:55 -0800 From: Rick Moen To: list@NOSPAM.org Subject: Re: Mara does not resolve ncs.gov Quoting Sam Trenholme (strenholme.usenet@NOSPAM.com): > Do they even make sure there are conversion scripts that convert all > relevant configuration files from one version of a given daemon to the > next version? Mu. ;-> I can't remember all details, but the general technique does _not_ aspire, in any way, to convert raw conffiles from an old version's data format to an incompatible new implentation's format. Instead, when you first install a package with significant configuration variations, you are prompted (through the services of the debconf[1] utility) for your choices on the basis of which the conffiles get written. debconf stores your answers to those questions in .templates files. When it's necessary to reimplement your configuration in a later and perhaps marginally compatible later version of the package, your answers are reapplied. This is of course not a magic bullet: You can easily have situations where you've directly hacked a system-managed conffile; it's debconf's duty in those cases to inform you of this situation and offer various options to deal with the diffs. However, there's been a strong tendency to ameliorate this category of problem by extracting locally-managed details out of software conffiles as include files (or equivalent) separate from the system-managed main conffile, so that smooth upgrades remain possible while usually avoiding what one might call the .rpmnew / .rpmsave problem. And indeed some changes are such sea changes that they're only arguably the same program at all: > For example, the BIND 4 -> BIND 8 config file conversion was > non-trivial; It was also so very long ago (1997) that neither Debian nor any other *ix even dreamed of handling named.boot to named.conf conversion programmatically. ;-> (Joey Hess didn't even have debconf production ready until around 2000.) > in addition, I think Apache made some pretty significant changes from > Apache 1 -> Apache 2. And that's why apache2 is a different package from "apache" (1.3.x). You can keep your old 1.3.x "apache" packages going, as you go from one stable release to another -- and they'll keep getting security updates and fixes. It won't break; it'll keep running. It won't magically turn into Apache2, which is different software. Eventually, at some point, though, it'll cease to be a supported package, and then you won't get further updates. In the case of the "apache" package, that's going to happen with Debian 6.0 "Squeeze"'s release. See: http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.html#deprecated (All of the above also applies in one way or another to all Debian-family distributions, such as the *buntu group. E.g., they all use debconf, separately named packages for Apache httpd 1.3.x vs. 2.x, and so on.) [1] http://www.fifi.org/cgi-bin/man2html/usr/share/man/man8/debconf.8.gz Date: Fri, 06 Mar 2009 19:45:53 +0200 From: Yassen Damyanov To: list@NOSPAM.org Subject: Too long subdomain string? Hello to all on maradns list, (I apologize if this is not the appropriate place to ask the following question.) I am a happy user of maradns for a long time, and never had any issues... until today. I run maradns as an authoritative DNS server for half a dozen of domains and the following subdoman configuration did not work: adivanshoptest.adivan-is.com. IP.ADD.RE.SS If I cut for example the first character, the line divanshoptest.adivan-is.com. IP.ADD.RE.SS DOES work fine. The version reported by the daemon is: # maradns --version This is MaraDNS version 1.2.12.09 Compiled on a OpenBSD system at Thu Mar 13 10:34:19 MDT 2008 The question is: does anybody know if maradns implies a length limit on a segment of the name entry, or if there is any other reason for this behavior? Your advice would be highly appreciated! Thanks in advance, Yassen -- Yassen Damyanov IT Labs, Ltd. Date: Fri, 6 Mar 2009 12:46:39 -0600 Subject: Re: Too long subdomain string? From: Sam Trenholme To: list@NOSPAM.org > I run maradns as an authoritative > DNS server for half a dozen of domains and the following > subdoman configuration did not work: > > adivanshoptest.adivan-is.com. IP.ADD.RE.SS > > If I cut for example the first character, the line > > divanshoptest.adivan-is.com. IP.ADD.RE.SS > > DOES work fine. > > The version reported by the daemon is: > > # maradns --version > This is MaraDNS version 1.2.12.09 > Compiled on a OpenBSD system at Thu Mar 13 10:34:19 MDT 2008 Works for me. Using maradns-1.2.12.10: $ cat /etc/mararc # Example mararc file. # This only shows a subset of MaraDNS' features needed to be an # authoritative and recursive name server. Look at # detailed/example_full_mararc for an example showing most of # the features that MaraDNS has. # Note that this example mararc file will not actually do anything # without modification. # Look in the doc/en/examples directory for a working example # authoritative nameserver, and a working recursive nameserver. # The various zones we support # When running in authoritative mode, we must initialize the csv2 hash, # or MaraDNS will be unable to load any csv2 zone files csv2 = {} # This is just to show the format of the file # Note the this is commented out. Any line that starts with # a '#' is not read by the parser. Remove the leading '#' to # enable any line that is commented out # The following line (commented out) tells MaraDNS to look at the # file db.example.net to get the zone for example.net #csv2["example.net."] = "db.example.net" # Naturally, we can have multiple zone files csv2["example.com."] = "db.example.com" # The address this DNS server runs on. If you want to bind # to multiple addresses, separate them with a comma like this: # "10.1.2.3, 10.1.2.4, 127.0.0.1" ipv4_bind_addresses = "127.0.0.4" # The directory with all of the zone files chroot_dir = "/etc/maradns" # If you want to enable recursion on the loopback interface, uncomment # the following line: recursive_acl = "127.0.0.1/8" $ askmara Aadivanshoptest.adivan-is.com. 127.0.0.4 # Querying the server with the IP 127.0.0.4 # Question: Aadivanshoptest.adivan-is.com. adivanshoptest.adivan-is.com. +86400 a 10.11.12.13 # NS replies: # AR replies: $ cat /etc/maradns/db.example.com adivanshoptest.adivan-is.com. 10.11.12.13 > The question is: does anybody know if maradns implies a length > limit on a segment of the name entry, or if there is any other > reason for this behavior? Yes. RFC1034/1035 say a DNS label can only be up to 63 characters long. I do not see this behavior. - Sam Note: I do not answer support requests sent by private email without being compensated for my time. I will discuss rates if you want this kind of support. Thank you for your understanding. Date: Tue, 10 Mar 2009 10:34:54 +0100 Subject: cache flush From: antonio anselmi To: list@NOSPAM.org I set my network to use opendns. I setup a very restrictive option so it blocked even all games sites. Yet for many hours (at least), I could still get games. Then, I rebooted the nodes and immediately games were blocked. So I did the reverse and unblocked games and see the same problem: games stayed blocked for many hours (at least) but were immediately unblocked when I rebooted the nodes. There seems to be some long-term caching going on? How can I periodically flush the cache? thanks for your help Date: Tue, 10 Mar 2009 08:56:54 -0600 Subject: Re: cache flush From: Sam Trenholme To: list@NOSPAM.org > How can I periodically flush the cache? You can periodically flush the cache by restarting MaraDNS. - Sam Note: I do not answer support requests sent by private email without being compensated for my time. I will discuss rates if you want this kind of support. Thank you for your understanding. Date: Tue, 10 Mar 2009 11:23:59 -0500 From: Ken Lyons - Graphix Wizard/Data-Forms To: list@NOSPAM.org Subject: Re: cache flush Don't know if this helps or not..but I have mine restart every 15 minutes... (inittab runs respawn mara... cron kills it's pid) that way any updates to the include files get updated, plus clear the cache. --I use automated script to add/edit dns entries Ken Sam Trenholme wrote: >> How can I periodically flush the cache? >> > > You can periodically flush the cache by restarting MaraDNS. > > - Sam > > Note: I do not answer support requests sent by private email without > being compensated for my time. I will discuss rates if you want this > kind of support. Thank you for your understanding. > > > > Date: Tue, 10 Mar 2009 17:08:20 +0100 (CET) Subject: Re: cache flush From: "Antonio Anselmi" To: list@NOSPAM.org thanks for the hints I tink to use cron in order to stop&start mara 'cos in some circumstances I need to stop all running daemons. is 15 mins timer a reasonable value in your real-life experiences? Antono On Tue, March 10, 2009 17:23, Ken Lyons - Graphix Wizard/Data-Forms said: > Don't know if this helps or not..but I have mine restart every 15 > minutes... > (inittab runs respawn mara... cron kills it's pid) > that way any updates to the include files get updated, plus clear the > cache. > --I use automated script to add/edit dns entries > > Ken > > > Sam Trenholme wrote: >>> How can I periodically flush the cache? >>> >> >> You can periodically flush the cache by restarting MaraDNS. >> >> - Sam >> >> Note: I do not answer support requests sent by private email without >> being compensated for my time. I will discuss rates if you want this >> kind of support. Thank you for your understanding. >> >> >> >> > Date: Tue, 10 Mar 2009 13:49:58 -0500 From: Ken Lyons - Graphix Wizard/Data-Forms To: list@NOSPAM.org Subject: Re: cache flush Antonio Anselmi wrote: > thanks for the hints > > I tink to use cron in order to stop&start mara 'cos in some > circumstances I need to stop all running daemons. > > is 15 mins timer a reasonable value in your real-life experiences? > I use two DNS servers both multi homed (per RFC). Haven't had any issues. I set my default TTL's for about 1 hour, (10min for dynadns hosts). And since both servers don't recycle in the same minute..one of them will take all the incoming requests while the other restarts. -- all of 10 seconds. I use a shell script wrapper (trigged from inittab ) on mara, with a -e flag. If a certain file /999-dns-down exists, it just sleeps for 60 seconds and exits instead of running mara. That way I can still shutdown DNS without it respawning or racing. If there are many requests for a dns update in the webadmin (over 30 updates), it can trigger a restart instead of waiting up to 14 minutes for the next batch. Ken > Antono > > On Tue, March 10, 2009 17:23, Ken Lyons - Graphix Wizard/Data-Forms said: > >> Don't know if this helps or not..but I have mine restart every 15 >> minutes... >> (inittab runs respawn mara... cron kills it's pid) >> that way any updates to the include files get updated, plus clear the >> cache. >> --I use automated script to add/edit dns entries >> >> Ken >> >> >> Sam Trenholme wrote: >> >>>> How can I periodically flush the cache? >>>> >>>> >>> You can periodically flush the cache by restarting MaraDNS. >>> >>> - Sam >>> >>> Note: I do not answer support requests sent by private email without >>> being compensated for my time. I will discuss rates if you want this >>> kind of support. Thank you for your understanding. >>> >>> >>> >>> >>> > > > > Date: Tue, 10 Mar 2009 19:31:48 +0100 (CET) Subject: Re: cache flush From: "Antonio Anselmi" To: list@NOSPAM.org so your mara start/stop script does remove/touch /999-dns-down it seems a good trick! Antonio On Tue, March 10, 2009 19:49, Ken Lyons - Graphix Wizard/Data-Forms said: > > Antonio Anselmi wrote: >> thanks for the hints >> >> I tink to use cron in order to stop&start mara 'cos in some >> circumstances I need to stop all running daemons. >> >> is 15 mins timer a reasonable value in your real-life experiences? >> > I use two DNS servers both multi homed (per RFC). Haven't had any > issues. I set my default TTL's for about 1 hour, > (10min for dynadns hosts). And since both servers don't recycle in > the same minute..one of them will take > all the incoming requests while the other restarts. -- all of 10 > seconds. > > I use a shell script wrapper (trigged from inittab ) on mara, with a > -e flag. > If a certain file /999-dns-down exists, it just sleeps for 60 > seconds and exits instead of running mara. > That way I can still shutdown DNS without it respawning or racing. > > If there are many requests for a dns update in the webadmin (over 30 > updates), > it can trigger a restart instead of waiting up to 14 minutes for the > next batch. > > > Ken > >> Antono >> >> On Tue, March 10, 2009 17:23, Ken Lyons - Graphix Wizard/Data-Forms >> said: >> >>> Don't know if this helps or not..but I have mine restart every 15 >>> minutes... >>> (inittab runs respawn mara... cron kills it's pid) >>> that way any updates to the include files get updated, plus clear >>> the >>> cache. >>> --I use automated script to add/edit dns entries >>> >>> Ken >>> >>> >>> Sam Trenholme wrote: >>> >>>>> How can I periodically flush the cache? >>>>> >>>>> >>>> You can periodically flush the cache by restarting MaraDNS. >>>> >>>> - Sam >>>> >>>> Note: I do not answer support requests sent by private email >>>> without >>>> being compensated for my time. I will discuss rates if you want >>>> this >>>> kind of support. Thank you for your understanding. >>>> >>>> >>>> >>>> >>>> >> >> >> >> > Date: Tue, 10 Mar 2009 12:46:48 -0600 Subject: Deadwood is now stable From: Sam Trenholme To: list@NOSPAM.org I have letting MaraDNS users that after over a year of development (OK, for most of 2008 that development was put on hold for personal reasons), Deadwood is now stable. Deadwood is the codebase that will (in theory) eventually become MaraDNS' next recursive resolver. Right now, the code does not have recursion (it needs to contact a recursive DNS server, such as the DNS server supplied by your ISP, to answer DNS question). However, it does have the following features MaraDNS does not have: * Thread-free code, which is important for some *NIXes that do not thread very well, and for embedded systems. * The ability to write the cache to and from a file * Full optional compile-time IPv6 support (Please thank Jean-Jacques Sarton for supplying this code) * TCP support provided by a separate helper program, also thread and fork-free (but non-caching) * "resurrection" support: The ability to pull an expired record from cache if it is impossible to contact an upstream DNS server. * A clean, easily maintained, and compact codebase. The code has a strong coding style enforced that makes the code more maintainable and manageable. * Correct handling of CNAME records * Small footprint. When compiled with -Os and stripped, the UDP binary is only about 27k in size; the TCP binary is about the same size. MaraDNS still has the following features that Deadwood does not have: * Full recursive support * TTL aging: MaraDNS reduces the TTLs of records so they are not cached as long until the records expire * Resource record rotation, which works as a crude load balancer Deadwood is available on the MaraDNS download page at http://www.maradns.org/download.html and also at http://www.maradns.org/deadwood Any comments of this program can be sent to the list. I hope people find this program useful. - Sam Note: I do not answer MaraDNS support requests sent by private email without being compensated for my time. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. From: "a uwl" To: list@NOSPAM.org Date: Sun, 15 Mar 2009 06:21:33 -0500 Subject: maradns-1.2.12.08 can't resolve some names Hello All, some days ago I installed the MaraDNS on my FreeBSD box from ports. pkg_info says: root@NOSPAM:/usr/local/etc # pkg_info | grep maradns maradns-1.2.12.08_1 DNS server with focus on security and simplicity I have too problems: (1) Sometimes some hosts, for example, www.google.de or cgi.ebay.de or some other hosts can't be resolved. But on second o third attemt the resolution working. As I can see, most (or all?) of these hosts are CNAMEs. (2) One host can't be resolved at all: russland-buecher.ru. I checked out this mailing list archive, but didn't found anything excepting "upgrade to 1.2.12.08" related to Debian. Therefore, I think, I did some configuration error. Sorry if it's a FAQ, but I didn't found a solution for me. Could somebody help me to resolve this issue? Very many thanks in advance! Hier is my config file: root@NOSPAM:/usr/local/etc # cat mararc | egrep -v "(^#|^$)" csv2 =3D {} csv2["dg.home."] =3D "db.dg.home" ipv4_bind_addresses =3D "127.0.0.1,192.168.188.3" chroot_dir =3D "/usr/local/etc/maradns" maradns_uid =3D 53 maradns_gid =3D 53 maxprocs =3D 96 no_fingerprint =3D 0 default_rrany_set =3D 3 max_chain =3D 8 max_ar_chain =3D 1 max_total =3D 20 verbose_level =3D 1 ipv4_alias =3D {} ipv4_alias["icann"] =3D "198.41.0.4, 192.228.79.201, 192.33.4.12, 128.8.10.90," ipv4_alias["icann"] +=3D "192.203.230.10, 192.5.5.241, 192.112.36.4," ipv4_alias["icann"] +=3D "128.63.2.53, 192.36.148.17, 192.58.128.30," ipv4_alias["icann"] +=3D "193.0.14.129, 198.32.64.12, 202.12.27.33" ipv4_alias["icann2"] =3D "198.41.0.4,192.228.79.201,192.33.4.12,128.8.10.90,192.203.230.10,192.5.5.2= 41,192.112.36.4,128.63.2.53,192.36.148.17,192.58.128.30,193.0.14.129,199.7.= 83.42,202.12.27.33" ipv4_alias["opennic"] =3D "157.238.46.24, 209.104.33.250, 209.104.63.249," ipv4_alias["opennic"] +=3D "130.94.168.216, 209.21.75.53, 64.114.34.119," ipv4_alias["opennic"] +=3D "207.6.128.246, 167.216.255.199, 62.208.181.95," ipv4_alias["opennic"] +=3D "216.87.153.98, 216.178.136.116" ipv4_alias["dg"] =3D "192.168.188.0/25" recursive_acl =3D "dg" random_seed_file =3D "/dev/urandom" root_servers =3D {} root_servers["."] =3D "icann2" ipv4_alias["azmalink"] =3D "12.164.194.0/24" ipv4_alias["hiddenonline"] =3D "65.107.225.0/24" spammers =3D "azmalink,hiddenonline" timeout_seconds =3D 10 CY vladi --=20 Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com Date: Mon, 16 Mar 2009 12:19:10 -0600 Subject: Re: maradns-1.2.12.08 can't resolve some names From: Sam Trenholme To: maradns list Thank you for bringing this to our attention. I need to give you some of MaraDNS' history and current development so you can understand what is going on. Back in 2001, I decided that MaraDNS really ought to have recursive DNS resolution, since this was a feature a DNS server should have. So, in the fall of 2001 I wrote all of this code and then Franky and myself did an extensive SQA process to stabilize the code and remove memory leaks from it. The code was quickly written, and resolved most name on the internet decently, but some things were tacked on, such as CNAME resolution. The plan was to rewrite the recursive code later on. Well, being an open source project, no one paid me to do this development, so I made other things in life a higher priority, such as going to the gym, graduating with a degree in computational linguistics magna cum luade, going to Mexico, getting a job and a girlfriend down here, etc. Because of this, the rewrite of the recursive resolver didn't start until late 2007. At the end of 2007 I was able to devote more personal time to this resolver, and had a basic non-recursive DNS cache done by the end of 2007. Life happened in 2008, and this recursive code (code named Deadwood) was on worked on a little this year, but I started using this code for my personal internet use and fixed some bugs I found during this use. At the end of 2008, I was in a position in my personal life where I was able to devote time to this code again, and finally released a stable version of this code a week ago. The code is in a lot of ways better than the original MaraDNS resolver, but doesn't have some features MaraDNS' resolver has, notably it need to use another recursive DNS server to process queries. This Deadwood code will eventually become MaraDNS' next-generation resolver. Right now, recursive resolution just isn't a priority for me and I'm working on other features, such as bona fide WIndows support and making the code modular so that one can make the code bigger or smaller depending on what features are needed. Once I start work on Deadwood's recursive code (no, there is no expected timeline) I will ask people to help me beta-test this code so that we don't have issues like this come up. Basically, there was a window in late 2001 where I paid serious attention to "this obscure site doesn't resolve with MaraDNS" bugs; however the code is written in such a way I had to make a lot of those sites WONTFIX. However, if someone is willing to sponsor MaraDNS development, I am willing to change MaraDNS' roadmap to accommodate the needs of my sponsor. For example, XeroBank recently sponsored adding to MaraDNS the ability to give a synthetic IP when it is impossible to resolve a given host name, or when a given host name does not exist. That said, I do feel a certain responsibility to fix critical (read: *critical*) bugs in MaraDNS. As recently as 2006, I made some changes to MaraDNS code to make it possible for MaraDNS to resolve a popular web site (microsoft.com). My experience is that when MaraDNS can't resolve a host at all, it's probably because there's something broken with the domain. > (1) Sometimes some hosts, for example, www.google.de or cgi.ebay.de or > some other hosts can't be resolved. But on second o third attemt the > resolution working. As I can see, most (or all?) of these hosts are > CNAMEs. Well, they resolve, so I don't consider this a serious as an issue where the host name doesn't resolve at all. However, I will look at these two host names later on this week, since they are both "Alexa top 500" sites (google.de is number 12 on the global Alexa list); if I can demonstrate that MaraDNS can resolve these sites (albeit with difficulty) I will close this bug as WONTFIX (but if you want to talk about sponsoring MaraDNS to fix this bug, we can talk about money in private email). > (2) One host can't be resolved at all: russland-buecher.ru. This site's Alexa rank is somewhere around 1,800,000, so I don't consider this critical. Again, if you want to talk about sponsoring MaraDNS to fix this bug, we can talk about money in private email. I will even list you on the MaraDNS sponsors page: http://www.maradns.org/sponsors.html And even on the front page if the sponsorship offer is generous enough. I encourage people to read my blog, where I talk about all the latest updates to MaraDNS and talk about my unpaid support boundaries: http://maradns.blogspot.com/2009/01/maradns-update-last-one-for-while.html http://maradns.blogspot.com/2009/01/maradns-support-boundaries-linux-rocks.html Basically, I generally only consider the inability to resolve a given host name critical (Read: Important enough for me to fix without being compensated for my time) if it's impossible to resolve the name at all, and if the site is an Alexa top 500 site. You may wish to read this thread to see an example of MaraDNS having a hard time with resolving some host names: http://woodlane.webconquest.com/pipermail/list/2009-January/000234.html I hope this helps people better understand the MaraDNS development process and why it is I'm reluctant to fix "this host does not resolve" bugs without being compensated for my time. - Sam From: "a uwl" To: "maradns list" Date: Mon, 16 Mar 2009 16:33:40 -0500 Subject: Re: maradns-1.2.12.08 can't resolve some names Dear Samvery many thanks! handle_noreply =3D 0 looks resolving the CNAME problem. I think the CNAME problem is serious enough. The answer from the resolver may be cached in the proxy server. The CNAME stays unresolvable until some user don't do shift-reload and renews the proxy cache.CYVladi --=20 Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com Subject: Writing a catch-all Date: Mon, 23 Mar 2009 15:35:34 -0500 From: "Patrick Goggins" To: I've just started using maradns and am trying to write a catch-all so all requests resolve to the same ip. =20 In the mararc file I have: csv2["%."] =3D "test.zone" =20 in the test.zone file I have: =20 % SOA % email@% 1 10 10 10 10 Testing. FQDN4 10.0.0.50 % FQDN4 10.0.0.50 =20 I startup maradns interactively without any issues but when I try to do a dig for any site it does not resolve the 10.0.0.50 address. =20 =20 =20 ~Patrick =20 Date: Mon, 23 Mar 2009 15:43:06 -0600 Subject: Re: Writing a catch-all From: Sam Trenholme To: list@NOSPAM.org > I've just started using maradns and am trying to write a catch-all so > all requests resolve to the same ip. Well, you can use csv2_default_zonefile to do this, or you can download and use a program far simpler than MaraDNS to do this: /*Placed in the public domain by Sam Trenholme*/ #include #include #define Z struct sockaddr #define Y sizeof(d) int main(int a,char **b){int i;char q[512],p[17 ]="\xc0\f\0\x01\0\x01\0\0\0\0\0\x04";if(a>1){a= socket(AF_INET,SOCK_DGRAM,0);struct sockaddr_in d;bzero(&d,Y);d.sin_port=htons(53);*((int *)(p+ 12))=inet_addr(b[1]);d.sin_family=AF_INET;bind( a,(Z*)&d,Y);socklen_t f=511;for(;;){i=recvfrom( a,q,255,0,(Z*)&d,&f);if(i>9&&q[2]>=0){q[7]++;q[ 2]|=128;memcpy(q+i,p,16);sendto(a,q,i+16,0,(Z*) &d,Y);}}}return 0;} (note that this will only work on a 32-bit machine) I have a more readable form of this program (that, yes, will work on a 64-bit machine and what not) which you are free to use here: http://www.samiam.org/software/microdns.html - Sam Subject: RE: Writing a catch-all Date: Mon, 23 Mar 2009 21:34:12 -0500 From: "Patrick Goggins" To: "Sam Trenholme" , Excellent! Just what I was looking for. ~Patrick -----Original Message----- From: list-bounces@NOSPAM.org [mailto:list-bounces@NOSPAM.org] On Behalf Of Sam Trenholme Sent: Monday, March 23, 2009 4:43 PM To: list@NOSPAM.org Subject: Re: Writing a catch-all > I've just started using maradns and am trying to write a catch-all so > all requests resolve to the same ip. Well, you can use csv2_default_zonefile to do this, or you can download and use a program far simpler than MaraDNS to do this: /*Placed in the public domain by Sam Trenholme*/ #include #include #define Z struct sockaddr #define Y sizeof(d) int main(int a,char **b){int i;char q[512],p[17 ]=3D"\xc0\f\0\x01\0\x01\0\0\0\0\0\x04";if(a>1){a=3D socket(AF_INET,SOCK_DGRAM,0);struct sockaddr_in d;bzero(&d,Y);d.sin_port=3Dhtons(53);*((int *)(p+ 12))=3Dinet_addr(b[1]);d.sin_family=3DAF_INET;bind( a,(Z*)&d,Y);socklen_t f=3D511;for(;;){i=3Drecvfrom( a,q,255,0,(Z*)&d,&f);if(i>9&&q[2]>=3D0){q[7]++;q[ 2]|=3D128;memcpy(q+i,p,16);sendto(a,q,i+16,0,(Z*) &d,Y);}}}return 0;} (note that this will only work on a 32-bit machine) I have a more readable form of this program (that, yes, will work on a 64-bit machine and what not) which you are free to use here: http://www.samiam.org/software/microdns.html - Sam h=mime-version:date:message-id:subject:from:to:content-type Date: Tue, 7 Apr 2009 13:56:45 -0500 Subject: Update on Deadwood (MaraDNS rewrite) From: Sam Trenholme To: maradns list Hello, everyone, This is just a quick update to let people know I've been steadily at work on Deadwood, the rewrite of MaraDNS. The UDP part of the code is now a fully functional Windows service when compiled in Windows, and is a very useful little (under 32k little) DNS cache both in CentOS 5 and as a native Windows XP (read: No Cygwin needed) binary. The code has some features MaraDNS doesn't have (resurrections, the ability to write the cache to disk, full Windows service support, non-threaded code) but doesn't have feature parity with MaraDNS yet (TTL again, RR rotation, and recursive DNS resolution). The code base is far cleaner and maintainable than MaraDNS, and much more pleasant to work with. The code seems rock stable to me, but getting more testing would be nice. It can be looked at here: http://www.maradns.org/deadwood I post updates about Deadwood here: http://maradns.blogspot.com/search/label/Deadwood And MaraDNS updates: http://maradns.blogspot.com/search/label/MaraDNS I am slowly but surely making Deadwood a fully functional DNS cache with a lot of features MaraDNS doesn't have. As always, since I am giving this program away under an open-source license, updates are done at my discretion and on my schedule. If you wish to direct MaraDNS/Deadwood development, sponsorship offers are currently being accepted at competitive rates, and patches will be considered. - Sam [You are getting this email because you are subscribed to the MaraDNS mailing list. If you don't want to get further mails like this, unsubscribe from this list.] To: list@NOSPAM.org From: Alexander Clouter Subject: Re: Update on Deadwood (MaraDNS rewrite) Date: Tue, 7 Apr 2009 20:19:18 +0100 Sam Trenholme wrote: > > [snipped] > > The code has some features MaraDNS doesn't have (resurrections, the > ability to write the cache to disk, full Windows service support, > non-threaded code) but doesn't have feature parity with MaraDNS yet > (TTL again, RR rotation, and recursive DNS resolution). > Regarding the 'cache to disk' bit, is it worth it? I would image the latency to use the disk as a cache is roughly in the same order of just making the query to the authoritive DNS server? Now, if you are instead talking about "write the cache to disk on shutdown for sweet and lovely restart", that's a whole different kettle of fish :) Good work never-the-less. Cheers [1] so you don't in effect flush the cache -- Alexander Clouter .sigmonster says: Life is like a simile. :date:message-id:subject:from:to:content-type h=mime-version:in-reply-to:references:date:message-id:subject:from:to Date: Wed, 8 Apr 2009 00:07:10 -0500 Subject: Re: Update on Deadwood (MaraDNS rewrite) From: Sam Trenholme To: list@NOSPAM.org > Regarding the 'cache to disk' bit, is it worth it? =A0I would image the > latency to use the disk as a cache is roughly in the same order of just > making the query to the authoritive DNS server? Actually, Deadwood doesn't do that because it doesn't really make sense to do that with a recursive cache (it's a different story with an authoritative database of records). > Now, if you are instead talking about "write the cache to disk on > shutdown for sweet and lovely restart", that's a whole different kettle > of fish :) Exactly. Deadwood has two features that make it easier to get DNS records when DNS servers on the internet are acting up: * Resurrections. If it's not possible to get a RR from the upstream DNS server, and we have an expired record in the cache, we will temporarily un-expire the record so that the user gets a record that probably still points to the site they want to reach. * Writing the cache to disk when shutting down Deadwood; reading the cache from disk when starting Deadwood. This allows the cache to stay around between computer reboots; this way, should a web site we went to three days ago no longer have working DNS servers, we can get the record from our cache file. The cache has a finite size and starts discarding records not recently accessed when it is filling up. Did you know that Bind 8 couldn't limit cache size and would just use more and more and more memory as more records were cached? My tentative plans are to add recursion to Deadwood, release a MaraDNS 2.0 which will be MaraDNS without recursion and Deadwood (this means it won't be possible to have the authoritative MaraDNS and Deadwood share the same IP). This will probably be released sometime in 2010. Since some people will still want the MaraDNS 1 behavior (same IP authoritative and recursive), I will continue to maintain a branch of MaraDNS 1. After MaraDNS 2.0, I currently plan to merge the Deadwood and MaraDNS authoritative code and have something that will have all the features of MaraDNS 1. At that point, I will decide on an end-of-life EOL timeline for MaraDNS 1. For distributors, there currently is no EOL for the 1.3.07 branch. The 1.2.12 branch of MaraDNS will be maintained until December 21, 2010; the only fixes for this branch are security and critical bugfixes. The 1.0 branch of MaraDNS is still maintained, but the only changes at this point are critical security fixes. 1.0 will be no longer available for download on the site after December 21, 2010. The extent of support I offer for MaraDNS 1 is pretty limited, and described here: http://maradns.blogspot.com/2009/01/maradns-update-last-one-for-while.html http://maradns.blogspot.com/2009/01/maradns-support-boundaries-linux-rocks.= html Basically, I'm concentrating all of my MaraDNS development energy rewriting the recursive half of MaraDNS 2, and you need to show me the money if you want more support or features added to the MaraDNS 1 code. - Sam To: list@NOSPAM.org From: Alexander Clouter Subject: Re: Update on Deadwood (MaraDNS rewrite) Date: Wed, 8 Apr 2009 11:12:22 +0100 Sam Trenholme wrote: > > [snipped] > > My tentative plans are to add recursion to Deadwood, release a MaraDNS > 2.0 which will be MaraDNS without recursion and Deadwood (this means > it won't be possible to have the authoritative MaraDNS and Deadwood > share the same IP). This will probably be released sometime in 2010. > Since some people will still want the MaraDNS 1 behavior (same IP > authoritative and recursive), I will continue to maintain a branch of > MaraDNS 1. > Does not really matter if the authoritative lives on 127.0.0.1 and you have similar functionality as you do in 1.3.x that effectively relays particular domains to particular IP's....it would need to be a 'pass through' non-caching option though. I would imagine that this would help keep the codebases very separate and the 'pass-though no cache' hack would be rather non-invasive. Anyway, cheers for the update [1] we need DNS views -- Alexander Clouter .sigmonster says: I smell a wumpus. :date:message-id:subject:from:to:content-type h=mime-version:in-reply-to:references:date:message-id:subject:from:to Date: Wed, 8 Apr 2009 12:30:16 -0500 Subject: Re: Update on Deadwood (MaraDNS rewrite) From: Sam Trenholme To: maradns list > Does not really matter if the authoritative lives on 127.0.0.1 and you > have similar functionality as you do in 1.3.x that effectively relays > particular domains to particular IP's....it would need to be a 'pass > through' non-caching option though. It matters if people have to materially change their MaraDNS configuration to update to a new version. My rule for software updates is that I don't like forcing users to make substantial changes to their configuration when upgrading. This is why MaraDNS 1 will still be (minimally) supported after 2.0 comes out so as to ease transition. My rule is three years of support for an older version once a new version compatible with the older version is released. > I would imagine that this would help keep the codebases very separate > and the 'pass-though no cache' hack would be rather non-invasive. I have some tentative plans on keeping the authoritative codebase separate and have it so I have to do the minimum amount of modifications to update things for MaraDNS 2.2. The mararc underlying parser has already been rewritten for Deadwood, so code that interacts with the parser (main() in MaraDNS) will be redone for MaraDNS 2.2. [1] > [1] we need DNS views It is going to take a few years for me to implement that, since that's a change to the authoritative code. [2] There's a lot of stuff the authoritative code needs: DNS views; the ability to reload zones without restarting MaraDNS (one of my sponsors asked me for this); full Notify, IXFR, and AXFR support. All of this matters, but it's more important right now to rewrite the recursive cache, since the recursive code was always "something that works until I can rewrite it", and got quite messy by the time it was able to reasonably well resolve names on the internet [3]. Just to let people know, I will not have access to email starting today until Sunday night or Monday, so will not be able to send replies. - Sam [1] MaraDNS 2.0 will be Deadwood with full recursion + MaraDNS with recursion disabled. [2] If someone is willing to sponsor me to do this, it would be quite expensive; you basically will have to hire me and it will then take three to six months of me working on the code eight hours a day, five days a week. [3] This is why I don't like making changes to the recursive code; the code needs to be rewritten; band-aid solutions to hosts that don't resolve are just that: Band aid solutions. It's akin to Windows ME at this point; the best thing we can do to move forward is to no longer use this code and rewrite the code from scratch. Which is what I've been doing on and off since 2007. h=mime-version:date:message-id:subject:from:to:content-type Date: Wed, 22 Apr 2009 12:26:21 -0500 Subject: Deadwood 2.3.01 released: Windows service; nocache From: Sam Trenholme To: list@NOSPAM.org Deadwood is the code base that will (hopefully) eventually become the next MaraDNS recursive resolver. Right now, it's a tiny (under 32k) combined binary with both caching (but not recursive) DNS-over-UDP support, and basic non-caching DNS-over-TCP support. The big changes from the 2.1 release of Deadwood is that both the DNS-over-UDP and DNS-over-TCP client are now one combined binary that looks at argv[0] to determine what mode to run in. In addition, there is full support for this program being a Windows XP service. Since I don't have regular access to Vista, there are no manifests for Vista's UAC. On the other hand, there is a document called Vista.txt that describes one way to install this program as a service in Vista. Since I'm no longer maintaining Deadwood-1, I have added a compile time flag, NOCACHE (as in -DNOCACHE) that disables all caching code, giving people a DNS forwarder akin to Deadwood-1. People who are interested in looking at this code are invited to go to Deadwood's web page: http://maradns.org/deadwood - Sam Subject: Question about delegating NS to another zone Date: Thu, 23 Apr 2009 16:58:57 -0400 From: "Summers, William" To: Sam, I was looking for clarification on how Mara handles a delegation from a subdomain to a nameserver in another zone using the authonly binary.=20 For example: xxxx.example.com=20 {SOA} xxxx.example.com. ns ns1.dnsprovider.com. xxxx.example.com. ns ns2.dnsprovider.com. In my initial tests Mara returns ns records, but, even with glue records I have not been able to get A records from the offsite ns. I also set +norecurse to see if the issue listed in the faq as "I have a NS delegation, and MaraDNS is doing strange things." I have experimented with dangling CNAME between ns1.xxxx.example.com and ns1.dnsprovider.com.=20 So far no luck returning dns records from the provider. Do I need to run the full binary?=20 I am not certain these are Mara issues, but was hoping for some insight since the FAQ pages refer to delegations only within the same zone. Thanks for such a great, secure system. :date:message-id:subject:from:to:content-type h=mime-version:in-reply-to:references:date:message-id:subject:from:to Date: Thu, 23 Apr 2009 16:16:19 -0500 Subject: Re: Question about delegating NS to another zone From: Sam Trenholme To: list@NOSPAM.org > I was looking for clarification on how Mara handles a delegation from a > subdomain to a nameserver in another zone using the authonly binary. Mara doesn't handle these things. If MaraDNS is authonly, MaraDNS doesn't return any records which aren't in MaraDNS' memory. In other words, if you have a NS sub-delegation by name, MaraDNS will only return the names, and not the IP addresses for these NS sub-delegations unless one adds local records in MaraDNS' memory. BIND has this way of looking on the internet for DNS records if it can't make a complete reply; for security reasons, MaraDNS doesn't do this and it's up to the user to make all of their replies are complete (no dangling CNAMEs, etc.) If you want to have MaraDNS as an authonly client return A records for NS records, the records need to be local. This is what the relevant lines in a CSV2 zone file would look like: sub.example.com. NS ns.example.org. sub.example.com. NS ns2.example.org. ns.example.org. A 10.1.2.3 ns2.example.org. A 10.1.2.4 - Sam Note: I do not answer MaraDNS support requests sent by private email without being compensated for my time. I will discuss rates if you want this kind of support. Thank you for your understanding. h=mime-version:date:message-id:subject:from:to:content-type Date: Thu, 30 Apr 2009 10:23:33 -0500 Subject: I'm looking for work in California From: Sam Trenholme To: maradns list Hello, MaraDNS users, It makes me very happy that people freely download and use MaraDNS, and even get free MaraDNS support from me and others here on this list. I'm letting people know that I'm ready to move back in California and am looking for work there. For people that may be able to hire me, or know someone who can hire me, my resume is here: http://samiam.org/resume/ There are other ways to help me. If you use MaraDNS in your enterprise or as an internet provider, I would like to know about it. If you use MaraDNS in an router or other device that is shipping, I want to know about it. If people are using MaraDNS professionally, this will make my resume look better. In addition, for people with embedded routers that can't handle threads, I have recently released Deadwood 2.3. This is a fully functional forwarding DNS server with low memory requirements that is under 32k in size when compiled in x86 [1] (25% of the size of dnsmasq). It also has full Windows support, running as a Windows service. Again, if people are using this code professionally, please let me know about it. Thank you everyone, for taking the time to read this email, and any assistance finding employment in California is greatly appreciated. I am continuing work on Deadwood and hope to have MaraDNS 2.0, with a completely rewritten caching and recursive code, out by the end of the year. - Sam [1] -Os; stripped h=mime-version:date:message-id:subject:from:to:content-type; Date: Tue, 19 May 2009 21:01:38 +0200 Subject: recursive not allowed From: Denis Barbazza To: list@NOSPAM.org Hi, i've a strange issue with maradns: (172.16.0.1 is maradns server) if I type: $ nslookup google.it ;; Got recursion not available from 172.16.0.1, trying next server Server: 81.29.230.5 Address: 81.29.230.5#53 Non-authoritative answer: Name: google.it Address: 216.239.59.104 if I type: $ nslookup google.it 172.16.0.1 Server: 172.16.0.1 Address: 172.16.0.1#53 Non-authoritative answer: Name: google.it Address: 216.239.59.104 Anyone could explain me what i have to do? thank you a lot in advance! this is my mararc file: csv1 = {} csv1["arizona.lignano."] = "db.arizona.lignano" bind_address = "0.0.0.0" chroot_dir = "/etc/maradns" maradns_uid = 65534 maxprocs = 96 no_fingerprint = 0 default_rrany_set = 3 max_chain = 8 max_ar_chain = 1 max_total = 20 verbose_level = 3 ipv4_alias = {} ipv4_alias["icann"] = "198.41.0.4,128.9.0.107,192.33.4.12,128.8.10.90,192.203.230.10,192.5.5.241,192.112.36.4,128.63.2.53,192.36.148.17,192.58.128.30,193.0.14.129,198.32.64.12,202.12.27.33" ipv4_alias["osrc"] = "199.166.24.1,205.189.73.102,199.166.24.3,207.126.103.16,195.117.6.10,205.189.73.10,204.57.55.100,213.196.2.97" ipv4_alias["alternic"] = "160.79.129.192,24.6.78.12,160.79.133.70,65.15.8.202,216.162.42.240,195.224.64.190,160.79.133.66,216.162.42.185" ipv4_alias["opennic"] = "131.161.247.226,209.151.84.102,64.247.218.140,64.247.218.149,209.104.33.250,209.104.63.249,209.151.84.103,199.175.137.211,207.6.128.246,65.243.92.254" ipv4_alias["localhost"] = "127.0.0.0/8" ipv4_alias["hotspot_lan"] = "172.16.0.0/24" recursive_acl = "localhost,hotspot_lan" random_seed_file = "/dev/urandom" maximum_cache_elements = 1024 upstream_servers = {} ipv4_alias["dns_provider"] = "81.29.230.5,81.29.230.1,151.99.125.1,151.99.0.100" upstream_servers["."] = "dns_provider" timeout_seconds = 2 -- Denis Barbazza :date:message-id:subject:from:to:content-type h=mime-version:in-reply-to:references:date:message-id:subject:from:to Date: Tue, 19 May 2009 14:10:50 -0500 Subject: Re: recursive not allowed From: Sam Trenholme To: maradns list > i've a strange issue with maradns: > ;; Got recursion not available from 172.16.0.1, trying next server Which version of MaraDNS are you using? Newer versions have fixed the issues with RD and RA bits being correctly set. If you're not using version 1.3.07.09, update. I *think* I fixed the RD/RA stuff in the 1.2 branch also, but 1.3 has a number of updates and is almost entirely backwards compatible with 1.2 (the only issues being obscure stuff like having ~ in TXT records) I would almost recommend updating to Deadwood [1] here, but am working on the bit where you locally resolve a particular domain with Deadwood right now. Next week sometime, I will post a follow-up telling you how to transfer this particular configuration to Deadwood. Thanks for the motivation to finish up the feature I'm implementing right now in Deadwood. - Sam [1] http://maradns.blogspot.com tells all; Deadwood is the new DNS code that will eventually become a part of MaraDNS 2.0, hopefully late this year. :date:message-id:subject:from:to:content-type; h=mime-version:in-reply-to:references:date:message-id:subject:from:to Date: Tue, 19 May 2009 21:28:17 +0200 Subject: Re: recursive not allowed From: Denis Barbazza To: Sam Trenholme , list@NOSPAM.org 2009/5/19 Denis Barbazza > > i've a strange issue with maradns: > > ;; Got recursion not available from 172.16.0.1, trying next server > > Which version of MaraDNS are you using? Newer versions have fixed the > issues with RD and RA bits being correctly set. > > I'm using this 1.2.12.04-1etch2 > > > now i'm going to try new version > > wow!!! fantastic! and thank you for the rapidity! now all is working ok. I've see that lenny come out with 1.3! Thank you again! -- Denis Barbazza From: "Ramil Abbasov" To: Subject: maraDNS and Solaris 9 Date: Wed, 10 Jun 2009 12:49:30 +0400 I have a trouble with installing maradns 1.3.07.09 at SPARC machine = (Enterprise 420) with Solaris 9. After ./configure I got the following: WARNING WARNING WARNING This is an unknown platform. MaraDNS may or may not compile on this platform. So maradns doesn't know about Solaris 9! Or I'm making mistake ... Hm = ... After "make" command I got the following: cd libs ; make "CC=3Dcc -O2 -Wall" DEBUG=3D-DNO_FLOCK ; cd ../dns ; make = "CC=3Dcc -O2 -Wall" DEBUG=3D-DNO_FLOCK ; cd ../rng ; make "CC=3Dcc -O2 = -Wall" DEBUG=3D-DNO_FLOCK ; cd ../parse ; make "CC=3Dcc -O2 -Wall" = DEBUG=3D-DNO_FLOCK ; cd ../qual ; make "CC=3Dcc -O2 -Wall" = DEBUG=3D-DNO_FLOCK ; cd ../server ; make "CC=3Dcc -O2 -Wall" = DEBUG=3D-DNO_FLOCK "VERSION=3D1.3.07.09" COMPILED=3D\""SunOS system at = Wed Jun 10 12:40:56 AZST 2009"\" ; cd ../tools ; make "CC=3Dcc -O2 = -Wall" DEBUG=3D-DNO_FLOCK ; cd ../tcp ; make "CC=3Dcc -O2 -Wall" = DEBUG=3D-DNO_FLOCK "VERSION=3D1.3.07.09" ; cat ../00README.FIRST cc -O2 -Wall -c -o JsStr.o JsStr.c=20 In file included from JsStr.c:7: JsStr.h:129: error: syntax error before "u_int32_t" JsStr.h:132: error: syntax error before "js_readuint32" JsStr.h:132: warning: type defaults to `int' in declaration of = `js_readuint32' JsStr.h:132: warning: data definition has no type or storage class JsStr.h:133: error: syntax error before "u_int32_t" *** Error code 1 make: Fatal error: Command failed for target `JsStr.o' Current working directory = /export/home/ramil/maradns/maradns-1.3.07.09/libs *** Error code 1 make: Fatal error: Command failed for target `all' I would be very appretiated if the problem solved or explained. Many thanks. Ramil Abbasov :date:message-id:subject:from:to:content-type h=mime-version:in-reply-to:references:date:message-id:subject:from:to Date: Wed, 10 Jun 2009 12:39:43 -0500 Subject: Re: maraDNS and Solaris 9 From: Sam Trenholme To: list@NOSPAM.org > JsStr.h:129: error: syntax error before "u_int32_t" First of all, the only platforms I fully support is CentOS 5 (MaraDNS 1.0 was fine on Solaris; MaraDNS 1.2 may or may not compile there, and good luck with MaraDNS 1.3). I also have partial support for Microsoft Windows. Other platforms: Unless you're willing to help sponsor MaraDNS, you're on your own (we can discuss rates in private mail if you want to go this route). If fixing this issue is important enough for you, you either pay me or take the source, make the appropriate changes and, if you're feeling extra nice, submit a patch to the list. And, if I'm feeling extra nice, I might even make the patch part of MaraDNS. Or maybe someone else on the list can help you. My first impression: You might not have the older BSD u_int32_t types. The solution might be to use and change u_int32_t to uint32_t. - Sam Note: I do not answer MaraDNS support requests sent by private email without being compensated for my time. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. :date:message-id:subject:from:to:content-type h=mime-version:in-reply-to:references:date:message-id:subject:from:to Date: Thu, 11 Jun 2009 01:41:55 -0500 Subject: Re: maraDNS and Solaris 9 From: Sam Trenholme To: list@NOSPAM.org >> JsStr.h:129: error: syntax error before "u_int32_t" > My first impression: You might not have the older BSD u_int32_t types. > =9AThe solution might be to use and change u_int32_t to > uint32_t. OK, talking to myself, but this was an issue back when MaraDNS supported Solaris. To wit: /* Solaris needs u_int32_t and u_int16_t defined */ #ifdef SOLARIS #ifndef _uint_defined typedef unsigned int u_int32_t; typedef unsigned short u_int16_t; #define _uint_defined #endif /* _uint_defined */ #endif /* SOLARIS */ But I think this would look better something like this: /* Solaris needs u_int32_t and u_int16_t defined */ #ifdef SOLARIS #ifndef _uint_defined #include typedef uint32_t u_int32_t; typedef uint16_t u_int16_t; #define _uint_defined #endif /* _uint_defined */ #endif /* SOLARIS */ - Sam Note: I do not answer MaraDNS support requests sent by private email without being compensated for my time. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type; Date: Thu, 25 Jun 2009 22:26:54 -0300 From: Marlon To: list@NOSPAM.org Subject: Deadwood and Maradns compiled with ICC This is a multi-part message in MIME format. --------------060205090308020708020407 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I succefully compiled deadwood-2.3.04 and maradns-1.3.13 using ICC, any thoughts about how to benchmark them ? Follow the Makefiles for icc attached. Regards, Marlon --------------060205090308020708020407 Content-Type: text/plain; name="Makefile_deadwood.icc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Makefile_deadwood.icc" # Makefile for Deadwood-2 # The compiler that makes programs designed to run on the machine # compiling. When cross-compiling, we still need to compile and # run programs on the build machine, so change the next line when # cross-compiling. export CC="icc" export FLAGS=${ICCCFLAGS} HOSTCC=$(CC) OBJS=DwStr.o \ DwMararc.o \ DwRadioGatun.o \ DwSocket.o \ DwUdpSocket.o \ DwTcpSocket.o \ DwSys.o \ DwHash.o all: DwMain DwTcp Test version.h # Since some systems may not have /dev/urandom (Windows, *cough* *cough*), we # keep a randomly generated prime around clean: rm -f Test DwMain DwTcp *.exe *.o a.out RandomPrime writehash_test* \ dw_cache *stackdump core Makefile foo* ; ./make.version.h ; \ if [ -e /dev/urandom ] ; then rm DwRandPrime.h ; \ cc RandomPrime.c ; ./a.out > DwRandPrime.h ; rm a.out ; fi version.h: ./make.version.h DwStr.o: DwStr.c DwStr.h $(CC) $(FLAGS) -Wall -c -o DwStr.o DwStr.c DwMararc.o: DwMararc.c DwMararc.h $(CC) $(FLAGS) -Wall -c -o DwMararc.o DwMararc.c DwRadioGatun.o: DwRadioGatun.c DwRadioGatun.h DwStr.h $(CC) $(FLAGS) -Wall -c -o DwRadioGatun.o DwRadioGatun.c DwTcpSocket.o: DwTcpSocket.c DwStr.h DwSocket.h $(CC) $(FLAGS) -Wall -c -o DwTcpSocket.o DwTcpSocket.c DwUdpSocket.o: DwUdpSocket.c DwStr.h DwSocket.h $(CC) $(FLAGS) -Wall -c -o DwUdpSocket.o DwUdpSocket.c DwSocket.o: DwSocket.c DwStr.h DwSocket.h $(CC) $(FLAGS) -Wall -c -o DwSocket.o DwSocket.c DwSys.o: DwSys.c DwStr.h $(CC) $(FLAGS) -Wall -c -o DwSys.o DwSys.c RandomPrime: RandomPrime.c $(CC) -O3 -o RandomPrime RandomPrime.c DwRandPrime.h: RandomPrime if [ -e /dev/urandom ] ; then ./RandomPrime > DwRandPrime.h ; fi DwHash.o: DwHash.c DwStr.h DwRandPrime.h DwHash.h $(CC) $(FLAGS) -Wall -c -o DwHash.o DwHash.c Test: Test.c DwStr.o DwStr.h DwStr_functions.h $(OBJS) $(CC) $(FLAGS) -Wall -o Test Test.c $(OBJS) DwMain: DwMain.c $(OBJS) DwStr_functions.h version.h $(CC) $(FLAGS) -Wall -o DwMain DwMain.c $(OBJS) DwTcp: DwMain ln -s DwMain DwTcp --------------060205090308020708020407 Content-Type: text/plain; name="Makefile_maradns.icc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Makefile_maradns.icc" VERSION=1.3.13 COMPILED="Linux system at Tue Jun 23 23:42:29 BRT 2009" COMPILED_DEBUG="Linux system at Tue Jun 23 23:42:29 BRT 2009 (Debug)" # Server objects SOBJECTS=server/MaraBigHash.o # js_string library (buffer overflow resistant string library) objects JOBJS=libs/JsStr.o libs/JsStrOS.o libs/JsStrCP.o # MaraHash (assosciative array) library objects MHOBJS=libs/MaraHash.o # Parser objects POBJECTS=parse/ParseMaraRc.o parse/ParseCsv1.o ../parse/ParseIpAcl.o # DNS query processing library objects DOBJECTS=dns/Queries.o dns/Compress.o dns/bobbit.o # Secure random number generator objects ROBJECTS=rng/rng-api-fst.o rng/rng-alg-fst.o OBJECTS=$(JOBJS) $(MHOBJS) $(SOBJECTS) $(DOBJECTS) $(POBJECTS) $(DOBJECTS) $(ROBJECTS) EXECS=server/maradns # Uncomment the following three lines to get this to compile on Solaris # LDFLAGS=-lxnet # CC=gcc $(LDFLAGS) -DSELECT_PROBLEM # M="CC=$(CC)" # These are currently unused, but will be needed again if we use flock() again # CFLAGS=-I/usr/ucbinclude # L="CC=$(CC) $(CFLAGS)" # LDFLAGS=-L/usr/ucblib -lucb -lxnet # end the Solaris section # Non-Solaris version of "M" V="VERSION=$(VERSION)" Q="DEFINES=-DSELECT_PROBLEM" # Debug #FLAGS = -O2 -Wall -DSELECT_PROBLEM export CC="icc" export FLAGS=${ICCCFLAGS} HOSTCC=$(CC) M="CC=$(CC) $(FLAGS)" D="CC=$(CC) $(FLAGS) -DDEBUG -DTHREADS" #FLAGS = -g all: cd libs ; make $(M) ; cd ../dns ; make $(M) ; \ cd ../rng ; make $(M) ; cd ../parse ; make $(M) ; \ cd ../qual ; make $(M) ; cd ../server ; \ make $(M) $(V) COMPILED=\"$(COMPILED)\" ; \ cd ../tools ; make $(M) ; \ cd ../tcp ; make $(M) $(V) ; cat ../00README.FIRST debug: cd libs ; make $(D) DEBUG="-DDEBUG -DTHREADS" ; \ cd ../dns ; make $(D) ; cd ../rng ; make $(D) ; \ cd ../parse ; make $(D) ; cd ../qual ; make $(D) ; \ cd ../server ; \ make $(D) $(Q) $(V) COMPILED=\"$(COMPILED_DEBUG)\" ; \ cd ../tools ; make $(D) ; \ cd ../tcp ; make $(D) $(V) ; cat ../00README.FIRST clean: rm -f $(OBJECTS) core $(EXECS) ; \ cp build/Makefile.w Makefile ; cd dns ; make clean ; \ cd ../libs ; make clean ; cd ../parse ; make clean ; \ cd ../qual ; make clean ; \ cd ../server ; make clean ; \ cp Makefile.recursive Makefile ; \ cd ../test ; make clean ; \ cd ../tools ; make clean ; \ cd misc ; make clean ; \ cd ../../utf8 ; make clean ; \ cd ../tcp ; make clean ; \ cd ../rng ; make clean ; \ cd ../sqa ; make clean ; \ # ; cd .. ; find . -type d | grep .deps | xargs rm -fr ; find . -name '*.o' | xargs rm strip: cd server; strip maradns ; cd ../tcp ; \ strip zoneserver getzone fetchzone ; \ cd ../tools ; strip askmara install: VERSION=$(VERSION) ./build/install.sh uninstall: VERSION=$(VERSION) ./build/uninstall.sh --------------060205090308020708020407-- :date:message-id:subject:from:to:content-type h=mime-version:in-reply-to:references:date:message-id:subject:from:to Date: Thu, 25 Jun 2009 22:55:02 -0500 Subject: Re: Deadwood and Maradns compiled with ICC From: Sam Trenholme To: list@NOSPAM.org I'm really pleased to hear that! I will make the makefiles part of tomorrow's Deadwood snapshot and part of MaraDNS 1.3.14. I assume you don't mind me putting the same copyright on these files as with other MaraDNS and Deadwood files: http://www.maradns.org/license.html (Note to self: Since 1.0 is only updated for critical security holes, just call this the "MaraDNS license") The other issue I want to resolve in MaraDNS 1.3.14 is the usage of sys/types.h and the obsolete u_int32_t forms for integers where the size is important; these days it makes more sense to use stdint.h and the uint32_t forms (just as Deadwood does), since these cause problems compiling MaraDNS on unsupported [1] platforms > I =A0succefully compiled deadwood-2.3.04 and maradns-1.3.13 using ICC, an= y > thoughts about how to =A0benchmark them ? Good question. Perhaps number of DNS queries one can compress a second or some such. Once I finish the compression code, which I've been working on the last two weeks, and should finish up this weekend. - Sam [1] Unsupported is a relative term; it simply means "if you want me to give you a good answer to your concern with MaraDNS on this platform [2], you'll have to pay me for my time to setup a VMware virtual machine running that platform so I can test things." [2] MaraDNS and Deadwood are developed in CentOS 5 and tested in CentOS 5 and Windows XP (using mingw)