Database backed DNS Management Solutions
Dear NANOG: I hope I can solicit some feedback from this venerable group. :-) Currently, my group operates 16 BIND servers across 5 datacenters, handling internal and external namespace duties. These servers are responsible for both internal and external forward and reverse name and IP spaces. There are also a number of Windows AD servers that hold their own namespaces, that the BIND servers slave from this info from, so names resolve between these domains. Windows AD forwards queries for internal zones it does not own to the appropriate namespace holder. So Windows DNS server interoperability is a business requirement. Some of these zones are dynamic, some are static. None of the dynamic zones are populated via DHCP, but by self-registration. We have heretofore used some in-house scripts for managing this, but obviously, the thought of keeping and managing this data in something other than its current form has caught on in our minds, and so therefore we are looking at a proposal put forth, to replace all of our BIND servers with a PowerDNS infrastructure. BIND has been the backbone of the Internet, and so many of us are wary of replacing BIND, when in essence, BIND itself is not the issue, nor is it broken. Has anyone done any in house comparance of PowerDNS versus BIND-DLZ? Googling has led to some useful info but no useful side by side comparances that are not obviously partisan. I favor something like ProBIND2, that keeps the data in the DB, but does not tie the serving of the data, etc to anything other than BIND. Any success/horror stories from implementing BIND management solutions is very welcome. If anyone has any success/horror stories about PowerDNS, BIND-DLZ, or a system like ProBind2 or NetDB (from Stanford) to manage BIND and its configurations in a DB, I would be very interested in hearing them. :-) Thank you. Best Regards, Ross S. Dmochowski Sr. Linux Administrator IGN/Gamespy/Fox Interactive Media r...@ign.com
RE: gTLD root nameserver anomaly
sorry, nm. glue records in the rootzones, that no one should have put. I'll go back in my corner now. -Original Message- From: Ross Dmochowski Sent: Wednesday, August 06, 2008 12:33 PM To: nanog@nanog.org Subject: gTLD root nameserver anomaly Importance: High Something weird seems afoot in the root nameservers. I am noticing that the root nameservers are handing out extra info with TTLs much longer than those delineated in the respective zone file on the authoritative nameserver for that zone. Case in point: I asked my local DNS server for ns2.gamespy.com and it went directly to a gtld server (f.gtld-servers.net.): 08:25:27.541627 IP 172.19.2.15.45505 192.35.51.30.domain: 42289% [1au] A? ns2.gamespy.com. (44) 08:25:27.544415 IP 192.35.51.30.domain 172.19.2.15.45505: 42289- 1/5/3 A 207.38.0.11 (229) and returned an answer with the larger TTL: dig ns2.gamespy.com ; DiG 9.2.4 ns2.gamespy.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 37167 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 7 ;; QUESTION SECTION: ;ns2.gamespy.com. IN A ;; ANSWER SECTION: ns2.gamespy.com.172800 IN A 207.38.0.11 ;; AUTHORITY SECTION: gamespy.com.172800 IN NS pdns4.ultradns.org. gamespy.com.172800 IN NS pdns5.ultradns.info. gamespy.com.172800 IN NS pdns1.ultradns.net. gamespy.com.172800 IN NS pdns2.ultradns.net. gamespy.com.172800 IN NS pdns3.ultradns.org. ;; ADDITIONAL SECTION: pdns1.ultradns.net. 131158 IN A 204.74.108.1 pdns1.ultradns.net. 44758 IN 2001:502:f3ff::1 pdns2.ultradns.net. 131158 IN A 204.74.109.1 pdns3.ultradns.org. 44758 IN A 199.7.68.1 pdns4.ultradns.org. 44758 IN A 199.7.69.1 pdns4.ultradns.org. 44758 IN 2001:502:4612::1 pdns5.ultradns.info.44758 IN A 204.74.114.1 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Aug 6 08:25:27 2008 ;; MSG SIZE rcvd: 322 but if I ask an UltraDNS server directly...it returns the correct TTL dig @204.74.108.1 ns2.gamespy.com ; DiG 9.2.4 @204.74.108.1 ns2.gamespy.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 23978 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 0 ;; QUESTION SECTION: ;ns2.gamespy.com. IN A ;; ANSWER SECTION: ns2.gamespy.com.300 IN A 207.38.0.11 ;; AUTHORITY SECTION: gamespy.com.300 IN NS PDNS6.ULTRADNS.CO.UK. gamespy.com.300 IN NS PDNS5.ULTRADNS.INFO. gamespy.com.300 IN NS PDNS4.ULTRADNS.ORG. gamespy.com.300 IN NS PDNS3.ULTRADNS.ORG. gamespy.com.300 IN NS PDNS2.ULTRADNS.NET. gamespy.com.300 IN NS PDNS1.ULTRADNS.NET. but unfortunately, my nameserver honors (as expected) the TTL that came back from the initial request ;; ANSWER SECTION: ns2.gamespy.com.172493 IN A 207.38.0.11 Another example would be 'gss1.foxtv.com'. I changed the IP for that server on Sunday night, and if you ask the authoritative nameservers (for IGN), they give you the correct response. However, when you do a trace, once can see that the gTLD server gives out its own info, which is not correct, and no one ever seems to get to the authoritative nameserver to get the appropriate information. -bash-2.05b$ dig +trace gss1.foxtv.com ; DiG 9.2.4 +trace gss1.foxtv.com ;; global options: printcmd . 1796IN NS f.root-servers.net. . 1796IN NS g.root-servers.net. . 1796IN NS h.root-servers.net. . 1796IN NS i.root-servers.net. . 1796IN NS j.root-servers.net. . 1796IN NS k.root-servers.net. . 1796IN NS l.root-servers.net. . 1796IN NS m.root-servers.net. . 1796IN NS a.root-servers.net. . 1796IN NS b.root-servers.net. . 1796IN NS c.root-servers.net. . 1796IN NS d.root-servers.net. . 1796IN NS e.root-servers.net
