Wednesday, September 29, 2010

Yes, open source is a win-win

Open source is a win-win.

I am very pleased to let the MaraDNS community know that I have successfully gotten a job offer which I just accepted this week. This is a job offer which I would not have gotten if I had not kept my skills current while living in Mexico by continuing to develop MaraDNS, culminating with a three-year-long complete rewrite of the recursive code.

The timing for getting this offer is perfect. As I planned to do a year ago, now that MaraDNS 2.0 is out the door, I will put MaraDNS on the back burner. This will give me more time to be a productive worker at my new job and refine my programming knowledge to master new technologies, keeping my skills current in the 2010s.

I am going to continue to support MaraDNS, of course. I will fix important bugs brought up on the mailing list, and will naturally fix any critical security bug that may be found in MaraDNS. I will also answer emails on the mailing list when and if I have time to do so. But, I do not have any plans to add new features to MaraDNS at this time.

I would like to thank all MaraDNS users for all of your comments, feedback, bug reports, and feature requests. I have devoted a lot of the last decade to MaraDNS, and it has been an honor to freely give to the world something which I hope people find useful.

Open source development truly pays off. It’s a win for users, since they have good code which they can change any way they see fit; it’s a win for developers, because it allows them to showcase their work and demonstrate their programming discipline to prospective employers. I encourage people who are looking to improve their programming skills to become part of an open-source project. It can be frustrating at times; but it is also rewarding.

Tuesday, September 28, 2010

MaraDNS 2.0.01 released

I have released MaraDNS 2.0.01. This is simply MaraDNS 1.4 with the deprecated MaraDNS 1.x recursive DNS server removed, and with the documentation updated to reflect the fact that Deadwood 3 is now used for MaraDNS’ recursion. People, of course, are free to use MaraDNS 1.4 for as long as they want, but its recursive code is now deprecated and only supported for critical security updates.

I encourage users of MaraDNS to use Deadwood for all recursion with MaraDNS.

Sunday, September 26, 2010

Friday, September 24, 2010

Deadwood 3.0.01 released

I have released Deadwood 3.0.01 today. With this release made, no new features will be added to the Deadwood recursive resolver for the foreseeable future. However, bug fixes and other routine maintenance will still be applied to this software package.

Deadwood is now a stable recursive resolver suitable for embedded systems, desktop PCs, or on internet servers. Deadwood is fully 64-bit compatible, has optional support for IPv6, and does not require threads to resolve records.

Deadwood 3.0.01 will be the recursive resolver for MaraDNS 2.0, which I will release shortly, as well as being an optional recursive DNS server to use in MaraDNS 1.4.

It has been a pleasure developing Deadwood and MaraDNS for nearly a decade. I will continue to support MaraDNS and Deadwood but have no plans to add new features once MaraDNS 2.0 is released.

In addition, I no longer need to accept donations for MaraDNS. All Deadwood and MaraDNS support needs to be done via the MaraDNS mailing list.

The 3.0.01 release of Deadwood is available here:

Wednesday, September 22, 2010

New Deadwood snapshot: Parser bugs fixed

I have been uploading new Deadwood snapshots to fix some bugs in the dwood3rc parser; the parser now has the += (append) operator work correctly with dictionary variables, as well as having more stringent controls for dictionary indexes (dictionary variables must be initialized; a dictionary index can not be appended to without first being set; etc.) so that dwood3rc files must be working Python 2 scripts to correctly parse.

In addition, I have refined the documentation a little.

They can be looked at here:

Monday, September 20, 2010

New Deadwood snapshot: Two questions and answers added to FAQ

I have uploaded a Deadwood snapshot today that adds two questions and answers to the FAQ. One is about blacklisting domains with Deadwood, and the other is a brief note about how, as much as I would like Deadwood to have DNSSEC support, I am not in a place in my life where I have the time to implement DNSSEC “for fun and for free”.

The updated FAQ can be looked at here:

Thursday, September 16, 2010 is a scam

For people looking for work, beware of I got hit by their scam when I was looking for work last week. Based on the various reviews about this company out there about this company, I can safely say that they are a scam.

The scam works like this: has a number of job postings on their web site; once you sign up with them, they quickly send you an email that they have looked at your resume. They then tell you that your resume sucks, and that you should pay them $400 to improve your resume to have a chance in the job market.

