Our annual survey of the Internet's DNS infrastructure measures (among other things) the percentage of a random sample of com, net and org subzones that use SPF. In the October 2009 survey, we found that 12.2% of the sample used SPF records. For more information, see http://dns.measurement-factory.com/surveys/200910.html
I beg to differ. BIND 9 isn't worse at reading zone data files, it's just much stricter. If it wouldn't read your zone data files, that's likely because you were taking advantage of BIND 8's sloppy zone data file parsing to do something illegal like attaching multiple CNAME records to the same owner name.
Active Directory should work with any name server that supports SRV records and dynamic update (IXFR would be handy, too). I imagine there are name servers besides BIND that fall into that category.
Don't blame BIND for DNS's master file format. BIND reads the format described in the RFCs, not a format coined specifically for it.
I won't deny that master file format is subtle and fraught with occasion for error, but it's also the lingua franca of zone data. Anyone working with DNS should understand it. It's the format query tools like dig produce, for one. How can you expect to understand dig's output if you can't read master file format?
It's not "BIND's zone-file format"--it's master file format, as described in the RFCs. Anything that calls itself a DNS server ought to read master file format (and optionally other formats).
How does this fix the problem? You've advocating using alternate roots, but they delegate to the same com name servers that the ICANN roots delegate to. And those com name servers contain the wildcard.
No, they're really redundant. They come from the very same source IP address, ask the same question, and often bear the same random message ID in the DNS message header, indicating that the name server that sent the dupe really didn't receive or follow the referral that the root sent.
Many of the "fixes" are up to the implementors of resolvers and name servers, but here are a couple of concrete measures you can take with your DNS infrastructure:
- If you use RFC 1918 address space internally, make sure your name servers are authoritative for the corresponding reverse-mapping zones. Also make sure your border router doesn't allow RFC 1918 source addresses out.
- If you use Active Directory internally, make sure your name servers are authoritative for the zones that correspond to your Active Directory domain's name.
BIND 4 name servers always sent queries from port 53 and to port 53. BIND 8 and 9 name servers, however, send queries from ephemeral ports to port 53. So some firewall administrators who haven't kept up allow outbound DNS messages to port 53 on Internet name servers, but only allow inbound DNS messages to port 53, which cuts off the responses.
Yup, they're rolling out anycast now. See this article on the Asia-Pacific rollout and this article on the rollout of a new replica of f.root-servers.net in Madrid.
You must have matriculated a long time ago. The roots have had recursion disabled for years. Pointing a resolver at them just returns referrals that your resolver can't interpret.
Actually, one of the three vulnerabilities was in the resolver library, not in the name server.
Re:just because I'm too lazy to search...
on
Root Zone Changed
·
· Score: 1
The maximum size of a DNS message over UDP is 512 bytes (unless you're using EDNS0, which is relatively new). 13 NS records and the 13 corresponding A records just fits into 512 bytes, assuming domain name compression is working as efficiently as possible. And to make compression work as efficiently as possible, the domain names in the NS records should be as similar as possible, as in [a-m].root-servers.net.
If you've been around the Internet long enough, you might remember a time when the root name servers had names like ns.nasa.gov, and there were fewer of them. Changing the names to [a-m].root-servers.net bought us room for 13.
I'm not sure this is what you're thinking of, but Carl Oppedahl (of patents.com fame) has set something like this up in Ruby Ranch, Colorado, but for DSL, not wireless. See this link or this one for details.
Apparently ICANN's choices of far-flung venues have put off some members from attending: there's apparently an armful of vaccinations necessary or recommended before traveling to Ghana, for example.
Guess you won't find many ICANN attendees down at the local blood bank donating.
"The useless idea of zones"? The concept of zones is integral to delegation, which is in turn vital to decentralizing management of the naming database.
As for "the discomfort BIND developers [have] with alternate root servers," the IETF has also gone on record as favoring a single root.
I remember seeing "Amadeus" for the first time: When he conducts "Don Giovanni" for the first time ("Don Gio-VANNI! Don Gio-VANNI!"), I remember thinking, hey, they ripped this off from "What's Opera Doc." Then I realized my mistake.
There's no reason we have to use whichever ACE becomes the standard in the domain names of root name servers. We sacrificed the old domain names of the root name servers (e.g., ns.nasa.gov) to the greater good of better domain name compression years ago.
The countervailing force is EDNS0, which will allow 4096 byte UDP-based DNS messages. And BIND 8.3.0, recently released, supports EDNS0. f's already running it. Once 8.3.0 is fully deployed on the roots, I think additional root name servers are just a quick hack away:
- System query without EDNS0: You get 13 root name servers
- System query with EDNS0: You get more
The problem is that 13 is a magic number in DNS. The maximum size of a DNS message when carried over UDP is 512 bytes. And guess how many NS records and associated A records you can fit in 512 bytes, assuming domain name compression is working as efficiently as possible? Thirteen.
If you add more root name servers, when name servers look up the list of root name servers (via something called a system query) you truncate the DNS message, and then those name servers retry over TCP and all hell breaks loose.
That said, two of the existing roots (j and l) are temporarily housed at ISI and VeriSign, which already have roots. Those two really need to be deployed to parts of the Internet that need them.
Actually, the root name servers and the gTLD name servers are now totally separate. Many of the roots were once authoritative for both the root zone and the gTLD zones, but not any more.
I think this is a crucial point: A degree in CS can lead to careers besides programming.
I was a disillusioned CS major, too--a good-but-not-great student at Berkeley. Like you, my GPA was higher outside the major than inside. I figured that my only career option was to become a mediocre programmer.
After graduation, I did work as a programmer for a few years, but I quickly found that there were other jobs I liked better. I eventually gravitated to networking, where I worked as a hostmaster (that guy who runs your company's name servers), then as a consultant and as an instructor. And I'm sure there are plenty of career options I didn't explore that would have been interesting, too.
So don't think of a CS degree as a one-way ticket to programming. Think of it as an analogue to a law degree. A remarkably small percentage of people with law degrees actually take the bar and practice law. Many of them end up in business, in politics, or in other careers that require critical, analytical thinking. Likewise, a CS degree can qualify you for lots of jobs that require logical thought and an understanding of technology.
Slashdot Mirror
Folks, Chu is the Secretary of Energy, not Treasury. See http://en.wikipedia.org/wiki/Steven_Chu.
Our annual survey of the Internet's DNS infrastructure measures (among other things) the percentage of a random sample of com, net and org subzones that use SPF. In the October 2009 survey, we found that 12.2% of the sample used SPF records. For more information, see http://dns.measurement-factory.com/surveys/200910.html
I beg to differ. BIND 9 isn't worse at reading zone data files, it's just much stricter. If it wouldn't read your zone data files, that's likely because you were taking advantage of BIND 8's sloppy zone data file parsing to do something illegal like attaching multiple CNAME records to the same owner name.
Active Directory should work with any name server that supports SRV records and dynamic update (IXFR would be handy, too). I imagine there are name servers besides BIND that fall into that category.
Don't blame BIND for DNS's master file format. BIND reads the format described in the RFCs, not a format coined specifically for it.
I won't deny that master file format is subtle and fraught with occasion for error, but it's also the lingua franca of zone data. Anyone working with DNS should understand it. It's the format query tools like dig produce, for one. How can you expect to understand dig's output if you can't read master file format?
It's not "BIND's zone-file format"--it's master file format, as described in the RFCs. Anything that calls itself a DNS server ought to read master file format (and optionally other formats).
How does this fix the problem? You've advocating using alternate roots, but they delegate to the same com name servers that the ICANN roots delegate to. And those com name servers contain the wildcard.
Or are you suggesting setting up a new com?
No, they're really redundant. They come from the very same source IP address, ask the same question, and often bear the same random message ID in the DNS message header, indicating that the name server that sent the dupe really didn't receive or follow the referral that the root sent.
Many of the "fixes" are up to the implementors of resolvers and name servers, but here are a couple of concrete measures you can take with your DNS infrastructure:
- If you use RFC 1918 address space internally, make sure your name servers are authoritative for the corresponding reverse-mapping zones. Also make sure your border router doesn't allow RFC 1918 source addresses out.
- If you use Active Directory internally, make sure your name servers are authoritative for the zones that correspond to your Active Directory domain's name.
BIND 4 name servers always sent queries from port 53 and to port 53. BIND 8 and 9 name servers, however, send queries from ephemeral ports to port 53. So some firewall administrators who haven't kept up allow outbound DNS messages to port 53 on Internet name servers, but only allow inbound DNS messages to port 53, which cuts off the responses.
The ISC provides a port of BIND to Windows, too. See this link.
gethostbyname() does a simple sequential search of /etc/hosts, so the amount of time it takes to do a lookup scales linearly with the size of the file.
Yup, they're rolling out anycast now. See this article on the Asia-Pacific rollout and this article on the rollout of a new replica of f.root-servers.net in Madrid.
You must have matriculated a long time ago. The roots have had recursion disabled for years. Pointing a resolver at them just returns referrals that your resolver can't interpret.
Actually, one of the three vulnerabilities was in the resolver library, not in the name server.
The maximum size of a DNS message over UDP is 512 bytes (unless you're using EDNS0, which is relatively new). 13 NS records and the 13 corresponding A records just fits into 512 bytes, assuming domain name compression is working as efficiently as possible. And to make compression work as efficiently as possible, the domain names in the NS records should be as similar as possible, as in [a-m].root-servers.net.
If you've been around the Internet long enough, you might remember a time when the root name servers had names like ns.nasa.gov, and there were fewer of them. Changing the names to [a-m].root-servers.net bought us room for 13.
I'm not sure this is what you're thinking of, but Carl Oppedahl (of patents.com fame) has set something like this up in Ruby Ranch, Colorado, but for DSL, not wireless. See this link or this one for details.
Apparently ICANN's choices of far-flung venues have put off some members from attending: there's apparently an armful of vaccinations necessary or recommended before traveling to Ghana, for example.
Guess you won't find many ICANN attendees down at the local blood bank donating.
"The useless idea of zones"? The concept of zones is integral to delegation, which is in turn vital to decentralizing management of the naming database.
As for "the discomfort BIND developers [have] with alternate root servers," the IETF has also gone on record as favoring a single root.
I remember seeing "Amadeus" for the first time: When he conducts "Don Giovanni" for the first time ("Don Gio-VANNI! Don Gio-VANNI!"), I remember thinking, hey, they ripped this off from "What's Opera Doc." Then I realized my mistake.
Nothing like a little cultural dyslexia.
There's no reason we have to use whichever ACE becomes the standard in the domain names of root name servers. We sacrificed the old domain names of the root name servers (e.g., ns.nasa.gov) to the greater good of better domain name compression years ago.
The countervailing force is EDNS0, which will allow 4096 byte UDP-based DNS messages. And BIND 8.3.0, recently released, supports EDNS0. f's already running it. Once 8.3.0 is fully deployed on the roots, I think additional root name servers are just a quick hack away:
- System query without EDNS0: You get 13 root name servers
- System query with EDNS0: You get more
The problem is that 13 is a magic number in DNS. The maximum size of a DNS message when carried over UDP is 512 bytes. And guess how many NS records and associated A records you can fit in 512 bytes, assuming domain name compression is working as efficiently as possible? Thirteen.
If you add more root name servers, when name servers look up the list of root name servers (via something called a system query) you truncate the DNS message, and then those name servers retry over TCP and all hell breaks loose.
That said, two of the existing roots (j and l) are temporarily housed at ISI and VeriSign, which already have roots. Those two really need to be deployed to parts of the Internet that need them.
Actually, the root name servers and the gTLD name servers are now totally separate. Many of the roots were once authoritative for both the root zone and the gTLD zones, but not any more.
Initially the update just gets journaled, but periodically, and on exit, BIND name servers rewrite the entire data file for a dynamic zone.
I think this is a crucial point: A degree in CS can lead to careers besides programming.
I was a disillusioned CS major, too--a good-but-not-great student at Berkeley. Like you, my GPA was higher outside the major than inside. I figured that my only career option was to become a mediocre programmer.
After graduation, I did work as a programmer for a few years, but I quickly found that there were other jobs I liked better. I eventually gravitated to networking, where I worked as a hostmaster (that guy who runs your company's name servers), then as a consultant and as an instructor. And I'm sure there are plenty of career options I didn't explore that would have been interesting, too.
So don't think of a CS degree as a one-way ticket to programming. Think of it as an analogue to a law degree. A remarkably small percentage of people with law degrees actually take the bar and practice law. Many of them end up in business, in politics, or in other careers that require critical, analytical thinking. Likewise, a CS degree can qualify you for lots of jobs that require logical thought and an understanding of technology.