From test24 at mail.ru Tue Nov 2 13:14:23 2010 From: test24 at mail.ru (test24) Date: Tue, 02 Nov 2010 20:14:23 +0300 Subject: =?koi8-r?Q?How_to_resolve_the_DNS_zone_in_Deadwood=3F?= Message-ID: > Piece of my Deadwood config: > > # > # Servers we connect to > > upstream_servers = {} > upstream_servers["my.tv."] = "10.10.1.1" # master NS for > TV. zone > upstream_servers["."] = "192.168.1.1," # for other ns > upstream_servers["."] += "192.168.1.2" # for other ns > > > when nslookup my.tv > Server: localhost > Address: 127.0.0.1 > > Name: my.ctv > > but where is IP for my.ctv ??? > > > And when > nslookup my.tv 10.10.1.1 > Server: UnKnown > Address: 10.10.1.1 > > Name: my.tv > Address: 10.10.1.15 > > > How to get the ip of my.tv From strenholme.usenet at gmail.com Tue Nov 2 20:50:57 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Tue, 2 Nov 2010 18:50:57 -0600 Subject: How to resolve the DNS zone in Deadwood? In-Reply-To: References: Message-ID: >> upstream_servers = {} >> upstream_servers["my.tv."] = "10.10.1.1" ? # master NS for >> TV. zone >> upstream_servers["."] = "192.168.1.1," ? ? # for other ns >> upstream_servers["."] += "192.168.1.2" ? ? # for other ns This looks good. Since you're using the += operator, make sure you're using Deadwood 3.0.01 (+= had problems in 2.9 releases of Deadwood) >> when nslookup my.tv The nslookup output you're giving us doesn't tell us enough to fix your problem. Things *should* work with the above configuration (if it didn't, Deadwood 3.0.01 would not have been released because it would have failed the dwood2rc_d_upstream_servers test). It's a good idea to use "dig" instead of nslookup. Dig is included with any modern Linux/BSD/whatever distribution. If using Windows, install Dig for Windows. Directions are here: http://woodlane.webconquest.com/pipermail/list/2010-July/000623.html Please show us the full "dig" output for the queries you sent us. - Sam From test24 at mail.ru Wed Nov 3 04:59:19 2010 From: test24 at mail.ru (test24) Date: Wed, 03 Nov 2010 11:59:19 +0300 Subject: =?koi8-r?Q?Re[2]=3A_How_to_resolve_the_DNS_zone_in_Deadwood=3F?= In-Reply-To: References: Message-ID: > >> upstream_servers = {} > >> upstream_servers["my.tv."] = "10.10.1.1" # > master NS for > >> TV. zone > >> upstream_servers["."] = "192.168.1.1," # for > other ns > >> upstream_servers["."] += "192.168.1.2" # for > other ns > > This looks good. Since you're using the += operator, make sure you're > using Deadwood 3.0.01 (+= had problems in 2.9 releases of Deadwood) I use latest Deadwoods version (to my mind) - from 24.09.2010/19:47/size 65024/Deadwood.exe > > >> when nslookup my.tv > > The nslookup output you're giving us doesn't tell us enough to fix > your problem. Things *should* work with the above configuration (if > it didn't, Deadwood 3.0.01 would not have been released because it > would have failed the dwood2rc_d_upstream_servers test). > dwood3rc configuration: max_ar_chain = 1 dns_port = 53 upstream_port = 53 tcp_listen = 0 recurse_min_bind_port = 12000 recurse_number_ports = 16384 upstream_servers = {} upstream_servers["my.tv."] = "10.10.1.1" # NS for my.tv with seved Master zone on it upstream_servers["."] = "10.10.1.2," # NS for others upstream_servers["."] += "10.10.1.3" # NS1 for others recursive_acl = "127.0.0.1/16," # Loopback Network recursive_acl += "10.10.1.1/24" # Local Network random_seed_file = "secret.txt" max_inflights = 32 maxprocs = 2048 tcp_listen = 0 max_tcp_procs = 1024 handle_noreply = 0 handle_overload = 0 filter_rfc1918 = 1 reject_aaaa = 1 resurrections = 1 reject_mx = 0 num_retries = 3 timeout_seconds = 4 timeout_seconds_tcp = 8 ttl_age = 1 verbose_level = 9 > It's a good idea to use "dig" instead of nslookup. Dig is > included > with any modern Linux/BSD/whatever distribution. If using Windows, > install Dig for Windows. Directions are here: > > http://woodlane.webconquest.com/pipermail/list/2010-July/000623.html > > Please show us the full "dig" output for the queries you sent us. > > - Sam So, with this configuration of deadwood i use nslookup ang dig in WinXP upstream_servers["my.tv."] = "10.10.1.1" # NS for my.tv with seved Master zone on it upstream_servers["."] = "10.10.1.2," # NS for others upstream_servers["."] += "10.10.1.3" # NS1 for others F:\DNS\nslookup my.tv 10.10.1.10 (Deadwood IP) Server: NS_Local Address: 10.10.1.10 Name: my.tv nslookup my.tv 10.10.1.1 *** Can't find server name for address 10.10.1.1: Non-existent domain Server: UnKnown Address: 10.10.1.1 Name: my.tv Address: 10.10.1.1 ================================ C:\Communic\DNS\Benchmark\Dig>dig @10.10.1.10 my.tv 10 (ASK Deadwood DNS) ; <<>> DiG 9.3.2 <<>> @10.10.1.10 my.tv ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 828 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;my.tv. IN A ;; AUTHORITY SECTION: my.tv. 0 IN SOA z.my.tv. y.my.tv. 1 1 1 1 1 ;; Query time: 0 msec ;; SERVER: 10.10.1.10#53(10.10.1.10) ;; WHEN: Wed Nov 03 10:41:10 2010 ;; MSG SIZE rcvd: 113 C:\Communic\DNS\Benchmark\Dig>dig @10.10.1.1 my.tv ; <<>> DiG 9.3.2 <<>> @10.10.1.1 my.tv ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1053 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;my.tv. IN A ;; ANSWER SECTION: my.tv. 3600 IN A 10.10.1.1 ;; AUTHORITY SECTION: tv. 3600 IN NS ss.tv. ;; ADDITIONAL SECTION: ss.tv. 3600 IN A 10.10.10.10 ;; Query time: 15 msec ;; SERVER: 10.10.1.1#53(10.10.1.1) ;; WHEN: Wed Nov 03 10:41:54 2010 ;; MSG SIZE rcvd: 73 ======================================= On master side ; ; BIND data file for local loopback interface ; $TTL 3600 @ IN SOA tv. admin.tv. ( 2010102202 ; Serial 8H ; Refresh 1D ; Retry 2W ; Expire 1D ) ; Negative Cache TTL IN NS ss.tv. ;@ IN A 10.10.1.10 ss IN A 10.10.10.10 my IN A 10.10.1.1 Where is the mistake? Thank you. Proposition: Cached NS (Deadwood) together with Authoritative server (MaraDNS) = new version of GOOD NS named DeadDNS (from DEADwood+maraDNS=DeadDNS) ;) From strenholme.usenet at gmail.com Wed Nov 3 10:25:13 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 3 Nov 2010 08:25:13 -0600 Subject: How to resolve the DNS zone in Deadwood? In-Reply-To: References: Message-ID: Thank you for the detailed information. > filter_rfc1918 = 1 This (which is enabled by default) tells Deadwood to never resolve private 192.168.x.x, 172.16-31.x.x, and 10.x.x.x IP addresses (which are described in RFC1918, hence the name). This is a security feature; if we allow a DNS server used on the real-world Internet to resolve these kinds of IPs, it opens us up to certain kinds of attacks: http://crypto.stanford.edu/dns/ If you have a need to resolve these kinds of IPs, please have filter_rfc1918 = 0 > ;; AUTHORITY SECTION: > my.tv. ? ? ? ? ? ? ? ? 0 ? ? ? IN ? ? ?SOA ? ? z.my.tv. y.my.tv. 1 1 1 1 1 Whenever Deadwood generates a reply it looks like this, it indicates that Deadwood is generating a synthetic "this host does not exist" reply. This can be done under a variety of circumstances. For example: * If reject_aaaa is set and someone asks for an AAAA (IPv6 address) record * If Deadwood gets a response from an upstream server which is blank and the RCODE isn't SERVER FAIL * If an IP specified in ip_blacklist is seen in the upstream reply (this feature exists to counteract NXDOMAIN redirection) * If, as happened in your case, a 192.168.x.x, 172.16-32.x.x, or 10.x.x.x IP is seen in the reply and filter_rfc1918 is not 0. > Proposition: > Cached NS (Deadwood) together with Authoritative server (MaraDNS) = new version of GOOD NS named DeadDNS > (from DEADwood+maraDNS=DeadDNS) ;) Thank you for the kind words. - Sam From test24 at mail.ru Wed Nov 3 11:17:24 2010 From: test24 at mail.ru (test24) Date: Wed, 03 Nov 2010 18:17:24 +0300 Subject: =?koi8-r?Q?Re[4]=3A_How_to_resolve_the_DNS_zone_in_Deadwood=3F?= In-Reply-To: References: Message-ID: Wed, 3 Nov 2010 08:25:13 -0600 ?????? ?? Sam Trenholme : > Thank you for the detailed information. > > > filter_rfc1918 = 1 > > This (which is enabled by default) tells Deadwood to never resolve > private 192.168.x.x, 172.16-31.x.x, and 10.x.x.x IP addresses (which > are described in RFC1918, hence the name). This is a security > feature; if we allow a DNS server used on the real-world Internet to > resolve these kinds of IPs, it opens us up to certain kinds of > attacks: > > http://crypto.stanford.edu/dns/ > > If you have a need to resolve these kinds of IPs, please have filter_rfc1918 = > 0 But if I set recursive_acl = "127.0.0.1/16," recursive_acl += "192.168.55.1/24," # Local Network recursive_acl += "192.168.56.1/24," # WiFi Network recursive_acl += "10.10.1.1/24" # Users Network ONLY to allow connections from Local network and does not allow DNS connections from the Internet to Deadwood what do you think about that ? > > ;; AUTHORITY SECTION: > > my.tv. 0 IN SOA z.my.tv. y.my.tv. 1 1 1 1 > 1 > > Whenever Deadwood generates a reply it looks like this, it indicates > that Deadwood is generating a synthetic "this host does not exist" > reply. > > This can be done under a variety of circumstances. For example: > > * If reject_aaaa is set and someone asks for an AAAA (IPv6 address) record > > * If Deadwood gets a response from an upstream server which is blank > and the RCODE isn't SERVER FAIL > > * If an IP specified in ip_blacklist is seen in the upstream reply > (this feature exists to counteract NXDOMAIN redirection) > > * If, as happened in your case, a 192.168.x.x, 172.16-32.x.x, or > 10.x.x.x IP is seen in the reply and filter_rfc1918 is not 0. > > > Proposition: > > Cached NS (Deadwood) together with Authoritative server (MaraDNS) = new > version of GOOD NS named DeadDNS > > (from DEADwood+maraDNS=DeadDNS) ;) > > Thank you for the kind words. > > - Sam From test24 at mail.ru Wed Nov 3 11:26:44 2010 From: test24 at mail.ru (test24) Date: Wed, 03 Nov 2010 18:26:44 +0300 Subject: local HOSTS file as stupid DNS IN A name resolver in Deadwood In-Reply-To: References: Message-ID: may Deadwood resolve (or it may be as a proposition too) from local hosts. file (such as in /etc or \Windows\system32\drivers\etc directories) ? From wsummers at deerfield.edu Tue Nov 9 11:03:52 2010 From: wsummers at deerfield.edu (Summers, William) Date: Tue, 9 Nov 2010 11:03:52 -0500 Subject: controlling responses to ANY queries Message-ID: Greetings Sam, First off thank you for Mara. We're seeing a rash of issues with mail servers from Yahoo.com. They unable to send to our domain because of a bug in qmail that sends an ANY query before doing MX lookups. If the ANY query return is larger than 512 bytes, qmail won't send and bounces the message with CNAME lookup error- CNAME lookup failed temporarily. (#4.4.3) I'm not going to try again; this message has been in the queue too long. I understand this is really a poor systems management issue with yahoo. From reading various posts, this a widely known issue, and a variety of patches have existed for over a decade. Since they are unreliable- is it possible to control the ANY query response size in Mara? thank you again. Ps. Congrats on the new job! From KenL at GraphixWizard.com Wed Nov 10 14:54:59 2010 From: KenL at GraphixWizard.com (Ken Lyons - Graphix Wizard/Data-Forms) Date: Wed, 10 Nov 2010 14:54:59 -0500 Subject: Round Robin Weight In-Reply-To: <2010-313-11-0-1289318769-010835@GWIZFL.ORG> References: <2010-313-11-0-1289318769-010835@GWIZFL.ORG> Message-ID: <2010-314-14-5-1289418739-013707@GWIZFL.ORG> Congrats to Sam on the job. I've been using mara for about 5 or 6 years now, and been using the round robin method to load balance on a multi-homed network. One of connections is now much larger than the other and I'd like to set a higher weight in the DNS replies. say 2:1 I tried adding extra (identical) records to stack the deck but no change. Short of adding another IP is their a weight or other option that would work? #ROUND ROBIN BELOW, one name, two addresses pop3-server.ABC.org. A 1.1.1.1 pop3-server.ABC.org. A 2.2.2.2 #Direct name to each IP on the two networks pop3-server-a.ABC.org. A 1.1.1.1 pop3-server-b.ABC.org. A 2.2.2.2 Ken Lyons From strenholme.usenet at gmail.com Wed Nov 10 21:55:51 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 10 Nov 2010 19:55:51 -0700 Subject: controlling responses to ANY queries In-Reply-To: References: Message-ID: > First off thank you for Mara. We're seeing a rash of issues with mail servers from Yahoo.com. They unable to send to our domain because of a bug in qmail that sends an ANY query before doing MX lookups. Some historical background: It's not a bug. It's a workaround for a bug in ancient versions of BIND (The feature was added to Qmail in 1996 to work around a bug in versions of BIND earlier than 4.9.4) [1] > Since they are unreliable- is it possible to control the ANY query response size in Mara? Mara does try and control the ANY response size by removing the NS and AR sections of the reply to an ANY query. Unfortunately, Mara has a bug where the corner case of having any ANY query that's larger than 512 bytes is not handled at all (not only does it not give a proper truncated reply back, but also "zoneserver" does not appear to let these packets through via DNS-over-TCP). Unfortunately, my plate is pretty full and I don't know when I will have time to fix Mara's handling of oversized ANY packets. The only fix in place right now is to remove records until the ANY query fits in 512 bytes. > Ps. Congrats on the new job! I am very pleased to have it and I would not have it today if I did not work on Mara for so many years. - Sam [1] http://homepages.tesco.net/J.deBoynePollard/Softwares/qmail/#any-to-cname From strenholme.usenet at gmail.com Wed Nov 10 21:59:53 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 10 Nov 2010 19:59:53 -0700 Subject: Round Robin Weight In-Reply-To: <2010-314-14-5-1289418739-013707@GWIZFL.ORG> References: <2010-313-11-0-1289318769-010835@GWIZFL.ORG> <2010-314-14-5-1289418739-013707@GWIZFL.ORG> Message-ID: > I've been using mara for about 5 or 6 years now, and been using the round > robin method to load balance on a multi-homed network. Both MaraDNS and Deadwood allow crude load balancing via rotation of resource records. It's a cool feature but one that I would not have implemented today if I knew then what I know now--it has caused bugs to pop up, both in MaraDNS and in Deadwood. > One of connections is now much larger than the other and I'd like to set a > higher weight in the DNS replies. ?say ?2:1 > I tried adding extra (identical) records to stack the deck but no change. > Short of adding another IP is their a weight or other option that would > work? One option is to use a TCP load balancer to give one IP three times the weight of the other IP. Another is to use SRV records, but I don't think there is widespread browser support for those. - Sam From m.ferlitsch at gmail.com Thu Nov 11 12:25:32 2010 From: m.ferlitsch at gmail.com (Markus Ferlitsch) Date: Thu, 11 Nov 2010 18:25:32 +0100 Subject: dnssec Message-ID: hi, does maradns also support dnssec? greets, markus From strenholme.usenet at gmail.com Thu Nov 11 19:54:58 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 11 Nov 2010 17:54:58 -0700 Subject: dnssec In-Reply-To: References: Message-ID: > does maradns also support dnssec? http://www.maradns.org/deadwood/doc/FAQ.txt From m.ferlitsch at gmail.com Fri Nov 12 02:24:35 2010 From: m.ferlitsch at gmail.com (Markus Ferlitsch) Date: Fri, 12 Nov 2010 08:24:35 +0100 Subject: dnssec In-Reply-To: References: Message-ID: ok, thx! maybe one day you will implement it :-) greets, Markus 2010/11/12 Sam Trenholme > > does maradns also support dnssec? > > http://www.maradns.org/deadwood/doc/FAQ.txt > From strenholme.usenet at gmail.com Fri Nov 12 09:26:16 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 12 Nov 2010 07:26:16 -0700 Subject: dnssec In-Reply-To: References: Message-ID: > ok, thx! maybe one day you will implement it :-) For future reference, and for people lurking on this mailing list, I have added a search feature (courtesy of Google) at the bottom of this page: http://www.maradns.org/notes.html Typing in DNSSEC in this page, for example, gives the answer to Markus' question as the first hit. If one prefers querying Google directly, the secret to getting a MaraDNS question answered quickly is to add "site:maradns.org" to the end of one's query. For example, Markus would have instantly gotten an answer to his question by typing in the following at Google's search box: "DNSSEC site:maradns.org" (Without the quotes; in Google searches, quotes means "return this *exact* phrase", which is not what is needed here). - Sam From strenholme.usenet at gmail.com Sat Nov 13 02:06:40 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Sat, 13 Nov 2010 00:06:40 -0700 Subject: local HOSTS file as stupid DNS IN A name resolver in Deadwood In-Reply-To: References: Message-ID: > may Deadwood resolve (or it may be as a proposition too) from local hosts. file > (such as in /etc ?or \Windows\system32\drivers\etc ?directories) ? No, Deadwood does not support this. Something similar, however, can be done: http://www.maradns.org/tutorial/recursive.html#privateroot Also, there is a lot of documentation for MaraDNS and Deadwood that is really work looking over and reading: http://www.maradns.org/notes.html http://www.maradns.org/deadwood/doc/ - Sam From m.ferlitsch at gmail.com Tue Nov 16 10:01:50 2010 From: m.ferlitsch at gmail.com (Markus Ferlitsch) Date: Tue, 16 Nov 2010 16:01:50 +0100 Subject: zonecheck - question Message-ID: Hi, today I have tried a zonecheck. What does this warning means? ---- * Nameservers are all part of the same AS* - *Adv: ZoneCheck * *To avoid losing all connectivity with the authoritative DNS in case of a routing problem inside your Autonomous System, it is advised to host the DNS on different AS.* - *All the nameservers are part of the same Autonomous System (AS number 6830), try to have some of them hosted on another AS.* - *generic* ---- Some months ago I didn't get this warning - but I also didn't change my maradns settings - it seems that the zonecheck-tool got some upgrade. PS: I use three maradns servers - 2 static IPs are from one provider in different towns and the thiwd server ist hosted at any other provider. greets, Markus From remco at webconquest.com Tue Nov 16 11:57:47 2010 From: remco at webconquest.com (Remco Rijnders) Date: Tue, 16 Nov 2010 17:57:47 +0100 Subject: zonecheck - question In-Reply-To: References: Message-ID: <20101116165747.GA19983@winter.webconquest.com> On Tue, Nov 16, 2010 at 04:01:50PM +0100, Markus Ferlitsch wrote: > today I have tried a zonecheck. > > What does this warning means? > > ---- > * > Nameservers are all part of the same AS* > > - *Adv: ZoneCheck > * > > *To avoid losing all connectivity with the authoritative DNS in case of a > routing problem inside your Autonomous System, it is advised to host the DNS > on different AS.* > > > - > > *All the nameservers are part of the same Autonomous System (AS number > 6830), try to have some of them hosted on another AS.* > > > - *generic* > > ---- > > Some months ago I didn't get this warning - but I also didn't change my > maradns settings - it seems that the zonecheck-tool got some upgrade. > > PS: I use three maradns servers - 2 static IPs are from one provider in > different towns and the thiwd server ist hosted at any other provider. Hi Markus, You can safely ignore this warning. It just means that all 3 IP addresses are owned / controlled by the same entity (UPC). Should UPC have a major routing issue, your DNS might become unavailable (but I guess at that time your ISP will be well aware of that issue!). As long as the servers are in different locations (different datacenters in different cities) you'll most likely be ok. If you run mara on a unix box, and have the 'whois' program installed, you can run for fun: whois AS6830 . You'll see this is quite big a network object importing many other AS objects. I guess the zonecheck warning comes from this. Cheers, Remco From m.ferlitsch at gmail.com Tue Nov 16 14:22:04 2010 From: m.ferlitsch at gmail.com (Markus Ferlitsch) Date: Tue, 16 Nov 2010 20:22:04 +0100 Subject: zonecheck - question In-Reply-To: <20101116165747.GA19983@winter.webconquest.com> References: <20101116165747.GA19983@winter.webconquest.com> Message-ID: Ok, thanks for detailed explication! 2010/11/16 Remco Rijnders > On Tue, Nov 16, 2010 at 04:01:50PM +0100, Markus Ferlitsch wrote: > > today I have tried a zonecheck. > > > > What does this warning means? > > > > ---- > > * > > Nameservers are all part of the same AS* > > > > - *Adv: ZoneCheck > > * > > > > *To avoid losing all connectivity with the authoritative DNS in case > of a > > routing problem inside your Autonomous System, it is advised to host > the DNS > > on different AS.* > > > > > > - > > > > *All the nameservers are part of the same Autonomous System (AS number > > 6830), try to have some of them hosted on another AS.* > > > > > > - *generic* > > > > ---- > > > > Some months ago I didn't get this warning - but I also didn't change my > > maradns settings - it seems that the zonecheck-tool got some upgrade. > > > > PS: I use three maradns servers - 2 static IPs are from one provider in > > different towns and the thiwd server ist hosted at any other provider. > > Hi Markus, > > You can safely ignore this warning. It just means that all 3 IP addresses > are owned / controlled by the same entity (UPC). Should UPC have a major > routing issue, your DNS might become unavailable (but I guess at that time > your ISP will be well aware of that issue!). As long as the servers are in > different locations (different datacenters in different cities) you'll > most likely be ok. > > If you run mara on a unix box, and have the 'whois' program installed, you > can run for fun: whois AS6830 . You'll see this is quite big a network > object importing many other AS objects. I guess the zonecheck warning > comes from this. > > Cheers, > > Remco > From nino80 at gmail.com Mon Nov 22 12:36:42 2010 From: nino80 at gmail.com (n j) Date: Mon, 22 Nov 2010 18:36:42 +0100 Subject: Csv2 zonefile syntax check In-Reply-To: References: Message-ID: Hello, MaraDNS doesn't feature a switch or a separate tool which just takes a zone file and checks it for syntax errors, is that correct? It is a nice-to-have feature for a startup script - don't kill the existing daemon if you can't load the new configuration. BTW, my first post here as a fresh MaraDNS user - great software, glad you got the job, and pity for stopping the development (though totally understandable). Best wishes, -- Nino From nino80 at gmail.com Tue Nov 23 18:18:56 2010 From: nino80 at gmail.com (n j) Date: Wed, 24 Nov 2010 00:18:56 +0100 Subject: RFC2317-style reverse zone mapping Message-ID: I noticed that maradns doesn't like RFC2317-style reverse zone mappings, i.e. slash character in particular: 0/25.3.2.10.in-addr.arpa NS ns.example.com results in: Error: Unexpected character Error is on line 6 in file test.zone context of error: 16/ (closing this file) Error: Problem getting hostname Error is on line 6 in file test.zone context of error: 16/ (closing this file) To be constructive, I found a workaround by modifying csv2_is_alphanum() in Csv2_parse.c to allow slash: /* Match on [0-9a-zA-Z\-\_] */ int csv2_is_alphanum(int32 in) { return (csv2_is_alpha(in) || csv2_is_number(in) || in == '-' || in == '_' || in == '/'); } The question is, is this safe to do? Will it maybe cause problems in parsing slash commands (though I haven't noticed any)? Thanks, -- Nino From strenholme.usenet at gmail.com Sat Nov 27 11:25:47 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Sat, 27 Nov 2010 10:25:47 -0600 Subject: Csv2 zonefile syntax check In-Reply-To: References: Message-ID: > MaraDNS doesn't feature a switch or a separate tool which just takes a > zone file and checks it for syntax errors, is that correct? > > It is a nice-to-have feature for a startup script - don't kill the > existing daemon if you can't load the new configuration. Keep in mind that, unless started with an external "daemonizer" like Duende, MaraDNS places on standard output all messages. So, to have something like this is simply a matter of either: * Having a program send MaraDNS a TERM signal a few seconds after starting, and putting MaraDNS' output in a file, grepping for problems. This can be easily done in Bash: maradns > foo & sleep 5 kill %1 * Making a "hacked" compile of MaraDNS with an exit(0) before the part of the code that waits for packets on port 53. Use this modified compile to check for errors before starting the real MaraDNS. > BTW, my first post here as a fresh MaraDNS user - great software, glad > you got the job, and pity for stopping the development (though totally > understandable). True enough. However, I still fix bugs in MaraDNS when I have time. Right now, I know of the following problems in MaraDNS: * MaraDNS does not correctly handle the corner case of having too many records to answer an authoritative ANY query too large to fit in a 512-byte DNS packet. * Deadwood is having a hard time resolving *.ebay.com queries. The issue appears to be because Deadwood does not use cached CNAME entries to speed up resolving a name (if one has "example.com +86400 CNAME example.net" and "example.net +300 A 10.1.2.3", Deadwood needs to contact two instead of one nameserver to resolve example.com five minutes later, even though that CNAME stays in Deadwood's cache for a day) * Deadwood can not resolve urbandictionary.com. The issue here appears to be that concatenating the CNAME chain that urbandictionary.com with the long list of IPs urbandictionary.com has results in a packet that does not fit in 512 bytes. * Deadwood's built-in "DNSwall" functionality only filters RFC1918 IPs, and not all IPs an attacker may use with the "resolve a name to a local IP to escalate privileges" attack. I actually have already fixed this, but I need to make sure people updating know about the impact of this change. I hope to, in a couple of months, have a new MaraDNS release with these issues resolved. - Sam