They give this form letter to everyone who signs up for one of their postings on their site, giving out a letter like this: “Your resume does not pass the 30-second test, and the content is not up to the standards one would expect from a candidate like you. Countless studies have proven that resume quality is the key determinant as to whether a candidate is selected to be interviewed. Your resume needs a boost from a visual, content, and overall writing standpoint to engage the reader. It needs to make them want to learn more about you. I didn’t find it to be exciting, and it didn’t make me want to run to the phone to call you. In short, your resume is effectively sabotaging your job search.”

It does not matter how well-written one’s resume is. It does not matter if one has the best resume that was ever made. After has their spambot scan your resume, they give you the above scathing criticism. Indeed, according to one anonymous poster, resumes written by’s own resume writers get the above very negative review.

Googling the exact above phrase gives multiple results. Why am I not surprised?

Sunday, September 12, 2010

Deadwood on OpenWRT; The case for 32-bit Skein

When I was designing Deadwood, I made sure to make the program work really nicely on 32-bit processors, while retaining compatibility on 64-bit processors. In the places where word size really matters, namely the hash compression function and the cryptographic random number generator, I went out of my way to use 32-bit algorithms (my own home-grown algorithm for the 32-bit hash compression function; RadioGatun[32] for the random number generator).

During Deadwood’s development cycle, I even gave a nod to systems that can work with both 16-bit and 32-bit numbers, by having it so “int” in the source code means “something that can fit in 16 bits”, and using int32_t for anything that would need more than 16 bits (near the end of the Deadwood development cycle, I went from “int32_t” to “int_fast32_t” for “integer that needs more than 16 bits”). This is untested—I don’t think there are any systems in use today capable of routing packets that have 16-bit wide registers—but allows it to be at least possible to port Deadwood to a 16-bit system.

The reason for all this attention to detail was because my target platform while developing Deadwood was to have it run nicely on the 32-bit router in the corner used to connect people to the internet. And, I have succeeded.

Sebastian Müller has already gotten Deadwood to recursively process queries on an embedded router and is working on porting Deadwood to a number of platforms. He was able to pull this off in a single afternoon because Deadwood is, from beginning to end, an architecture-independent recursive DNS server optimized for 32-bit platforms.

Of course, Deadwood also runs nicely on 64-bit platforms; one of my regressions I perform when building Deadwood is to make sure nothing breaks in 64-bit. The only issue is that some operations (the hash compression, the cryptographic random number generator) are less efficient because they were written to run on 32-bit systems. [1]

Now, while Deadwood does run nicely on various 32-bit embedded systems, I unfortunately can not readily support these configurations because I run Deadwood on x86_32 and can not solve problems for people running it on different systems. It works, but people want to do this are on their own and need to take responsibility for any problems they see.

This leads us to Skein, a proposed hash primitive for SHA-3. Skein is a very good hash with a lot of features, including having, in its core, Threefish, the only tweakable block cipher primitive that appears secure.

However, I can’t use Skein because there’s no native 32-bit version of it, even though such a thing is possible. When I pointed out this problem on Schneier’s blog, I was dismissed by another poster with “all 32-bit desktop processors (and even some ARM chips) have instructions that can do math on pairs of 64-bit numbers”.

That’s all well and good, but Deadwood isn’t just for the desktop. It’s also for the embedded 32-bit space and that means no MMX/SSE instructions that work on 64-bit numbers.

One of the reasons why I feel so frustrated is because I can’t just make a 32-bit Skein variant. Not without possibly making 10 different errors that could destroy its security.

I understand why Schneier, et. al. don’t feel comfortable coming out with some rotation constants to make a 32-bit Skein variant; if they did make such a Skein variant and some cryptographers found weaknesses in them, it would make them look bad. So, they are being very conservative about what they will declare to be the official “magic numbers” for Skein. Numbers I simply do not feel comfortable changing.

If I were to use one of the SHA-3 submissions for Deadwood’s PRNG, I would use Keccak. Like Skein, it can output a stream of infinite length from any input of any length. Unlike Skein, it is more 32-bit compatible; not only is there a 32-bit “reduced word length” variant officially blessed by the algorithm’s creators, but also 64-bit Keccak more easily scales down to 32-bits than Skein, since the only operations done are permutes, rotates, and exclusive ORs.

