A DNS zone file generator and parser written in Javascript.
An RFC1035 compliant DNS zone file parser and generator for Node.js and browser.
Installation
Bower Install
bower install dns-zonefile --save
Standalone
sudo npm install dns-zonefile -g
Module
npm install dns-zonefile
Usage
Zone Information
dns-zonefile accepts both zone data expressed as a JSON object or plain text zone file. It supports SOA, NS, A, AAAA, CNAME, MX, PTR, SRV and TXT record types as well as the $ORIGIN keyword (for zone-wide use only). Each record type (and the $ORIGIN keyword) is optional, though bind expects to find at least an SOA record in a valid zone file.
Examples
Forward DNS Zone
The following JSON produces a zone file for a forward DNS zone:
dns-zonefile will produce the following zone file from the above information, while the following zone file can as well be parsed to produce the zone file like above:
dns-zonefile will produce the following zone file from the above information, while the following zone file can as well be parsed to produce the zone file like above:
; SOA Record @ IN SOA NS1.NAMESERVER.NET. HOSTMASTER.MYDOMAIN.COM. ( 1411420237 ;serial 3600 ;refresh 600 ;retry 604800 ;expire 86400 ;minimum ttl )
; NS Records @ IN NS NS1.NAMESERVER.NET. @ IN NS NS2.NAMESERVER.NET.
; PTR Records 1 IN PTR HOST1.MYDOMAIN.COM. 2 IN PTR HOST2.MYDOMAIN.COM.
Standalone Usage
To use dns-zonefile to generate a zone file from JSON from the command line, place the desired JSON data in a file (zonefile_data.json in this example) and run the following command. Note that the resulting zone file will be printed to the console; to save the zone file to disk (my_zone.conf in this example), use redirection as in this example:
zonefile -g zonefile_data.json > my_zone.conf
To use dns-zonefile to parse a zone file to JSON from the command line, place the desired zone file data in a file (zonefile_data.txt in this example) and run the following command. Note that the resulting JSON will be printed to the console; to save the JSON to disk (my_zone.json in this example), use redirection as in this example:
zonefile -p zonefile_data.txt > my_zone.json
If the -g and -p are omitted, -g will be assumed if the lower cased filename contains .json, otherwise, -p will be assumed.
zonefile -v or zonefile --version will print the version information.
A utility for quickly searching presorted DNS names. Built around the Rapid7 rdns & fdns dataset.
How does it work?
This utility assumes the file provided is presorted (both alphabetical, and symbols).
The algorithm is pretty simple:
Use a binary search algorithm to seek through the file, looking for a substring match against the query.
Once a match is found, the file is scanned backwards in 10KB increments looking for a non-matching substring.
Once a non-matching substring is found, the file is scanned forwards until all exact matches are returned.
Limits
There is a built-in limit system. This prevents 2 things:
scanning too far backwards (MaxScan)
scanning too far forwards after scanning backwards (MaxOutputLines)
This allows for any input while stopping requests that are taking too long.
Additionally, this utility does not handle the edge cases(start/end) of files and will return an error if encountered.
Install
go get the following packages:
# used for dnsgrep cli flags go get "github.com/jessevdk/go-flags" # used by the experimental server for http routing go get "github.com/gorilla/mux" # pull in a string reversal function go get "github.com/golang/example/stringutil"
Run
The following steps were tested with Ubuntu 16.04 & go 1.11.5.
Generate fdns_a.sort.txt and rdns.sort.txt first using the scripts found in the scripts/ folder:
# Each of these scripts requires: # * 3 hours+ on an SSD # * 300GB+ temp disk space (under the same folder) # * ~65GB for output output (under the same folder) # * jq to be installed ./scripts/fdns_a.sh ./scripts/rdns.sh
Run the command line utility:
go run dnsgrep.go -f DNSBinarySearch/test_data.txt -i "amiccom.com.tw"
Run the experimental server in the same folder as fdns_a.sort & rdns.sort.txt:
go run experimentalServer.go
Data Source
The source of this data referenced throughout this repository is Rapid7 Labs. Please review the Terms of Service:https://opendata.rapid7.com/about/
ZDNS is a command-line utility that provides high-speed DNS lookups. For example, the following will perform MX lookups and a secondary A lookup for the IPs of MX servers for the domains in the Alexa Top Million:
Raw DNS responses frequently do not provide the data you want. For example, an MX response may not include the associated A records in the additionals section requiring an additional lookup. To address this gap and provide a friendlier interface, we also provide several lookup modules: alookup and mxlookup.
mxlookup will additionally do an A lookup for the IP addresses that correspond with an exchange record. alookup acts similar to nslookup and will follow CNAME records.
ZDNS can either operate against a recursive resolver (e.g., an organizational DNS server) [default behavior] or can perform its own recursion internally. To perform local recursion, run zdns with the --iterative flag. When this flag is used, ZDNS will round-robin between the published root servers (e.g., 198.41.0.4). In iterative mode, you can control the size of the local cache by specifying --cache-size and the timeout for individual iterations by setting --iteration-timeout. The --timeout flag controls the timeout of the entire resolution for a given input (i.e., the sum of all iterative steps).
Running ZDNS
By default, ZDNS will operate with 1,000 light-weight go routines. If you're not careful, this will overwhelm many upstream DNS providers. We suggest that users coordinate with local network administrators before performing any scans. You can control the number of concurrent connections with the --threads and --go-processes command line arguments. Alternate name servers can be specified with --name-servers. ZDNS will rotate through these servers when making requests.
Unsupported Types
If zdns encounters a record type it does not support it will generate an output record with the type field set correctly and a representation of the underlying data structure in the unparsed_rr field. Do not rely on the presence or structure of this field. This field (and its existence) may change at any time as we expand support for additional record types. If you find yourself using this field, please consider submitting a pull-request adding parser support.
Open the config file, shuttle.yaml. Make sure all the ports are all configured correctly before launching. The default ports in config file are 8080, 8081 and 8082.
General: http-port: "8080"#http/https port socks-port: "8081"#socks port controller-port: "8082"#dashboard port
Launch
Go to the shuttle directory and enter the command below in terminal/CMD to launch the app.
./start.sh #no output
Open your browser and visit http://localhost:8082 (For example, use the default settings controller-port: "8082"). The application has already run successfully if you can visit the dashboard on your browser. Otherwise check the shuttle.log for more details and new issues anytime.
System Configuration
If you can visit http://c.sipt.top on your browser, you can skip the following steps directly.
Open System Preference => Network => Advanced => Proxy，there are 3 main options:
Web Proxy（HTTP） set to 127.0.0.1:8080 (for example, http-port: "8080")
Web Proxy（HTTPS） set to 127.0.0.1:8080（for example, http-port: "8080"）
SOCKS Proxy set to 127.0.0.1:8080（for example, socks-port: "8081"）
Press OK and click Apply. The proxy settings are working if you can see the dashboard by visiting http://c.sipt.topon browser.
Enter the following commands to make Terminal.app go through proxies:
Open the config file, shuttle.yaml. Make sure all the ports are all configured correctly before launching. The default ports in config file are 8080, 8081 and 8082.
General: http-port: "8080"#http/https port socks-port: "8081"#socks port controller-port: "8082"#dashboard port
Launch
Double-click startup.bat, there will be no output on screen. Open your browser and visit http://localhost:8082 (For example, use the default settings controller-port: "8082"). The application has already run successfully if you can visit the dashboard on your browser. Otherwise check the shuttle.log for more details and new issues anytime.
System Configuration
If you could open http://c.sipt.top in your browser, you can skip the following steps directly.
Open System Preference => Network => Proxy, set to 127.0.0.1:8080（for example: http-port: "8080"）. The proxy settings are working if you can see the dashboard by visiting http://c.sipt.top on browser.
Linux
Preparation
Download the zip file from release and unzip it. The Folder structure is shown below.
Open the config file, shuttle.yaml. Make sure all the ports are all configured correctly before launching. The default ports in config file are 8080, 8081 and 8082.
General: http-port: "8080"#http/https port socks-port: "8081"#socks port controller-port: "8082"#dashboard port
Launch
Go to the shuttle directory and enter the command below in terminal/CMD to launch the app.
./start.sh #no output
Open your browser and visit http://localhost:8082 (For example, use the default settings controller-port: "8082"). The application has already run successfully if you can visit the dashboard on your browser. Otherwise check the shuttle.log for more details and new issues anytime.
Configuration
Version
ver: v1.0.1
Current config file only supports v1.0.1. Don't edit yourself.
MITM: rules: ["*.baidu.com", "*.zhihu.com"] #Domains allowed for MitM ca: (base64) # CA certificate and private key, no need for configuration, Shuttle will generate them automatically and store here key: (base64)
Rule Configuration
Rule: # Proxy rules - ["DOMAIN-SUFFIX", "gitlab.anjian.com", "DIRECT", ""] # - [Match full domain，domain，go through Proxy group，] - ["DOMAIN", "sipt.top", "Proxy", ""] # - [keyword match，keyword，connection reject，] - ["DOMAIN-KEYWORD", "zjtoolbar", "REJECT", ""] # - [IP range match，IP range，direct connection，] - ["IP-CIDR", "127.0.0.0/8", "DIRECT", ""] # - [GEOIP match，China， go through nProxy group，] - ["GEOIP", "CN", "nProxy", ""] # - [match none of above，， go through Proxy group，] - ["FINAL", "", "Proxy", ""]
Check all DNS records The Refresh button and Clear button is on the left-hand corner. The Refresh button currently only support all records refresh.
Records
Check all request, and the corresponding rule. Currently, only the latest 500 entries will be stored, and keyword filter is supported
Traffic Capture
You can enable Dump for HTTP traffic capture. All the Dumped Data would show the DOWNLOAD icon the every records. You can click and see for more detail.
It's a little bit complicated for HTTPS traffic capture. You can follow the steps to try it out.
Generate a certificate. A new CA would be generated and stored in the config file when you click the GENERATE button each time.
Click DOWNLOAD button to download the CA.
Add the CA to system and trust the CA.
The table above will list all HTTPS traffic that could be captured based on rules. You can add yourt own rules. Shuttle will not capture the HTTPS traffic matched no rules..
You should enable both Dump and MitM to make HTTPS traffic capture available.
Large file download
Enter the file name in the input filed, then click download.
The dumped data just shows "The file is too large" instead of data detail for the better webpage performance when the file data size is over 2MB. You can download it for more details.
Build from source
go get -d github.com/sipt/shuttle cd$GOPATH/src/github.com/sipt/shuttle/assets go generate # package html and GeoLite2-Country.mmdb resources into assets/assets.go cd$GOPATH/src/github.com/sipt/shuttle/cmd go build -tags release
dnsproxy2 - a replacement DNS proxy for Android 4.3+
This currently allows the user to manually override the DNS server IP, and it sets the correct UID on outbound requests so they can be filtered via iptables / AFWall+ / DroidWall / etc.
Requirements:
Root access
Write access to /system
/etc/init.d (if you want to start it on boot)
Build instructions:
1) Install NDK r8e under /opt/android-ndk
2) Run /opt/android-ndk/ndk-build
3) Binaries are under libs/. Most devices will use libs/armeabi-v7a/
Installation instructions:
Make sure adb is in your PATH and functional, then on your PC host run:
bash misc/install.sh
This installs /system/xbin/dnsproxy2 and /etc/init.d/20dnsproxy2
To uninstall, remount /system read-write and delete those files.
The purpose for this project is to make it easy to set up a fast smart DNS service on your own. It is possible to get a US VPS for 1$/mo which is well under the current 4$/mo for most smart DNS services. It is also potentially alot faster, as you then have a whole proxy server to yourself.
Another purpose is privacy. By changing your DNS servers, you allow whoever is on the other side to see almost all the websites you visit. Some providers explicitly state in their TOS that they log everything, which gives them control over your data. A better option is that you control those servers.
Prerequisites:
A VPS based in the country you want, preferrably running Ubuntu 14.04. A 128MB server is enough.
python
haproxy
For sni and dnat setup:
dnsmasq
The configuration generator (dnsproxy.py) offers three different possibilities for setup:
You can generate each configuration file separately with -m manual. Example: python dnsproxy.py -m manual -o haproxy. -m manual is also default, so this can be simplified to python dnsproxy.py -o haproxy.
It is also possible to specify which proxy list you would like to use, based on country. You can specify that by passing -c , where is a suffix of any file in the proxies/ directory. For example, if you wish to generate configuration for a uk based SNI proxy, you can run python dnsproxy.py -c uk -m sni. The default country is us.
Check the wiki for additional information, along with these links by @trick77:
Generate configuration files to setup a tunlr style smart DNS
optional arguments: -h, --help show this help message and exit -m {manual,sni,dnat,local}, --mode {manual,sni,dnat,local} Presets for configuration file generation. -o {dnsmasq,haproxy,netsh,hosts,rinetd,iptables} [{dnsmasq,haproxy,netsh,hosts,rinetd,iptables} ...], --output {dnsmasq,haproxy,netsh,hosts,rinetd,iptables} [{dnsmasq,haproxy,netsh,hosts,rinetd,iptables} ...] Which configuration file(s) to generate. This is ignored when not in manual mode. -c COUNTRY, --country COUNTRY The country to use for generating the configuration. -d, --dnat Specify to use DNAT instead of SNI (Advanced). This is ignored when not in manual mode. --no-test Specify to skip generating test configuration. This means that you will not be able to test your setup with the setup tester. --ip IP Specify the public IP to use --bind-ip BIND_IP Specify the IP that haproxy should bind to --base-ip BASE_IP Specify the base IP from which DNAT should start generating. --base-port BASE_PORT Specify the base port from which DNAT should start generating. --save Specify wether to save the configuration to config.json --output-dir OUTPUT_DIR Specify the output directory --only [ONLY [ONLY ...]] Specify the proxies to use while generating --skip [SKIP [SKIP ...]] Specify the proxies to not use while generating --dnsmasq-filename DNSMASQ_FILENAME Specify the DNS configuration file name --haproxy-filename HAPROXY_FILENAME Specify the haproxy configuration file name --iptables-filename IPTABLES_FILENAME Specify the iptables configuration file name --netsh-filename NETSH_FILENAME Specify the netsh configuration file name --hosts-filename HOSTS_FILENAME Specify the hosts configuration file name --rinetd-filename RINETD_FILENAME Specify the rinetd configuration file name
A Dynamic DNS system built with API Gateway, Lambda & Route 53.
This repository originally supplemented the blog post: Building a Serverless Dynamic DNS System with AWS Code and instructions for the version described in the blog can be found in the v1 folder of this repository.
The project implements a serverless dynamic DNS system using AWS Lambda, Amazon API Gateway, Amazon Route 53 and Amazon DynamoDB. A bash reference client route53-ddns-client.sh is included, but the api calls for the system can be easily implemented in other languages. The benefits and overall architecture of the system described in Building a Serverless Dynamic DNS System with AWS are still accurate.
The current project supports:
One step provisioning via AWS CloudFormation
System configuration in Amazon DynamoDB
ipv6 support
Internal ip address (rfc1918) support
Custom API endpoint hostname
Network discovery: Enables a single host on a network segment to set DNS entries for multiple other hosts on the same network.
Stack name - required All Stack resources are named using the CloudFormation Stack name you choose. Because of this, the Stack name must be compatible with the name restrictions of all services deployed by the stack. Only use lower case letters, numbers '_' and '-'
route53ZoneName - required Route53 Zone name. ie 'example.com' Use either existing zone or name of zone to be created by the stack. Zone name must not end in '.' If using an existing zone, route53ZoneName must match the name of the zone passed in route53ZoneId. For Private Hosted Zones, you must use an existing zone.
All remaining parameters can be left blank or at defaults.
route53ZoneId Populate to use an existing zone. ie 'Z1FXLQ1OABKR4O' The zone must exist in the same account as the stack. If omitted, a new Route53 DNS zone will be created. If supplied, the ddns system will gain IAM permissions to modify existing zone entries.
defaultTtl The default TTL for DNS records, can be overridden for individual records in DynamoDB config.
enableCloudFront CloudFront is required for ipv6 support or to use a custom API Alias (CNAME). Note that the Stack creation will not complete until after the CloudFront distribution is done propagating. This adds several munites to Stack creation time. -false - Call API Gateway directly -withCustomAlias - Required for ipv6 and/or apiCname -withoutCustomAlias - Required for ipv6
apiCname API Endpoint Custom Alias Required for enableCloudFront withCustomAlias Will create a CNAME to your API endpoint in the route53ZoneName supplied. i.e. entering 'ddns' for route53ZoneName 'example.com' will create the CNAME 'ddns.example.com'
useApiKey Adds an API Key to your API Gateway. Requests to the API without the proper key are blocked instead of passing through to Lambda. This prevents DOS/resource depletion attacks against your Lambda backend. The auto-generated key is published to the stack outputs.
acmCertificateArn Required to use a custom dns endpoint (Alias) for your API. Populate to use an existing ACM Certificate. (CloudFormation will not create a certificate on your behalf.) Full ARN of an ACM SSL Certificate: i.e. 'arn:aws:acm:us-east-1:123456789012:certificate/a1aaab22-11ab-ab12-cd34-12345abc0ab0' The certificate must be in us-east-1 (Virginia) Region. The certificate can either match the API endpoint custom alias. i.e. 'ddns.example.com' or the entire zone i.e. '*.example.com' See: Request a Public Certificate
CloudFrontPriceClass Leave at default unless you are accessing from outside US, Canada & Europe. See documentation. -US-Canada-Europe -US-Canada-Europe-Asia -All-Edge-Locations
DynamoDB Configuration Sets the provisioned capacity of the DynamnoDB table built by CloudFormation. ddbRcu & ddbWcu set the Read & Write capacity units for the DynamnoDB table. ddbGsiRcu & ddbGsiWcu set the Read & Write capacity units for the DynamnoDB Global Secondary Index. Leave at defaults for small scale deployments. Provisioned capacity affects both scalability and cost.
templateVersion Sometimes required to force a stack update or force Lambda-backed custom resources to run. The system does not actually track the version, if needed increment or simply change it to another arbitrary digit.
When Stack creation is complete you may need to look at the Outputs for information necessary to proceed with setup.
ddns Stack Outputs:
apiUrl Use this as your API endpoint It is a calculated output based on your Parameter choices. It will either reflect the API Gateway, CloudFront, or Custom Alias of the API.
The system creates a DynamoDB Table for configuration named [stackName]-config. You must create an Item (row) for each Route53 DNS entry managed by the system. The Table is pre-populated with two example Items to duplicate and modify. Note that some attributes are for configuration, while others (marked read-only below) reflect state information from the system.
Configuration Table Attributes
hostname The hostname of the dns record.
record_type A for ipv4 or AAAA for ipv6 records Note that hostname and record_type form the composite primary key for the Table. The combination of the two Attributes in each Item must be unique.
allow_internal Boolean to control whether the record can be set to an internal (rfc1918) address See Security Considerations
comment For your reference only, unused by ddns.
ip_address - read-only Reflects the last IP address set for the record by the ddns system
last_accessed - read-only Reflects the last public IP address from which the record was read or modified
last_checked - read-only Reflects the last time the record was read by the ddns system
last_updated - read-only Reflects the last time the record was modified by the ddns system
lock_record Boolean to prevent ddns from modifying the corresponding Route53 record The deletion/omission of an Item will also prevent Route53 record creation or modification. See Security Considerations
mac_address Set the mac address of the host to associate with the Route53 record Optional, used by Network Discovery
read_privilege Boolean to allow read access by another host Optional, used by Network Discovery
The ddns system gains permissions to modify records in the configured Route53 Zone. If you are concerned about allowing the system to modify an existing Zone, you can create a new Zone as a delegated subdomain. See Route53 Setup for instructions. Note that delegated subdomains do not work with private zones.
The ddns system will not modify or create a record if a matching Item is not found in DynamoDB or a matching matching Item is found, but it's lock_record attribute is true.
When the client makes an API request to modify a record, it passes a token generated by hashing: -The public IP of the requesting host or network -The hostname to be set -The shared secret associated with the hostname's Item in DynamoDB Note that the public IP is discovered by an initial client request to the API in get mode. Then API then reflects the client's public IP in the JSON response.
The API (via Lambda) re-creates and matches the hash the IP of the request and a lookup of the shared_secret attribute from DynamoDB.
It then sets the dns record to the requestor's public ipv4 or ipv6 address.
When setting a private IP, the client can request that any valid ipv4 or ipv6 address be set into the record. If the allow_internal configuration Attribute is set to false, the system will not set arbitrary IP addresses.
Known issues
The system could be vulnerable to request-replay attack via a man-in-the-middle. As designed, it relies on the security of ssl/tls to secure transmissions. We are evaluating whether it makes sense to add a timestamp to the hash to mitigate this.
Publishing private ipv4 addresses to a public Route53 Zone leaks those addresses publicly.
Network Discovery enables a single host to set dns entries for other hosts on the same network. This removes the need to install a client on all hosts, and enables creation of dns entries for devices unable to run a client.
To enable this feature, create host groups in the DynamnoDB config table.
Hosts with matching shared_secret Attributes and the read_privilege set to true form a group.
The mac_address Attribute must also be set correctly in DynamoDB for each host in the group.
Any host within a group can make requests to set Route53 records on behalf of other hosts in the group.
Process:
The client makes an authenticated list_hosts request to the API.
The API returns json containing the hostname, mac_address & record_type for each host in the group. {"record_type": "A","hostname": "foo.example.com.","mac_address": "51:6B:00:A6:F5:77"}]
The client makes an ARP (ipv4) request to find the ip address of each host by mac address. arp |grep 51:6B:00:A6:F5:77 (192.168.0.20) at 51:6B:00:A6:F5:77 [ether] on eth0 For ipv6, the client can use ndp -an or ip -6 neigh instead of ARP (depending on OS).
The client then makes the API request to set other host's dns using the discovered ip addresses.
A reference client network-discovery.sh is included. It's a wrapper script that uses route53-ddns-client.sh to call the actual API.
The reference client uses local os cache via arp, ip or ndp commands to discover and match ip addresses to mac addresses. Note: The host running the network-discovery may not have all hosts in its cache at any given time. For ipv4, you could use nmap to scan the network. This method is impractical for ipv6 considering the huge number of potential addresses. Network discovery will not work as implemented inside a VPC as VPC is unicast only. If you have feedback on the utility of network-discovery or thoughts on improvements, please let us know!
Using an API Key - required for all requests if enabled Replace voN8GxIEvPf with key published in your stack outputs. curl -q --ipv4 -s -H 'x-api-key: voN8GxIEvPf' https://ddns.example.com?mode=get curl -q --ipv6 -s -H 'x-api-key: voN8GxIEvPf'"https://ddns.example.com?mode=set&hostname=foo.example.com&hash=ABCD123"
Generating the hash token needed for all other API requests mySharedSecret=123abc myPublicIP=73.222.111.6 myHostname=test.example.com. Note that hostname must end in a '.' echo -n "$myPublicIP$myHostname$mySharedSecret" | shasum -a 256
Set public ip - mode=set curl -q --ipv4 -s "https://ddns.example.com?mode=set&hostname=foo.example.com&hash=ABCD123" curl -q --ipv6 -s "https://ddns.example.com?mode=set&hostname=foo.example.com&hash=ABCD123"
Set private ip - mode=set curl -q -s "https://ddns.example.com?mode=set&hostname=foo.example.com&hash=ABCD123&internalIp=192.168.0.1" curl -q -s "https://ddns.example.com?mode=set&hostname=foo.example.com&hash=ABCD123&internalIp=2500:1ff3:e0e:4501:8cf0:c278:da3d:4120" Note that you can set either ipv4 or ipv6 private addresses regardless of the protocol used by curl.
List hosts in group for network discovery - mode=list_hosts curl -q -s "https://ddns.example.com?mode=list_hosts&hostname=foo.example.com&hash=ABCD123"
the BUNDY project is currently in hibernation status. It is not dead, but it is also not alive either. There is currently no active development, and no security bug fixes. We do not recommend using BUNDY as a production DNS server. BUNDY, due to it’s python code, is a great tool to prototype new DNS functions. It can be used as a prototyping tool. If you have interest on working on or with BUNDY, let us know. We can wake up BUNDY from sleep any time./
BUNDY provides an authoritative DNS server (with in-memory and SQLite3 backends), DNSSEC support, dynamic DNS, zone transfers. Supplementary components are included for statistics collection and reporting and remote configuration and control are included, as is an experimental recursive nameserver with support for forwarding. It is the continuation of the BIND 10 project from the ISC hosted at http://bind10.isc.org/.
Since the June 2013 1.1.0 BIND 10 release, the new DNS highlights include incoming zone transfer statistics, support for CAA and TLSA resource records, and the zone loader now supports the zone file $GENERATE directive. Note that the bundy-xfrin “use_ixfr” configuration item is deprecated and a new configuration “zones/request_ixfr” may be used to replace it. Also use “database_file” under the “data_sources” module for bundy-xfrin inbound transfers and use bundy-loadzone -e option to create an empty zone prior to the first transfer.
The suite also provides DHCPv4 and DHCPv6 servers, a dynamic DNS component, a DHCP performance testing program, and a C++ library for DHCP. ISC is continuing with the development of these components in a new project, Kea.
The ./configure options --disable-dns and --disable-dhcp may be used to provide an optional DHCP- or DNS-only build and installation.
Bundy was a sponsored development project (under the name BIND 10) from April 2009 to April 2014, and would not be possible without the generous support of the past sponsors: AFNIC, Afilias, CIRA, CNNIC, CZ.NIC, DENIC eG, Google, IIS.SE, JPRS, Nominet, .nz Registry Services, RIPE NCC, Registro.br, SIDN, and Technical Center of Internet. Support for the new DHCPv4 and DHCPv6 components is provided by Comcast.
The NLnet Labs Name Server Daemon (NSD) is an authoritative, RFC compliant DNS nameserver.https://nlnetlabs.nl/nsd
The NLnet Labs Name Server Daemon (NSD) is an authoritative DNS name server. It has been developed for operations in environments where speed, reliability, stability and security are of high importance. If you have any feedback, we would love to hear from you. Don’t hesitate to create an issue on Github or post a message on the NSD mailing list. You can lean more about NSD by reading our documentation.
Compiling
Make sure you have the C toolchain, OpenSSL and its include files, and libevent with its include files and flex and bison installed. The repository does not contain ./configure and you can generate it like this (./configure is included in release tarballs, and then you do not have to generate it first):
aclocal && autoconf && autoheader
NSD can be compiled and installed using:
./configure && make && make install
NSD configuration
The configuration options for NSD are described in the man pages, which are installed (use man nsd.conf) and are available on the NSD documentation page.
An example configuration file is located in nsd.conf.sample.
Net::DNS is a DNS resolver implemented in Perl. It allows the programmer to perform nearly any type of DNS query from a Perl script. For details and examples, please read the Net::DNS manual pages. To read about the latest features, see the Changes file. To discuss and share experiences with other users of Net::DNS, subscribe to the mailing-list.
Net::DNS does not depend on any C libraries. However, if possible Net::DNS tries to link to the libresolv library. This provides a notable speed increase.
The author invites feedback on Net::DNS. If there's something you'd like to have added, please let me know. If you find a bug, please follow the instructions below.
New releases and developments are announced on the "Blog" (which is syndicated through an RSS feed).
Net::DNS::SEC
In case you would like to add DNSSEC support to Net::DNS please check out Net::DNS::SEC, an add-on to this package, available thought CPAN
Net::DNS::SEC is tightly integrated with Net::DNS but distributed separately because its dependency on libraries that may not port to all platforms.
The current release version of Net::DNS::SEC is: 1.12.
New releases and developments are announced on the same "Blog" as Net::DNS.
Bugs?
If you have a bug report, drop it by CPAN's RT installation. Your problem will be assigned a ticketnumber and can be tracked.
Here's a direct link to the Net::DNS bug reporting form.
If you find a bug, please report it to the author along with the following information:
version of Perl (output of 'perl -V' is best)
version of Net::DNS
operating system type and version
version of nameserver (if known)
exact text of error message or description of problem
the shortest possible program that exhibits the problem
the specific queries you're making, if the data is available to Internet nameservers
If I don't have access to a system similar to yours, I may ask you to insert some debugging lines and report back on the results. The more help and information you can provide, the better.
Packages
Several operating systems provide a Net::DNS package. An incomplete list of those packages is available.
GRONG is a DNS authoritative name server.It is more a research project than a production-ready program.
GRONG (Gross and ROugh Nameserver written in Go) is a DNS (Domain Name System) authoritative name server. It is intended as a research project and is not probably suitable for use on the wild Internet.
MAY NOT BE SUITABLE ON A PRODUCTION SITE. YOU HAVE BEEN WARNED!!!
GRONG can only be used as an authoritative name server (like, for instance, nsd), not as a recursive one.
GRONG provides a general DNS engine, the front-end, which receives packets, parses them and sends a proper response, and several possible back-ends (named "responders") which generates a response, given the query. Some are provided with GRONG and you are welcome to write others.
Run with -help to see the defaults (and the other, less common, options)
The -address option takes either a port (in the syntax ":NNN"), in that case GRONG listens on all IP addresses, or one address (in the syntax "x.y.z.T:NNN" for IPv4 and "[xxxx:yyyy::zzzz]:NNN" for IPv6). There is currently no way to listen on some (but not all) of the IP addresses.
The -domain option takes a domain name, which will be the name of the zone for which the name server will be authoritative for. Not all responders use it.
The back-end is choosen at compile-time only (I have no idea about the support for dynamic linking in Go)
Among the provided responders: * rude-responder: responds REFUSED to every query * reflector-responder: responds with the IP address of the client (for TXT requests, in text form, for A or AAAA requests, as binary). -domain indicates the zone name it uses (e.g. whoami.example.net) * as112: an AS 112 name server (see <http://www.as112.net/>)
For the person who compiles **************************
You need a working Go <http://golang.org> environment. Today, only the gc compiler is supported.
To choose a responder (here, foobar-responder):
make clean ln -sf foobar-responder.go responder.go make mv ./server /where/you/want/grong-foobar
For the person who writes a responder ************************************
The interface of the responder is:
It must be in package "responder" and imports package "types". Read "types.go" first, it contains useful constants (named from the RFC 1035).
The front-end checks that the request is a query and, if so, calls the responder. The prototype is:
To see what is available for you in the query, see the description of type DNSquery. Important: the query name (Qname) is always in lowercase, to ease comparisons.
In the DNSresponse, RRs (Resource Records) have to be in the wire format (the front-end does not know the format of the RR, to keep it generic). For instance, data in TXT RR has to be {length, value}. There are some utilities functions in types to help you to do so.
The map named "config" above gives you access to global variables. You can never be sure what variables are defined so it is careful to test their existence before using them. Typical variables (read the source code of server.go to find others) are: * debug: an integer for the debug level (0 = no debug, 1 = a bit of debug, etc). Always set. * servername: if set, a string identifying this specific name server (for instance "cdg1.a.ns.example.net"). * zonename: if set, the name of the zone currently served (for instance "myself.example.net")
Since the map stores various types (the "interface{}", which means the empty interface, something which is fulfilled by every possible object), you often have to convert data with the reflect package. For instance, to get the integer value of debug: debug, exists := myconfig["debug"] if exists { debugi := reflect.NewValue(debug).(*reflect.IntValue).Get() }
The responder must also provide a function:
func Init(firstoption int)
which will be called at server startup and which can be used to process additional command-line flags (see as112.go for a good example) or any other stuff.
Implementation notes ********************
One goroutine is run for every DNS request. Makes the code much simpler and easier to read but may explain the fact that performance are behind BIND.
TODO ****
Finish the AS112 responder (SOA and NS records)
The ability to listen to more than one address (but not all). Can I give several -address option to the flag module? If so, it probably just means firing several udpListeners and several tcpListeners. Since it interacts with the IPv4/IPv6 listening abilities, we may have to wait for the solution of <http://code.google.com/p/go/issues/detail?id=679>.
Debugging of Go runtime performance issues, hit it harder with queryperf!
Test with gccgo
Implements version.server (and version.bind and hostname.bind ?)
See if we can replace a good part of package "types" by standard package net/ <http://golang.org/src/pkg/net/dnsmsg.go> It does not seem easy, the dns* files do not export anything outside of package net, they are meant for internal use only.
A name server with data, for instance able to serve a zone with a simple setup, one SOA, a few NS, and one A record for www.$ORIGIN. The list of zones (all with identical data) and the IP address of the Web server being taken from a file or on the command-line.
Continue hardening against rogue packets. See the example test-scapy.py in the distribution.
Michael Hoisie had a very good suggestion to turn GRONG into a package. He plans: 1) all the source files should have a common package, like "grong". there shouldn't be a main package 2) there could be a Responder interface, that looks like: type Responder interface { Respond(query.DNSquery) DNSresponse } And all the various responders would implement this. 3) The Makefile would have a format like (except modified for Grong): http://github.com/hoisie/web.go/blob/master/Makefile 4) Instead of main() method, there would be a method like Run( resp Responder ) that takes a responder and starts the server
An Authoritative DNS Server written purely in PHP.
This is an Authoritative DNS Server written in pure PHP. It will listen to DNS request on the default port (Default: port 53) and give answers about any domain that it has DNS records for. This class can be used to give DNS responses dynamically based on your pre-existing PHP code.
Requirements
PHP 7.1+
Needs either sockets or socket_create PHP extension loaded (which they are by default)
Example
Here is an example of DNS server usage:
require_once__DIR__.'/../vendor/autoload.php';
// JsonResolver created and provided with path to file with json dns records $jsonResolver=newyswery\DNS\Resolver\JsonResolver([ '/path/to/zones/example.com.json', '/path/to/zone/test.com.json', ]);
// System resolver acting as a fallback to the JsonResolver $systemResolver=newyswery\DNS\Resolver\SystemResolver();
// StackableResolver will try each resolver in order and return the first match $stackableResolver=newyswery\DNS\Resolver\StackableResolver([$jsonResolver, $systemResolver]);
// Create the eventDispatcher and add the event subscribers $eventDispatcher=new\Symfony\Component\EventDispatcher\EventDispatcher(); $eventDispatcher->addSubscriber(new\yswery\DNS\Event\Subscriber\EchoLogger());
// Create a new instance of Server class $server=newyswery\DNS\Server($stackableResolver, $eventDispatcher);
// Start DNS server $server->start();
Running example
Run composer install to install dependencies
Run php example/example.php to run the server
Query server using dig command to ensure proper functioning
$ dig @127.0.0.1 test.com A +short 111.111.111.111
$ dig @127.0.0.1 test.com TXT +short "Some text."
$ dig @127.0.0.1 test2.com A +short 111.111.111.111 112.112.112.112
Zone File Storage
PHP DNS Server supports three zone file formats out-of-the-box: JSON, XML, and YAML; each file format is supported by a specialised Resolver class: JsonResolver, XmlResolver, and YamlResolver, respectively. Example files are in the example/ directory.
NicTool is a open source DNS management suite that takes the headaches out of managing DNS data. NicTool provides a easy to use web interface that allows users with little dns knowledge the ability to manage dns zones and records.
Features
Web interface for users, admins, and clients
Validation of DNS data before acceptance
Permissions for users and groups
Delegatation of zones and zone records to users and/or groups
Logging of all DNS changes (who did what & when)
RDBMS data storage
API for automation and integration
Supported formats for exporting DNS data to servers
NicTool Server - Exposes the DNS data via a SOAP web service.
NicTool API - The NicTool API is what connects to the NicTool Server. The format of requests is defined in the reference API at http://www.nictool.com/docs/api/
NicTool Client - A CGI application thatt provides a web interface for managing DNS data. NicTool Client has customizable HTML templates and a CSS style sheet. It is slowly becoming a modern JS web app
Smart Proxy is a free open source project that provides restful API to subsystems such as DNS, DHCP, etc, for higher level orchestration tools such as Foreman.
A transparent reverse protocol agnostic socks proxy. It allows you to setup gateways to an onion and to hide the address of a reverse proxy from the server and the server's address from the general public. The main purpose is to allow clearnet access to tor hidden services.
To configure simply set the configuration parameters in config.py and then run:
./proxy start
It only requires root if the listener port is less than 1024.
The Practical Linux Hardening Guide provides a high-level overview of hardening GNU/Linux systems. It is not an official standard or handbook but it touches and uses industry standards.
This guide also provides you with practical step-by-step instructions for building your own hardened systems and services. One of the main goals is to create a single document covering internal and external threats.
The requirements are derived from the (NIST) 800-53 and related documents.
Please also remember:
This guide contains my comments that may differ from certain industry principles. If you are not sure what to do please see Policy Compliance.
The Importance of Hardening Linux
Simply speaking, hardening is the process of making a system more secure. Out of the box, Linux servers don’t come "hardened" (e.g. with the attack surface minimized). It’s up to you to prepare for each eventuality and set up systems to notify you of any suspicious activity in the future.
The process of hardening servers involves both IT ops. and security teams and require changes to the default configuration according to industry benchmarks.
Also for me, hardening is the fine art of doing the right things, even if they don't always look to have a big impact. It's always a balance between ease of use and protection.
You need to harden your system to protect your assets as much as possible. Why is it important? Please read a great, short article that explains the hardening process step by step by Michael Boelen.
How to Harden Linux
In my opinion, you should drop all non-industry policies, articles, manuals, and others especially on production environments and standalone home servers. These lists exist to give a false sense of security and aren't based on authority standards.
There are a lot of great GNU/Linux hardening policies available to provide safer operating systems compatible with security protocols. For me, CIS and the STIGs compliances are about the best prescriptive guides - but of course you can choose a different one (e.g. PCI-DSS, DISA).
Most of all you should use Security Benchmarks/Policies which describe consensus best practices for the secure configuration of target systems.
Configuring your systems in compliance eliminates the most common vulnerabilities. For example, CIS has been shown to eliminate 80-95% of known vulnerabilities.
On the other hand, these standards are complicated checklists (often for newbies, difficult to implement). In my opinion, ideally, real world implementation is automated via something like OpenSCAP.
You should use a rational approach because more is not better. Each environment is different, so even though security rules should all work in theory, sometimes things will not work as expected.
Hardening is not a simple process. Here are general rules following common best practices:
never use root account for anything that does not require it
only sudo individual commands
never set a server to run as root (except for initialization time) and ensure that it exits all unnecessary privileges before accepting requests
secure your firewall the best you can and forbid all unnecessary access
do not install unnecessary or unstable software
Which Distribution Should be Used
This guide is tested on Red Hat Enterprise Linux 7 and CentOS 7 distributions because these are:
free (CentOS) and open source
enterprise-class
stable and reliable
with great community support
built on coherent snapshots of old packages
Both distributions allow the use of certified tools which can parse and evaluate each component of the SCAP standard.
If you use another distribution - no problem, this guide is also for you.
A Security Technical Implementation Guide (STIG) is a cybersecurity methodology for standardizing security protocols within networks, servers, computers, and logical designs to enhance overall security.
National Institute of Standards and Technology (NIST)
The National Institute of Standards and Technology (NIST) is a physical sciences laboratory and a non-regulatory agency of the United States Department of Commerce.
Payment Card Industry Data Security Standard (PCI-DSS)
Payment Card Industry Data Security Standard (PCI-DSS) compliance is a requirement for any business that stores, processes, or transmits cardholder data.
In accordance with PCI-DSS requirements, establish a formal policy and supporting procedures for developing configuration standards for system components that are consistent with industry-accepted hardening standards like:
Center of Internet Security (CIS)
International Organization for Standardization (ISO)
SysAdmin, Audit, Network, and Security (SANS) Institute
National Institute of Standards and Technology (NIST)
Security Content Automation Protocol (SCAP)
Security Content Automation Protocol (SCAP) provides a mechanism to check configurations, vulnerability management and evaluate policy compliance for a variety of systems.
One of the most popular implementations of SCAP is OpenSCAP and it is very helpful for vulnerability assessment and as a hardening helper. OpenSCAP can easily handle the SCAP standards and generate neat, HTML-based reports.
The auditing system settings with SCAP Security Guide project contains guidance for settings for Red Hat/CentOS and it's validated by NIST.
You should inspect the security content of your system with oscap info module:
# For RHEL: oscap info /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml
# For CentOS: oscap info /usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml
OpenSCAP Base
The OpenSCAP scanner will only provide meaningful results if the content you want it to process is correct and up to date. The oscap tool scans your system, validates security compliance content, and generates reports and guides based on these scans.
The command-line tool, called oscap, offers a multi-purpose tool designed to format content into documents or scan the system based on this content. Whether you want to evaluate DISA STIGs, NIST‘s USGCB, or Red Hat’s Security Response Team’s content, all are supported by OpenSCAP.
Before use, please read Using OSCAP documentation.
# Installation: yum install openscap-scanner
# Make a RHEL7 machine e.g. PCI-DSS compliant: oscap xccdf eval --report report.html --profile xccdf_org.ssgproject.content_profile_pci-dss /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml
# Make a CentOS machine e.g. PCI-DSS compliant: oscap xccdf eval --report report.html --profile xccdf_org.ssgproject.content_profile_pci-dss /usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml
SCAP Workbench
SCAP Workbench is a utility that offers an easy way to perform common oscap tasks on local or remote systems.
This project covers some of the things in this guide which can be automated (e.g. setting of grub password or enforcing the permissions of the common directories). Its a good start if you want to make changes and see how it works from the level of automation tools.
docker run -d -e PARKOMAT_CONFIG_FILE=/opt/parkomat/config.toml -v /your/parkomat/directory:/opt/parkomat -p 53:53/udp parkomat/parkomat
Remember to have config.toml file in your /your/parkomat/directory path.
Example Configuration:
Note: instead of 127.0.0.1 use your external IP.
# if you set it to true, Parkomat will serve any domain pointing at it catch_all = true
[[domains]] name = "example.domain"
[[domains]] name = "parkomat.io" # supports per domain zone settings [domains.zone] A = "192.168.0.1" MX = """ 1 better.mail.server """ TXT = """ hello world """
# each domain will use following zone settings [zone] # for both .domain and www.domain A = "127.0.0.1" MX = ''' 1 test1.mail.server 10 test2.mail.server '''
[web] ip = "0.0.0.0" port = 80 path = "./www"
# make sure that path exists # for example issue mkdir -p /var/log/parkomat access_log = "/var/log/parkomat/access.log"
[webdav] enabled = true username = "hello" password = "world" # your share will be under http://example.domain/dav/ mount = "/dav/"
[dns] ip = "127.0.0.1" port = 53
# details of dns servers for NS record [[dns.servers]] name = "ns1.parkomat.co" ip = "127.0.0.1"
[[dns.servers]] name = "ns2.parkomat.co" ip = "127.0.0.1"
Make sure to create GLUE record for each dns server listed in [[dns.servers]]. You need to follow your registrar documentation on how to do it.
You can run multiple parkomat nodes for DNS server. Make sure they use the same configuration file (for example mounted via NFS).
To add new domain, simply create new directory with that domain name. If you want to use SSL, just copy domain.crtand domain.key files to that domain directory (be careful - do not upload them to public_html directory). You need to restart parkomat afterwards (SSL at the moment is not reloaded at runtime).
All your html and other files go to public_html directory.
WebDav
If you want to use WebDav with windows, the domain you will be using it with should have certificates uploaded. Apparently WebDav doesn't work without SSL on Windows.
If you like this App, please visit UNICEF tap project website http://tap.unicefusa.org/ and make a donation to the kids who need clean water supply.
# # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,USA.
This is an iPhone App that is a SOCS Proxy. It allows you to connect your laptop to the Internet through the iPhone's 3G/Edge connection (tethering.) If you want to install the application on your iPhone you will have to build and install the App from the the supplied code. * Pay Apple for iPhone development program * get a development certificat from Apple's developers portal * download the entire source code to a Mac * double click SOCKS.xcodeproj * in the left panel select Targers and then select SOCKS * press the "i" Info button on the top * select Properties tab * In the Identifier field change "symfi" to your company name * connect an iPhone using a cable * click Build and Debug
In order for this to work you need to follow few steps Instructions for Mac: * On your laptop start an add-hoc Wi-Fi network: * System Preferences->Network * select AirPort * click on Network Name and select Create Network * in Name enter "mywifi", press OK, press Apply * Connect you iPhone to the add-hoc wifi network: * Settings->Wi-Fi * select "mywifi" * Run this SOCKS App on your iPhone * In the SOCS Proxy tab press Start * configure your laptop to use SOCKS: * System Preferences->Network->Advanced...->Proxies * select SOCKS proxy * in the SOCKS Proxy Server field enter the address and port that appear on your iPhone screen * press OK * press Apply
Source for an iPhone App that is a SOCKS Proxy. It allows you to connect your laptop to the Internet through the iPhone's 3G/Edge connection (tethering) without having to jailbreak your iPhone. If you want to install the application on your iPhone you will have to build and install the App from the the supplied code. The code is completely legitimate and does not use any undocumented APIs and NO JAIL BREAK is required. But Apple will not approve such an App on its store so you will have to build it yourself: * Pay Apple for iPhone development program * get a development certificat from Apple's developers portal * configure your iPhone for development with Xcode (SDK 4) * download the entire source code to a Mac * double click SOCKS.xcodeproj * in the left panel select Targers and then select SOCKS * press the "i" Info button on the top * select Properties tab * In the Identifier field change "symfi" to your company name as it was used in the certificate * connect an iPhone using a cable * click Build and Debug
In order to use the SOCKS Proxy App for tethering you need to follow few steps: * On your laptop start an ad-hoc Wi-Fi network. On Mac this is done by: * System Preferences->Network * select AirPort * click on Network Name and select Create Network * in Name enter "mywifi", press OK, press Apply * Connect you iPhone to the add-hoc wifi network: * Settings->Wi-Fi * select "mywifi" * Run this SOCKS App on your iPhone * In the SOCS Proxy tab press Start * take note of the address and port that appear on the screen. * if you get the message "no Wifi" then you are not yet connected to the ad-hoc network. Wait a minute and try again. * put your iPhone face down on the table in order to save battery * configure your laptop application to use your SOCKS (with the above address and port). Some examples: * Safari on Mac (Firefox needs a different configuration): * System Preferences->Network->Advanced... * select Proxies * check SOCKS proxy * in the SOCKS Proxy Server field enter the address and port that appear on your iPhone screen * press OK * press Apply * Firfox on Mac * Firefox->Preferences...->Advanced->Network->Settings... * Select "Manual proxy configuation:" * enter IP and port of your iPhone in the SOCKS Host: and Port: * OK * Unix (Mac) shell commands can be made to use socks (socksify) using thetsockscommand (check the man page) (seealso). * tsocks is configured using the file /opt/local/etc/tsocks.conf for example, if the proxy is on 169.254.213.179:20000 then the file should look like:local = 127.0.0.1/255.255.255.255 local = 169.254.0.0/255.255.0.0 server = 169.254.213.179 server_port = 20000 server_type = 5* When finished remember to disable the usage of SOCKS in your laptop application: * Safari Mac: uncheck the above SOCKS proxy and press OK and Apply to restore regular connectivity On iOS device with background capability (iPhone 3GS with iOS 4 or iPhone 4) you can leave the app and do something else (like pulling mail on your iPhone, playing on your iPod app) as long as you return back fast enough (in about 10min) to the SOCKS app.
GitHub repository: