No description
5eca8e269a
Previously if the resolver was asked for a record it didn't have, it would
return a response with a NS record in the authority section. This is
incorrect, as the lack of answer indicates to the resolver that it should try
that NS record as the next step, resulting in a loop:
$ dig @8.8.8.8 rbf-seed.btc.petertodd.org TXT +trace
<snip>
rbf-seed.btc.petertodd.org. 300 IN NS rbf-seed-ns1.btc.petertodd.org.
rbf-seed.btc.petertodd.org. 300 IN NS rbf-seed-ns2.btc.petertodd.org.
;; Received 141 bytes from 205.251.193.174#53(ns-430.awsdns-53.com) in 426 ms
rbf-seed.btc.petertodd.org. 40000 IN NS rbf-seed-ns2.btc.petertodd.org.
;; BAD (HORIZONTAL) REFERRAL
;; Received 88 bytes from 185.52.1.173#53(rbf-seed-ns2.btc.petertodd.org) in 108 ms
rbf-seed.btc.petertodd.org. 40000 IN NS rbf-seed-ns2.btc.petertodd.org.
;; BAD (HORIZONTAL) REFERRAL
;; Received 88 bytes from 185.52.1.173#53(rbf-seed-ns2.btc.petertodd.org) in 108 ms
<snip>
rbf-seed.btc.petertodd.org. 40000 IN NS rbf-seed-ns2.btc.petertodd.org.
;; BAD (HORIZONTAL) REFERRAL
dig: too many lookups
The correct response in the authority section of a negative response is a SOA
record, which indicates that the answer is authoritative and the resolver can
consider the record missing and stop looking for it:
$ dig @8.8.8.8 rbf-seed.btc.petertodd.org TXT +trace
<snip>
rbf-seed.btc.petertodd.org. 300 IN NS rbf-seed-ns1.btc.petertodd.org.
rbf-seed.btc.petertodd.org. 300 IN NS rbf-seed-ns2.btc.petertodd.org.
;; Received 141 bytes from 205.251.196.185#53(ns-1209.awsdns-23.org) in 740 ms
rbf-seed.btc.petertodd.org. 40000 IN SOA rbf-seed-ns1.btc.petertodd.org. pete.petertodd.org. 1435846201 604800 86400 2592000 604800
;; Received 128 bytes from 104.236.95.174#53(rbf-seed-ns1.btc.petertodd.org) in 31 ms
There have been a few reports of problems resolving seed domains on some
ISPs - hopefully this was the root cause.
|
||
|---|---|---|
| .gitignore | ||
| bitcoin.cpp | ||
| bitcoin.h | ||
| combine.pl | ||
| compat.h | ||
| db.cpp | ||
| db.h | ||
| dns.c | ||
| dns.h | ||
| main.cpp | ||
| Makefile | ||
| netbase.cpp | ||
| netbase.h | ||
| protocol.cpp | ||
| protocol.h | ||
| README | ||
| serialize.h | ||
| strlcpy.h | ||
| test.pl | ||
| uint256.h | ||
| util.cpp | ||
| util.h | ||
bitcoin-seeder ============== Bitcoin-seeder is a crawler for the Bitcoin network, which exposes a list of reliable nodes via a built-in DNS server. Features: * regularly revisits known nodes to check their availability * bans nodes after enough failures, or bad behaviour * accepts nodes down to v0.3.19 to request new IP addresses from, but only reports good post-v0.3.24 nodes. * keeps statistics over (exponential) windows of 2 hours, 8 hours, 1 day and 1 week, to base decisions on. * very low memory (a few tens of megabytes) and cpu requirements. * crawlers run in parallel (by default 24 threads simultaneously). REQUIREMENTS ------------ $ sudo apt-get install build-essential libboost-all-dev libssl-dev USAGE ----- Assuming you want to run a dns seed on dnsseed.example.com, you will need an authorative NS record in example.com's domain record, pointing to for example vps.example.com: $ dig -t NS dnsseed.example.com ;; ANSWER SECTION dnsseed.example.com. 86400 IN NS vps.example.com. On the system vps.example.com, you can now run dnsseed: ./dnsseed -h dnsseed.example.com -n vps.example.com If you want the DNS server to report SOA records, please provide an e-mailadres (with the @ part replaced by .) using -m. RUNNING AS NON-ROOT ------------------- Typically, you'll need root privileges to listen to port 53 (name service). One solution is using an iptables rule (Linux only) to redirect it to a non-privileged port: $ iptables -t nat -A PREROUTING -p udp --dport 53 -j REDIRECT --to-port 5353 If properly configured, this will allow you to run dnsseed in userspace, using the -p 5353 option.