32-bits is still very much a reality today. While the transition to 64-bit desktops is well underway, it will be a few years before 64-bit desktops become more common than 32-bit desktops. The embedded space is very slowly letting go of 8-bit systems, replacing them with 32-bit systems. I wouldn’t be surprised if 32-bit is still around in 2038, when we will have to worry about systems with 32-bit time_t overflowing (Deadwood will run until 2143 on systems with a 32-bit time_t, uses 64-bit timestamps internally, and won’t overflow in 2143 if compiled on a system with a 64-bit time_t).

Yes, we are making the transition to 64-bit. But we can’t make the transition with solutions like Skein that pretend 32-bit no longer exists.

[1] In terms of making a full 64-bit port of Deadwood, I would have to:
  • Make most, but not all, of the int32_t declarations int_fast32_t declarations (64-bit compilers should make int_fast32_t 64 bits wide)
  • Use RadioGatun[64] instead of RadioGatun[32] (because of how I wrote the RadioGatun code, this is a fairly quick change)
  • Replace the hash compression core with one using 64-bit instead of 32-bit operations. The most difficult part of this is making a 63-bit random prime number; we can quickly brute-force test the primality of a 31-bit number, but not for a 63-bit number.
No, I don’t have plans to do this before MaraDNS 2.0 is released.

Friday, September 10, 2010

New Deadwood snapshot: Improved documentation

I just uploaded a Deadwood snapshot; this snapshot has updated and improved the Deadwood manpage (typos corrected; Windows Reference.txt version of manpage updated). In addition, I have added install.bat and uninstall.bat batch files to the Windows port of Deadwood, and revised README.txt for Windows accordingly, so Windows XP users can now install (or remove) Deadwood with just one click.

It can be looked at here:

Update: I just tested this in Windows 7, and Deadwood is not a one-click nor two-click install, since right-clicking on a .bat file and choosing “run as administrator” changes the current working directory to \WINDOWS\system32. To install on Windows 7:
  • Go to the start menu and search for “cmd”
  • When found, rick click on it and run “cmd” as an administrator
  • At the cmd prompt, use the “cd” command to find and enter the directory where Deadwood is unpacked
  • Invoke the “install.bat” script from this directory
I will have to update Vista.txt and README.txt to point out how to install Deadwood in Windows 7 (and, presumably, Windows Vista) in the next couple of days.

An eulogy for DNScurve

OpenDNS is probably the strongest DNScurve proponent out there. So, when they start making moves to look for a DNSSEC engineer (as an aside, the position is no longer open; they finally convinced one of their own engineers to implement DNSSEC, probably while holding their nose), you know that DNSSEC has won.

DNScurve, with all due respect, never had a chance. It didn’t have a chance when I last talked about it a year ago. It’s downright moribund today.

Sure, on a technical level it has some really cool technology—in particular, I really like the (2^(255)) - 19 curve it uses for cryptography; a “stock” DNS packet can only fit 512 bytes of information (we can make the packet about 1280 bytes in size if we use EDNS), so a public key cryptographic primitive that offers strong security without needing to push around 3072-bit RSA signatures (the approximate size needed with RSA to get the same level of security as DJB’s “25519” curve) is very appealing.

But, unfortunately, standards are not judged solely on their technical merits. They are also judged on how well the people who work on the standards get along and are willing to make compromises.

DJB, as far as I can tell, was never willing to work with other people on DNScurve. He wanted it to be an end-to-end DJB-exclusive invention: His own “25519” curve for public key cryptography, his own Salsa20 stream cipher for encryption (a nice enough cipher, but it uses 32-bit words everywhere and doesn’t have a mode using 64-bit words), and his own “Poly1305”.

To top it off, DJB didn’t even implement a reference implementation of DNScurve. He wasn’t even willing to walk far enough outside of his ivory tower to make an implementation, make said implementation public, and allow people to see how it ran in the real world.

And, indeed, no one else implemented DNScurve either. The most notable implementation of DNScurve was GbDNS, but that was replaced by something called “QRP” a year ago. OpenDNS was the only other place that implemented DNScurve, but they’re now looking to implement DNSSEC.

