Warren's wildcard DNS setup for the .com TLD

[Bill Larson]

I believe that my organization may have been clobbered by this setup last week.
It took about six hours to track down servers with the invalid information and
clear their cache.

To prevent this situation, Paul made the suggestion that BIND could be setup
such that DNS information wouldn't be dessiminated if "at least one of the
server's IP addresses can't be found in the NS glue".  How would this proposal
be affected by DNS forwarding?

My situation is that DNS queries must be forwarded to an NT server (corporate
policy to insure that private DNS information is available).  By dumping the
cache on my BIND servers because of this problem, none of the corrupt DNS
information had any glue records associated with it at all.  Originally I
thought that this was an indicator for this problem, but there was numerous
other zone information available, apparently valid, that also had no glue.
(When I am refering to "glue" I mean the IP addresses for the name servers for
the zone, but also the "NS" records themselves.  I normally think of "glue" as
just the "A" records for the identified name servers.)

Is this situation with forwarding limited to forwarding to NT servers, or is
this how BIND also functions?  If the lack of NS records for zone information
obtained by forwarding is inherent with forwarding, would this proposal help in
a situation where there is no glue (NS records and A records) for a zone?

Bill Larson

Michael Kjorling wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Jun 30 2001 09:52 -0700, Paul Vixie wrote:
>
> > > I have received a bunch of emails lately from different people who are
> > > upset with Warren's setup of his DNS server as authorative for the
> > > .com top-level domain with a wildcard address record directing lots of
> > > traffic to his web pages.
> >
> > I wasn't paying attention to that thread.  Ick.  So THAT's what's going on.
>
> Yes, that is what was/is going on. And my apologizes extend to the
> entire Internet community and everyone who have to put up with all
> this.
>
> > Should some future version BIND refuse to serve queries for zones where at
> > least one of the server's IP addresses can't be found in the NS glue?  (It
> > has to serve AXFR in case it's a stealth master.)
>
> I can see an even simpler fix - the question is if it'll have the
> intended effect. I make it an RFC in this newsgroup/mailing list.
>
> Say that I am querying for foo.bar.com, and bar.com has the name
> servers ns1.bar.com and ns2.bar.com. Then, refuse to accept any
> authority records which do not mention hosts (DNS labels to the
> *left* of the RRtype) under bar.com.
>
> Recursion should be turned off on all publicly accessible servers
> anyway, so this won't break things too much. It's only about enforcing
> a good policy. It could be a good idea to put this as an option for
> those who actually need to accept authority records like those, but
> the default should definitely be to ignore them.
>
> The downside of such a setup is that it would increase the load on the
> root name servers; however, it would make attacks like Warren's
> impossible to mount.
>
> Your suggestion seems fairly good to me, with one downside. Stealth
> slaves. My first impression is that those would be much harder to set
> up, especially if you're running caching BIND servers for some reason
> pointed (via forwarding, for example) to the stealth slave server.
>
> What do you guys say? I am still rather new about DNS - there are a
> lot of people here who have much more experience than I do. Is this a
> workable route?
>
> Michael Kjörling
>
> - --
> Michael Kjörling - michael at kjorling.com - PGP: 8A70E33E
> "We must be the change we wish to see" (Mahatma Gandhi)
>
> ^..^     Support the wolves in Norway -- go to     ^..^
>  \/   http://home.no.net/ulvelist/protest_int.htm   \/
>
> ***** Please only send me emails which concern me *****
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE7Pg58KqN7/Ypw4z4RAmkuAKCBgZwUXpXf8vBdXNopcDBaeQ+CiACfR5bt
> XnpfTQ/C8/GFzEZ0slZ5Q6E=
> =YaUJ
> -----END PGP SIGNATURE-----