Did you know that Men & Mice are serious about your success and eager to share our knowledge with you?
Headquartered in Iceland with locations scattered around the world, Men & Mice is proud to have offices full of extremely intelligent minds that are eager to share their knowledge. The education takes place on our website, at our webinars & trainings, and through various social media channels like Twitter.
We gather interesting industry related knowledge that we read about, and impressive software and online tools that we discover, and then share that information during webinars, on our blog and thru social media. You'll learn what is new, what dangers you should be aware of and, how you can simplify your daily network management tasks.
At Men & Mice the aim is to offer state of the art software and hardware, great service, and last but not least, industry leading education. At the upcoming "DNS fragmentation attacks - the dangers of not validating DNSSEC" webinar in December, the focus will be on why these attacks work, why DNS caching servers that do not do DNSSEC validation are especially vulnerable, why DNSSEC signed zones can be used to launch these attacks, and how IPv6 and/or DNSSEC validation can stop these attacks.
If you have a question about DNS, IPAM, DHCP, DNSSEC, IPv6, or anything really, you can ask our Experts in the Services department.
You might also want to follow us so you don't miss out on what is hot and what is not!
Men & Mice on Twitter
Men & Mice on Facebook
Men & Mice on LinkedIn
Men & Mice on Google+
Men & Mice Webinars
Men & Mice Trainings
Men & Mice is pleased to announce the release of the new Men & Mice DNS/DHCP appliance. This new purpose-built appliance solution is specifically designed to maximize the performance of both hardware and software.
Security is built-in from the ground up, with a lean hardened Linux core that prevents both internal and external threats, including Distributed Denial of Services (DDoS) attacks.
Managed by the best
This new hardened appliance is centrally-managed through the acclaimed Men & Mice Suite, thus further extending the functionality and usability of the Men & Mice DNS, DHCP and IP Address Management solutions.
The Men & Mice Suite is trusted by some of the world's most high-profile organizations to manage their vast global networks. Combined with our new appliance product, we offer an unparalleled feature set that empowers administrators to easily manage complex DDI infrastructures from a single centralized user interface.
Together, our appliance and management solutions offer users the flexibility to build and adapt their network infrastructure as suits their business needs. Unlike other DDI solutions, we do not require our customers to replace their current servers, as our management solutions can be deployed as a management layer on top of the existing DNS/DHCP infrastructure. This enables customers to achieve all the benefits of security and high availability, while still being able to tailor the network to their needs.
Where they make sense, appliances can be added gradually and without the risk of network outages when existing servers are at the end of their lifetime or are difficult to maintain.
The Men & Mice Suite management solution supports industry-standard DNS/DHCP services including Microsoft and Linux, as well as DHCP services deployed on Cisco routers and a hybrid mixture thereof.
Offering secure and reliable DNS/DHCP services that improve the stability of core services while at the same time simplifying the task of managing the fast growing IP infrastructure has clear customer value. Maintaining the environment running the core DNS/DHCP services can be quite time consuming and has inherent security risks. By implementing our appliance-based solution, the task of information gathering, patching, and securing is handled by Men & Mice. Updates are then simple to implement through one source, thereby simplifying administration tasks.
The benefits are obvious: maximized ROI, low cost of ownership and dramatically decreased network risk.
Hardware or Virtual
The Men & Mice DNS/DHCP appliance can be deployed as either a hardware appliance or as a virtual appliance, bringing still greater flexibility to the client. Deployments of the Suite can be a mixture of hardware and/or virtual appliances in conjunction with standard Microsoft, Linux and Cisco core services- all without affecting the ability to manage the entire infrastructure from a single user interface.
Great Value Proposition
Offering competitive pricing, world class 24/7 service and support along with a strong warranty package, our appliances offer great value and ROI.
By Mr. Arno Meulenkamp, one of Men & Mice experts.
Since February 2013, to roughly coincide with the release of version 1.0 of BIND 10, Men & Mice, together with ISC, has been conducting BIND 10 workshops, allowing administrators to get a feel for the new software from ISC. The workshops have been a great success and feedback has been almost unanimously positive. In the workshops, several bug reports have been sent to ISC, with some fixes incorporated in the upcoming 1.2.0 release. In every workshop up to now (we won't guarantee it for future workshops!) we've had actual BIND 10 developers come in and talk about the development and answer questions. The BIND 10 team is very approachable and this has really helped with developing this workshop, but also in getting participants to think about what they need to implement BIND 10 best in their environment.
BIND 10 is a major change from BIND 9, not only in functionality (currently DNS *and* DHCP are supported, with no real limits on other additions later on), but also in configuration (no more named.conf!), flexibility (you only have to load the modules you need and you can relatively simply develop modules for features you miss) and development model (more bazaar than cathedral). In almost all cases, the people that came to the workshops have been impressed and sometimes even excited about the possibilities that BIND 10 will give.
At the same time, it became clear that the expectations of the big "1.0" release were different from reality. Lots of time and effort has been spent by the ISC developers to put a structure in place that is fast and stable and will allow for a scalable and flexible platform. That meant that some areas have gotten more attention than others, and this consequently means that the BIND 10 modules you need might not be feature complete or tested properly to be deployed in a production environment right now. You should make sure the functionality you need is ready or scheduled to be included soon before you create your deployment schedule.
That's not to say that BIND 10 now is not ready, but there are some very rough edges still and the expectations that we see in the workshop are for a much smoother ride. Until that smooth ride is here though, we have the BIND 10 workshop that will give you a look at this exciting new software and allows you to poke and prod and start imagining how this software will fit into your workflow, and what work needs to be done to get BIND 10 to be deployed in your network. You may just find yourself writing code for BIND 10 or sponsor the development of your killer feature.
We hope to see you soon in one of our workshops!
Men & Mice, a leading provider of DNS, DHCP and IP Address Management (IPAM) solutions, announces the release of the Men & Mice Suite version 6.4.
The new release of the Men & Mice Suite shows continued commitment to provide a high quality and feature rich DNS, DHCP and IP address management product.
This new version of the Men & Mice Suite expands management flexibility by introducing appliance management, full-spectrum device management and an enhanced feature set which make the system uniquely powerful and flexible.
Management for the Men & Mice DNS/DHCP Appliance
Version 6.4 of the Men & Mice Suite contains management features for the Men & Mice DNS/DHP Appliance, it contains a hardened Linux kernel combined with secure DNS and DHCP servers and is available both as a hardware and a virtual appliance. The appliance manager handles all communications, updates and configuration settings of the new appliance product.
All DNS and DHCP management features of the Men & Mice Suite can be used for the service on the appliances, enabling flexible and secure end-to-end DNS, DHCP and IP infrastructure management from one console. The Men & Mice Suite user can as before manage most industry standard DNS/DHCP services, including Microsoft and Linux as well as DHCP services deployed on Cisco routers and a hybrid mixture thereof. This unique combination offers flexibility in deploying and using these solutions and allows customers to combine the Men & Mice appliance products in hybrid environments with industry standard DNS/DHCP services.
Management of Devices
Subnet utilization history
New Update Manager
A Migrate Zone Wizard has been added
Subnet containers can now be created and used to ease subnet management
Access is now inherited for subnets and scopes
Support for creation and modification of $GENERATE zone statements has been added
It is now possible to view and clear selected DNS Cache entries from BIND DNS servers and the DNS/DHCP appliances
Various new SOAP commands have been added, further extending the flexible usage of the Men & Mice Suite
As in previous releases of the Men & Mice Suite the new version contains various enhancements and improvements. Many of these improvements have been worked on in cooperation with our current customers to meet their needs.
For further information contact Men & Mice
How does the Internet sort out your request to read this blog article from all the request to look at, such as the newspapers online or videos about cute kittens?
Rules are the answer!
Rules come in the form of acronyms and an IP address in the world of computing. A Protocol is another name for a rule and an Internet Protocol (IP) address is a unique number assigned to every device on the Internet. But how does it all work? Take a look at James May's Q&A on "How the Internet works" to learn more.
By Mr. Arno Meulenkamp, one of Men & Mice experts.
Men & Mice will be posting a few blog posts on how to set up and maintain DNSSEC on the Microsoft Windows 2012 Server platform. We assume that you know about DNS and DNS administration on Windows 2012 Server and have at least a minimal knowledge of DNSSEC.
Before you start signing and handing out your Trust Anchor, you will have to make a few choices. Will you use KSK/ZSK or Single-Type? How will you perform Key Rollovers and zone signing? How strong do your keys have to be? How will you store your keys? Do you want to go with NSEC3 or is NSEC more useful in your environment? Will you use your keys as trust anchors or will you (also) have a DS record in your parent zone?
Don't worry if the previous paragraph was filled with acronym overload. Let's go through the steps and choices one by one. Beginning with turning off recursion.
Making Windows 2012 DNS Server Authoritative only
The default state for the DNS server from Microsoft is to be a recursive server. Adding authoritative zones does not switch off the recursive part. Authoritative servers should be reachable for everyone, which means that if the same server also offers recursion, it can also be abused.
BCP 140 provides some recommendations for recursive nameservers and the Windows Firewall allows you to limit the IP addresses that can reach port 53, for DNS. However, Windows 2012 does not allow you to selectively switch recursion on or off for specific ranges of IP addresses, so the safest option is to switch off recursion for authoritative DNS servers. Switching recursion off can be done in three ways, like most configuration options for DNS servers.
In the advanced tab in the server properties you have the "Disable recursion" option. Select this option.
DnsCmd.exe <Servername> /Config /NoRecursion 1
Set-DnsServerRecursion -Enable 0
Key Signing Keys (KSK) and Zone Signing Keys (ZSK) or Single-Type
With DNSSEC, a private key creates a signature over a resource record set (all resource records with the same name, class and type attributes) and stores that signature in a new RRSIG resource record. This can be verified with the related public key that is published in the DNSKEY resource record. In order to be able to have confidence in the keys in DNS, you will need to securely get information about a public key through a channel that is not DNS. People that want to trust your DNS data will trust your key either through the Delegation Signer (DS) record in your parent zone or they get the key directly from you. In both cases, it takes some effort to distribute a new key.
In most cases, it is advisable to use two keys, Zone Signing Keys (ZSK), which are used to sign your entire zone, and Key Signing Keys (KSK), which are used to sign only the DNSKEY resource record set. The KSK will be used to point to by the DS record in your parent zone (most often a TLD) and can also be used as secure entry point for others that want to manually configure a trust point for your DNS data. Unless you know that you will not need the added flexibility of the KSK/ZSK distinction, it is recommended to do it, as it will make regular ZSK rollovers simpler.
Key strength, Key rollover and Key storage
Windows 2012 Server has the option to have multiple key storage providers. Going through which option is best in different situations is beyond the scope of this post, but it means that you can be more flexible with regards to security requirements for your DNS zone data.
As you can see in the screenshot, the zone signing wizard asks you not only to specify the regular attributes like key length and crypto algorithm, but it also lets you specify the key storage provider as well as a rollover frequency.
RFC 6781, the current IETF document on DNSSEC Operational Practices mentions that a key length of 1024 bits (for RSA keys) is enough to allow usage of those keys for a long time, even decades. However, for operational purposes it is a good idea to roll over keys more regularly so as to have operational knowledge of rollovers should the need arise to perform an emergency rollover. Windows 2012 Server does not allow keys shorter than 1024 bits, but it does allow you to set a wide range of rollover frequencies, from one week to twenty years.
NSEC or NSEC3
If you want to be able to trust the DNS resource records, you also need to be able to trust the message that particular data does not exist. DNSSEC solves this with NSEC or NSEC3 records. The short explanation is that with an NSEC record, it lists the resource record types for the name, as well as the name of the next resource record. With this information you can see that the resource record type (for the name you queried) or the resource record name you requested does not exist. NSEC uses the actual resource record names, whereas NSEC3 uses a one-way hash of the name. This way it prevents people from walking your zone data from one record to the next, at the expense of some CPU cycles both on the authoritative server as well as the resolver. Because of the before mentioned amplification attacks, it is a very bad idea to allow zone transfers, but do you mind if people have the contents of your entire zone? If you do not want to give people access to your entire zone file, you should choose NSEC3. Be aware that in order to use NSEC3, you cannot use RSA/SHA-1 as the algorithm of your keys, as some resolvers that understand RSA/SHA-1 might not understand NSEC3. Using RSA/SHA-256 is a safe alternative.
Secure Entry Points (SEP), Trust Anchors and DS records
The last part to look at before you sign your zone is who you want to distribute your key to. It might be necessary for some servers to be configured with your key directly, but, as long as your TLD supports DNSSEC, it will create less overhead during KSK rollovers to only have a DS record at your parent zone.
Ducks in a row
You will be ready to start signing your zone, as soon as you have settled on:
- the key strength you need
- how you will store your keys
- how often you will roll over your keys
- if you will use NSEC or NSEC3
- who to distribute your public key to
Signing your zone can be done with the simple Zone Signing Wizard, but dnscmd.exe and the powershell have their own advantages. We will go deeper into how to sign in a future post.
By Mr. Arno Meulenkamp, one of Men & Mice experts.
DNS has been a game where only ISC's BIND really played. Even though there were some other options out there, they never got a large market share, they were missing some (new) feature or they simply did not play well with others. Nowadays though, the situation is different. Not only do we have daemons like NSD and Unbound, but others have also paid more attention to current standards and Microsoft is no different. The implementation in Microsoft's Windows Server 2012 is a fully interoperable DNS server, with an up-to-date security implementation, including DNSSEC. DNSSEC in Windows Server 2012 can now also be used for dynamic zones, but only if part of Active Directory.
Management of DNS server hasn’t changed much, but there are three distinct ways. Each has their own advantages/disadvantages and feature set. DNS Manager is a graphical tool which allows you to do most things that administrators need on a daily basis. It’s got an easy overview and wizards for most recurring tasks. It doesn’t let you change more detailed settings though. Dnscmd.exe is still available, a command line utility that will allow you to check and set most DNS settings, including some options not found in the other tools. Microsoft is moving over to the Windows Powershell however, so to be sure that your scripts will use the supported way of configuring the DNS server and you won’t find yourself suddenly no longer supported, you will have to use the DNS cmdlets in the Windows Powershell.
If you use Windows 2012 Server as a recursive DNS server, there is not much to change. Microsoft 2012 Server DNS follows most IETF recommendations, so you don’t have to hunt for obscure options, just enable the features you want. If you do want to go through all the details, you will have to use the Powershell cmdlets, they will give you all the power you want/need.
One option to consider that is not enabled by default is DNSSEC validation. Doing this can of course be done in three different ways, each quite straightforward, although it takes two seperate steps, configuring at least one trust anchor and then enabling DNSSEC validation.
Configuring a Trust Anchor
To add a trust anchor, you can either add the DS record for the zone(s) you want to use as a trust anchor, or you can add the DNSKEY key material itself. Adding multiple trust anchors is no problem, but unfortunately, it is not possible to add lookaside (RFC 5074) zones.
The most obvious trust anchor to add is the one for the root zone. IANA publishes the root zone trust anchor online, along with signatures and certificates to authenticate its authenticity. If you are not sure if the TLD (that your domain zone is a child zone of) is signed, you can find that out on this ICANN page. If your TLD is not listed as having its trust anchor in the root zone, you will have to add your own DS or DNSKEY as a trust anchor as well. Of course, this is also true if you cannot or choose not to publish your trust anchor in your TLDs zone.
After you get the DS-set or DNSKEY-set file(s) for your chosen trust anchor(s), you need to add them.
You can choose to import a DS-set or DNSKEY-set file, but you can also directly enter the information, as we show here for the DS record for the root zone. Select Trust Points in the DNS Manager, then add a DS record.
Dnscmd.exe has a special shortcut to adding the trust anchors for the DNS Root zone. It will retrieve the DS records for the root zone, add them and enable DNSSEC validation all in one go.
PS C:\Users\Administrator> Dnscmd.exe /RetrieveRootTrustAnchors
Are you sure you want to Retrieve and add root trust anchors (activating DNSSEC validation)? (y/n) y
The root trust anchors were succesfully retrieved and added as DS trust anchors.
They will become effective when the server is able to convert them to DNSKEY
trust anchors during an active refresh.
Command completed successfully.
To add a trust anchor for another zone, you can either enter the data for a DNSKEY or, as shown here, for a DS record.
Dnscmd.exe /TrustAnchorAdd example.net DS 16389 7 1 07F5FF12568D815B7D78741EA635E42D7339E265
Add-DnsServerTrustAnchor -Name . -CryptoAlgrithm RsaSha256 -Digest 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 -DigestType Sha256 -KeyTag 19036
Enabling DNSSEC validation
After configuring the trust anchor(s), enabling DNSSEC validation is trivial.
DnsCmd.exe <Servername> /Config /enablednssec 1
Although Microsoft wants to move command line configuration to Powershell cmdlets, it is not currently possible to enable DNSSEC validation through the Powershell.
If you want to test if DNSSEC validation is active and working you cannot use nslookup.exe, as it does not support DNSSEC. Men & Mice put up a page with some tools that can help, but the easiest test would be to use DIG. You can download the zip file for the latest version of BIND from ISC. To use DIG, create an empty directory and copy the files DIG.EXE, DIG.HTML, LIBDNS.DLL, LIBEAY32.DLL, and LIBISC.DLL into it (or put those files in a directory in your path).
If you test with DIG, make sure you do so from the Command Prompt, cmd.exe, and not from the Powershell, as that may give unexpected results. A simple test is to query the nameservers for the root zone.
PS C:\Users\Administrator\Downloads\BIND9.9.2>.\dig.exe +dnssec . ns
; <<>> DiG 9.9.2 <<>> +dnssec . ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40600
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 23
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4000
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 86400 IN NS f.root-servers.net.
. 86400 IN NS c.root-servers.net.
. 86400 IN NS j.root-servers.net.
. 86400 IN NS d.root-servers.net.
. 86400 IN NS g.root-servers.net.
. 86400 IN NS l.root-servers.net.
. 86400 IN NS e.root-servers.net.
. 86400 IN NS b.root-servers.net.
. 86400 IN NS m.root-servers.net.
. 86400 IN NS h.root-servers.net.
. 86400 IN NS i.root-servers.net.
. 86400 IN NS a.root-servers.net.
. 86400 IN NS k.root-servers.net.
. 86400 IN RRSIG NS 8 0 518400 20130421000000 20130413230000 20580 . MLGI2vO6PUzXf7QNqmjyjj5QD8LMmWJkEL257Lkak1dBeX8VVqvt/3By yNrs7bb2PvSXbEum3OvqCFxRVD6D01bOQsFXQni/bnyJ6bd/m/ubc7qF 1GGEsF+NnkLOPb3zuslRK3kQCiz9EZIdz5Lqlwz2fsHlmlL65QEgXAbC fE4=
;; ADDITIONAL SECTION:
f.root-servers.net. 86400 IN A 184.108.40.206
f.root-servers.net. 86400 IN AAAA 2001:500:2f::f
c.root-servers.net. 86400 IN A 220.127.116.11
j.root-servers.net. 86400 IN A 18.104.22.168
j.root-servers.net. 86400 IN AAAA 2001:503:c27::2:30
d.root-servers.net. 86400 IN A 22.214.171.124
d.root-servers.net. 86400 IN AAAA 2001:500:2d::d
g.root-servers.net. 86400 IN A 126.96.36.199
l.root-servers.net. 86400 IN A 188.8.131.52
l.root-servers.net. 86400 IN AAAA 2001:500:3::42
e.root-servers.net. 86400 IN A 184.108.40.206
b.root-servers.net. 86400 IN A 220.127.116.11
m.root-servers.net. 86400 IN A 18.104.22.168
m.root-servers.net. 86400 IN AAAA 2001:dc3::35
h.root-servers.net. 86400 IN A 22.214.171.124
h.root-servers.net. 86400 IN AAAA 2001:500:1::803f:235
i.root-servers.net. 86400 IN A 126.96.36.199
i.root-servers.net. 86400 IN AAAA 2001:7fe::53
a.root-servers.net. 86400 IN A 188.8.131.52
a.root-servers.net. 86400 IN AAAA 2001:503:ba3e::2:30
k.root-servers.net. 86400 IN A 184.108.40.206
k.root-servers.net. 86400 IN AAAA 2001:7fd::1
;; Query time: 124 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Apr 14 12:01:36 2013
;; MSG SIZE rcvd: 871
As you can see from the answer, the ad flag is set for Authenticated Data. You now have a working authenticating DNSSEC resolver.
DNS Servers as weapons?
The usually stealth DNS was in the news recently when some very worrisome news surfaced last week. A feud between an anti-spam organisation (Spamhaus) and a hosting site that is accused of offering spam senders a safe haven has escalated, and the criminals used DNS and BGP to attack Spamhaus.
The press picked the story up from Cloudfare, and while the Internet was not at risk, as some wrote, the attack was big enough to bring down servers on the Internet and even single networks. That is a scary thought, especially as any one of us could be a victim of such attacks in the future. Many organizations today cannot survive very long without Internet, and once you are under attack even by just one individual, it might be difficult and expensive in terms of time and money to mitigate these attacks.
While not all parts of the recent attacks were caused by DNS, the larger part of the denial of service attack was. Experts have known about these kind of attacks (known as "DNS reflection" and "DNS amplification" attacks), and also the solutions for years. But many DNS administrators are not aware of the problem, or have not made it a priority to prevent their DNS servers from being used as a weapon for criminals. Many are running outdated DNS server software or a DNS server that is unknowingly configured to be a weapon in such attacks. The US-Cert (Computer Emergency Response Team) was prompted by the recent attacks to issue instructions on how to secure a DNS server.
How to secure your DNS server
Having your DNS server "open" doesn't only put other users of the Internet at risk, but also eats away your own resources. You network gets more saturated and your DNS service will be slowed down when your DNS server is misused for attacks. It only takes a minute to secure your DNS server so that it cannot be used as a weapon in Denial of Service attacks, and here's how:
* close down open DNS resolvers
* implement BCP38 or ask your upstream provider to implement it
* deploy DNS Response Rate Limiting on authoritative DNS Servers
* monitor your DNS servers to detect attacks
Men & Mice Webinar
"The dangers of DNS reflection attacks (and how to mitigate them)"
To help you with the task, Men & Mice is offering a FREE 1 hour WEBINAR.
This webinar will explain the nature of DNS reflection attacks and what DNS operators on Unix (BIND DNS) and Windows (Microsoft DNS) can do to prevent their DNS servers to be used as weapons in DNS reflection attacks.
The first Release Candidate of the new DNS and DHCP server from ISC, BIND 10 (http://bind10.isc.org) was released on February 15, 2013.
Men & Mice is monitoring and supporting the BIND 10 development, and as part of that, our engineers sometimes create little helpful tools to share with the community.
TSIG is short for Transaction Signatures, defined in RFC 2845 "Secret Key Transaction Authentication for DNS (TSIG)". TSIG is primarily used to authenticate DNS zone transfer between DNS servers, and to secure dynamic DNS updates.
BIND 10 supports TSIG for both zone transfer and dynamic updates, but it does not contain a tool to create the TSIG keys. While it is possible to use the tools from BIND 9 (https://www.isc.org/wordpress/software/bind/) or ldns (ldns-keygen, http://www.nlnetlabs.nl/projects/ldns/), installing these tools along with BIND 10 might be too much overhead.
Men & Mice engineers have written a small tool in Python called b10-gentsigkey.py (https://github.com/menandmice/b10-gentsigkey).
The tool creates by default an HMAC-MD5 key with 128bits size and prints the key on the screen:
# b10-gentsigkey.py example.com
Usage: b10-gentsigkey.py [--help | options] name
-h, --help show this help message and exit
-a ALGORITHM, --algorithm=ALGORITHM
algorithm for the TSIG key
-b SIZE, --bytes=SIZE
size of the key
-f print bindctl CLI command
b10-gentsigkey supports all the TSIG algorithms that are also supported by BIND 10 ('hmac-md5', 'hmac-sha1', 'hmac-sha224', 'hmac-sha256', 'hmac-sha384', 'hmac-sha512').
Using the "-f" (Format) switch, the tool will print the bindctl command to enter the TSIG key into the BIND 10 configuration. That command can be copy-n-paste into the bindctl command line:
# b10-gentsigkey.py -a hmac-sha256 -b 256 -f example.de
config add tsig_keys/keys "example.de:M2nrsQWVEAuAfm67U2Gdfj2dFfJIPay9ZFMukXSSCiY=:hmac-sha256"
this output can be directly piped into bindctl:
# b10-gentsigkey.py -a hmac-sha1 -b 256 -f example.com | bindctl
We hope to bring a similar command into the BIND 10 CLI (bindctl), so that no external tool is required to create TSIG keys by an external tool.
Until then, enjoy this little tool.
If you are interested in learning more about BIND 10, Men & Mice is working close with ISC to deliver the first industry training on this new version of the BIND name server software in Amsterdam, Netherlands from February 20th - 21st, 2013. You can learn more about it from the Men & Mice BIND 10 workshop page.
BIND 10 is the next generation of BIND, the most widely-used DNS server on the Internet. It is modular server that includes an authoritative DNS server, a recursive DNS server, a DNSSEC signer and a DHCP server for IPv4 and IPv6. BIND 10 first production release to be expected in 2013.
Additional information on BIND 10 can be found on the BIND 10 project website http://bind10.isc.org.
Men & Mice is working close with ISC to deliver the first industry training on this new version of the BIND name server software in Amsterdam, Netherlands from February 20th - 21st, 2013.
This is a classroom-style course with lecture and hands-on labs.
The students will learn how to:
- install BIND 10 from source or from packages
- configure BIND 10 as an authoritative DNS Server, a DHCP server and automate DNS and DHCP data provisioning using the BIND 10 management toolset.
The class is geared towards sysadmins and network administrators with basic knowledge on DNS.
Knowledge on BIND 9 is not required.