DNScurve also suffered from being a solution looking for a problem. The only real issue DNScurve solved was the problem of being able to sniff DNS traffic and spoofing replies based on the traffic seen. It didn’t solve the problem of an upstream DNS server sending spoofed traffic. Quite bluntly, this is a problem OpenDNS’ current business model doesn’t want to see solved (they make their money from NX redirects and from having point to their own web page), so it’s no surprise they advocated DNScurve for as long as they did.

DNSSEC, on the other hand, is already seeing wide adoption. BIND has always supported it, of course, and Unbound supports it. GbDNS also now has gone from supporting DNScurve to support DNSSEC. PowerDNS is getting DNSSEC support.

If things in my life ever change and I got a six-month paid sabbatical, I would also implement DNSSEC and make it part of Deadwood; I regret the fact I don’t have time to make a compact pure-C implementation of DNSSEC.

If you want to make a standard real, work with standards committees. I know DJB can do this; his excellent Salsa20 cipher is part of the eSTREAM portfolio (but, again, I’d like to see a 64-bit Salsa20, or, even better, a 64-bit version of Cha-Cha I would call Merengue, or even Merequetengue). It’s a shame he didn’t do the same with DNScurve. Hopefully, the 25519 curve can become a public key algorithm used in future revisions to the DNSSEC standard.

- Sam

Thursday, September 9, 2010

Deadwood 2.9.07 released: Faster resolution, better security

I have released Deadwood 2.9.07 today. Compared to Deadwood 2.9.06, this release offers:
  • Faster resolution speeds. I have fixed two significant bugs which measurably slowed down Deadwood’s resolution performance; now Deadwood has, on my home internet connection, performance better than Unbound (it took Deadwood 2.9.07 159 seconds to resolve a list of names; Unbound 1.4.6 needed 169 seconds to resolve this list).
  • Better security. The underlying hash compression function uses a “secret” number in its core that is usually only changed whenever a new Deadwood release is made. I have updated this code to now have another “secret” number that is changed every time Deadwood is started.
  • Spam zombie protection. For over a year, there was a bug in Deadwood that broke MX records. Not only have I fixed this bug in Deadwood 2.9.07, I also have set up Deadwood to disable MX records by default, since they are generally only used by email hubs and “zombie” computers spewing spam.
This release can be downloaded here:

Wednesday, September 8, 2010

New Deadwood snapshot: Resolve speeds comparable to Unbound

It looks like I have solved the issues people have reported with Deadwood being sluggish. The two bugs I fixed were one where Deadwood would delay timeout_seconds (normally 2 seconds) if there was a problem getting an upstream IP from its cache, and another where Deadwood would delay timeout_seconds if there were upper case letters in the name of a DNS reply.

I just ran Juergen’s test with Deadwood and Unbound. Deadwood is able to resolve the list of domain names on my network in 2:42 (two minutes forty-two seconds) and 2:54 (the 2:42 figure was done starting Deadwood with no cache); Unbound needed 2:57 to resolve the same list. In addition, namebench shows Deadwood doing a lot better than Unbound (far fewer lost queries and better average response time to the queries Deadwood does resolve) on my machine.

Steve Gibson’s DNS benchmark tool is buggy and incorrectly reports that Deadwood drops most DNS packets; I have set up Deadwood to report every reply it sends as well as every incoming query, and have verified that Deadwood replies to most, if not all, of its incoming queries when Gibson’s DNS benchmark is run against it.

In addition, I have revised Deadwood’s internal hash algorithm to be more secure: The algorithm, in addition to using a multiplication constant that randomly changes every time Deadwood is compiled in CentOS Linux or a new Deadwood release is made (which Deadwood has always done), now uses an additive constant that is different every time Deadwood is started. Deadwood is hard-coded to use /dev/urandom (secret.txt in Windows systems) for entropy to generate this additive constant from (we also get a bit of entropy from the timestamp); if this file is not found, Deadwood will fallback to using a hard-coded additive constant for its core hash.

I would like to thank Juergen Daubert, Wayne, and Marlon for their bug reports, feedback, and suggestions getting programs to help debug Deadwood’s performance.

The snapshot can be downloaded here:

Windows users can use this snapshot that has the improved performance (but not the improvements to Deadwood’s internal hashing function):

Please report any bugs to the mailing list [1].

- Sam

[1] Crash reports are useless unless they are accompanied by a stack trace or a recipe for reproducing the crash; Valgrind errors are invalid unless Deadwood is compiled with -DVALGRIND_NOERRORS

Note: Yeah, I’m still looking for work. Send me an email if you have a job for me.

Update: Anyone who downloaded deadwood-H-20100908-3 should download deadwood-H-20100908-4; this update is a hotfix that fixes dictionary variables which I broke in deadwood-H-20100908-3. Note also that dictionary variables work with the most recent Windows binary; it was the improved hash compression security which temporarily broke dictionary variables.

Yes, I do perform regressions to catch things like this, but only for numbered release (e.g. I’ll do the regressions before releasing Deadwood 2.9.07) and not for snapshot releases.

Monday, September 6, 2010

New Deadwood snapshot: Queries nearly three times faster

There has been some discussion today about the fact Deadwood, while very good at resolving names in general, is a good deal slower than other DNS servers.

Looking at the code, I already found the #1 offender that was responsible for about two thirds of the slowdown, and have patched this bug in today’s Deadwood snapshot. Anyone who feels Deadwood is a bit sluggish is encouraged to download and use today’s snapshot.

In addition, one issue that I have been thinking about for a while is that the hash compression function is not quite random enough. So, I’ve revised the hash compression core to add a random 16-bit number for each iteration of the hash compression. The number is randomly generated with Deadwood’s secure PRNG (Read: RadioGatún[32]) and is different every time Deadwood is started.

Deadwood snapshots can be looked at here:

Sunday, September 5, 2010

New Deadwood snapshot: MX record lookups disabled by default

Over the years, people have reported issues using MaraDNS as part of a mail hub, processing MX queries. This is a manner of using MaraDNS which I plain simply do not perform, and therefore have not adequately tested. The fact that releases of Deadwood with broken MX lookup support have been out for over a year, with no one letting me know about this bug on the MaraDNS mailing list (or me becoming aware of it myself with my own “dogfood” testing; I only became aware of it when I decided to make a MX lookup with Deadwood on a lark) indicate that this is not something widely used, much less tested.

My general feeling is that, if an average client machine is making a MX query, most likely it has been taken over by a spambot sending out spam. I have been using Microsoft Outlook and other MUAs (mail user agents) with Deadwood for over a year while its MX processing was broken and never saw a problem; a MUA does not perform MX lookups to send mail, but instead connects to the SMTP server, which does the actual MX lookups.

That in mind, in today’s snapshot of Deadwood, I have explicitly disabled MX lookups; if an MX lookup is made, the query is rejected and the IP is logged as being a possible spam zombie. There is a parameter which I have documented that will enable MX lookups again.

The fact of the matter is this: Using Deadwood with a mail hub making a large number of MX requests is completely untested. If one wants to use Deadwood in this manner, please subscribe to the MaraDNS mailing list and express the intention to help beta-test Deadwood for this use case which I do not have.

In the meantime, by disabling and logging MX lookups in Deadwood, we can make networks a little more secure and resistant to spam zombies commandeering machines on our networks.

Saturday, September 4, 2010

New Deadwood snapshot: Non-A records now resolve

I guess not that many people are testing Deadwood.

Let me be honest about the type of testing I’m doing with Deadwood: I am testing Deadwood’s as a DNS server used for casual web surfing on today’s internet. That means that most of the queries done are A queries; I don’t do much testing with AAAA (IPv6) queries because, quite bluntly, my ISP doesn’t offer IPv6 service and I can think of only one site on the Internet with an AAAA record:

Likewise, I haven’t done any testing with MX records. I haven’t touched MX records at all because I’m not using Deadwood with a mail hub. So, it came as an unpleasant shock to me when I discovered last night that Deadwood hasn’t been properly resolving MX records for over a year.

In Deadwood 2.4.05 (released August 9, 2009), I added the ability to rotate resource records. Unknown to me, this feature broke Deadwood with any variable-length record, such as a MX record pair where the hostnames are of different lengths.

The advantage of using Deadwood’s robust string library with almost all of Deadwood’s DNS processing is that this bug did not result in any memory corruption or cause any other problems; the only issue has been that Deadwood would not resolve MX or other variable length records.

The idea that some freetards advocate that open source software is magically tested and that all bugs become shallow is nothing more than so much—how should I say this—mental masturbation. The author of Mailman, John Viega, points out how wrong this is in his excellent essay “The Myth of Open Source Security”.

Excuse me for the blunt wording, but I am a little frustrated right now: I have devoted a decade of my life to MaraDNS, and I haven’t even been able to get a job because of my hard work; while I have had a couple of interviews I would not have had because of MaraDNS, so far I have gotten no offers. Yes, those are interviews I would not had have if it weren’t for MaraDNS, and, yes, MaraDNS kept my skills from getting completely rusty during the ’00s when I was concentrating on learning Spanish and living in Mexico. But, looking back, I really wish I had spent more time learning C++ and object oriented programming and less time editing the Wikipedia or posting to /..

It looks like Deadwood isn’t getting much external testing; not one person saw Deadwood’s issue with MX records in the year Deadwood has had this bug. So, yeah, like everything else with MaraDNS, I’m responsible for just about all of the testing. This isn’t a complete loss; people have asked me in interviews about my testing methodology for MaraDNS.

I have just uploaded a snapshot which fixes the issue with rotating records like MX records:

As a side benefit, since I have fixed this issue, TTL aging and RR rotation now work with ANY records.

Next: Set up a test for this issue, as well as DNS compression tests for all of the resource record types MaraDNS supports. If I get time, I will also set up tests to make sure Deadwood correctly handles things like SRV records with compression pointers, and that Deadwood doesn’t compress SRV records.

Friday, September 3, 2010

Deadwood 2.9.06 released

I have just released Deadwood 2.9.06. This is Deadwood 2.9.05 with its handling of empty DNS packets tweaked to handle the corner case of a DNS server giving out an empty packet better. It’s been two weeks since the last Deadwood testing release and it looks like I’m getting down to the nitty-gritty corner cases that only affect a tiny percentage of DNS resolutions (properly configured DNS servers do not give out empty DNS packets).

My plan is to release Deadwood 3.0.01 in a little over two weeks.

Meanwhile, Deadwood can be downloaded here:

Thursday, September 2, 2010

New Deadwood snapshot: Better heuristics for empty DNS packets

When a remote server sends us an empty DNS packet, what does that really mean? Well, it usually means that the hostname does not always exist. But, not always.

Let’s take the hostname It has three DNS servers:,, and Two of the servers ( and do the right thing: They redirect the name to Akamai’s horrendous mess of DNS resolution. However, is broken and gives us a blank DNS packet with a SERVER FAIL message.

The DNS administrators for aren’t trying to tell us that doesn’t resolve. No, they’re trying to tell us that their DNS administrator is asleep and misconfigured one of their three DNS servers.

So, I’ve tweaked the heuristics of Deadwood to treat a DNS packet with a “SERVER FAIL” RCODE as being one where the DNS server is asleep at the wheel, so instead of treating the packet like “this name does not exist” (like what we normally do with a blank DNS reply), we ignore the packet and bug the next DNS server on the list. The code isn’t perfect: We wait timeout_seconds before contacting the next server, but it’s good enough to have domains mismanaged like this correctly resolve.

I should note that the bugs I’m finding in Deadwood right now are not bugs caused by Deadwood not being RFC-compliant—the last bug I fixed like that was on August 9. No, at this point, I’m fine-tuning Deadwood to more or less do the right thing with mismanaged domains and broken DNS servers.

As always, the snapshot can be looked at here:

Wednesday, September 1, 2010

New Deadwood snapshot: Better handling of empty packets

I have uploaded a new snapshot of Deadwood which improves Deadwood’s handling of empty packets. A number of broken DNS configurations and servers out on the internet, such as the DNS servers answering the IPv6 (AAAA) query for, send out an empty DNS packet instead of a correctly made SOA-in-NS-section DNS reply when a host name can not be found.

Another situation where a DNS server gives out a reply like this is when someone stops paying for their domain, so the ISP suspends their account by removing the zone for their domain. However, this information has not been changed upstream. As a result, when we contact the DNS servers for a given zone, the DNS servers give us a blank QUERY REFUSED reply.

Since these do happen, Deadwood now pretends that a blank DNS reply is a low-TTL “SOA-in-NS-section” reply. This should speed up some queries, especially on IPv6-capable computers that perform AAAA queries before doing A queries.

It can be looked at here:

I should point out that I wrote the code to do this in a way to minimize the amount of code added to Deadwood and to maximize code reuse by having the relevant code in DwRecurse.c call the already created make_synth_not_there_answer() function made a little-more general purpose.