To all DNS admins: please check that you don't have 199.0.55.3 and 144.228.8.227 mentioned anywhere in your files. If you do, remove such records and change your DNS server software to something more reasonable. Dima fed up his ears with named's chronic inability to filter out bogus additional records
...
Dima fed up his ears with named's chronic inability to filter out bogus additional records
I have done, algorithmically, everything that can be done at that level. At this point we are going to have to wait for DNSSEC or some other wire protocol change. If you have suggestions to the contrary I would like to hear them. (And if you have money to pay for BIND improvements I would like to hear about that, too.)
Ignoring additional records works pretty well for me. Otherwise, the beast is out there, and we cannot do much except waiting for it to die slowly. Dima P.S. For those who wonder what is so special about these addresses - they were SprintLink's DNS servers' around Wilhelm the Conqueror's time or shortly after that. Apparently, some clueless admins have these addresses as bogus glue records in their zones and use vintage named versions that allow them to do that. Once leaked out in additional sections of DNS responses, these bogus records end up in other servers' caches, which in turn try to use these addresses to resolve queries for names for which SprintLink's servers are claimed to be authoritative. P.P.S. In two hours about 400 servers tried to use hrn-cat-2.sprintlink.net (a Catalyst something) as a name server. Paul A Vixie writes:
I have done, algorithmically, everything that can be done at that level. At this point we are going to have to wait for DNSSEC or some other wire protocol change. If you have suggestions to the contrary I would like to hear them. (And if you have money to pay for BIND improvements I would like to hear about that, too.)
Ignoring additional records works pretty well for me.
This is harder than it looks. Sometimes the glue A RRs are the only ones you can get -- you need them in order to ask questions in the domain they are in, so without them you have infinite regress. We are planning to store these glue A RRs as query-temporary data shortly, such that they can be used to try to refetch themselves but will never be returned as answers to any other query. Danger, what follows is a request for money. If you expect that to offend you, then hit some key that will delete this message without further ado. Note that the Internet Software Consortium is funded by vendors and ISPs, and that we are currently doing work on INN, BIND, and DHCP. It takes a lot of money to feed all these programmers. If you feel that you are monetarily benefitting from our work on this software, please consider making a donation. (Thanks are due to UUNET for past years' funding, and to Usenix, IBM, and Network Solutions for this year's partial funding.)
What sort of budget needs are there? Can you suggest what an "average" donation amount would be assuming some level of participation from the ISP and "beneficiary" community? Ed On Thu, 23 Jan 1997, Paul A Vixie wrote:
Ignoring additional records works pretty well for me.
This is harder than it looks. Sometimes the glue A RRs are the only ones you can get -- you need them in order to ask questions in the domain they are in, so without them you have infinite regress.
We are planning to store these glue A RRs as query-temporary data shortly, such that they can be used to try to refetch themselves but will never be returned as answers to any other query.
Danger, what follows is a request for money. If you expect that to offend you, then hit some key that will delete this message without further ado.
Note that the Internet Software Consortium is funded by vendors and ISPs, and that we are currently doing work on INN, BIND, and DHCP. It takes a lot of money to feed all these programmers. If you feel that you are monetarily benefitting from our work on this software, please consider making a donation. (Thanks are due to UUNET for past years' funding, and to Usenix, IBM, and Network Solutions for this year's partial funding.)
Ed Morin Northwest Nexus Inc. (206) 455-3505 (voice) Professional Internet Services edm@nwnexus.WA.COM
Paul A Vixie writes:
Ignoring additional records works pretty well for me.
This is harder than it looks. Sometimes the glue A RRs are the only ones you can get -- you need them in order to ask questions in the domain they are in, so without them you have infinite regress.
As I said, it works fine for me. When no A record for a nameserver is available, named just issues a proper request for it to whatever server might now about it. Here's the patch: *** named/ns_resp.c.old Mon Nov 11 01:36:51 1996 --- named/ns_resp.c Thu Jan 23 19:01:30 1997 *************** *** 272,278 **** qdcount = ntohs(hp->qdcount); ancount = ntohs(hp->ancount); aucount = ntohs(hp->nscount); /* !!! */ ! arcount = ntohs(hp->arcount); free_addinfo(); /* sets addcount to zero */ cp = msg + HFIXEDSZ; dpp = dnptrs; --- 272,281 ---- qdcount = ntohs(hp->qdcount); ancount = ntohs(hp->ancount); aucount = ntohs(hp->nscount); /* !!! */ ! if (qp->q_flags & Q_PRIMING) ! arcount = ntohs(hp->arcount); ! else ! arcount = 0; free_addinfo(); /* sets addcount to zero */ cp = msg + HFIXEDSZ; dpp = dnptrs; It's a darn dirty kluge, but it works. The correct way to do that is to make sure that the responding server is in the hierarchy chain of an additional record, and ignore the record, if it's not. Note the Reply-To header. Dima
Ignoring additional records works pretty well for me.
This is harder than it looks. Sometimes the glue A RRs are the only ones you can get -- you need them in order to ask questions in the domain they are in, so without them you have infinite regress.
This might be naive but: AFAIK the only time you *need* glue A RRs rather than normal A RRs is when you are looking for a namserver whose name is within the zone, i.e. within .com foo NS ns.foo.com ns.foo.com A 1.2.3.4 foo NS ns2.foo.com ns2.foo.com A 2.3.4.5 foo NS ns.bar.net the top two are correct glues, and the bottom one doesn't need one. The danger is that the A record is incorrect, or that someone has stuck it in unnecessarilly, like (in .com) foo NS ns.bar.net ns.bar.net A 5.6.7.8 So, why not tag such glue records when the go in the cache as suspect. Then when you first refer to them, query them for their own A record. IE in the top example above, when the A RR for ns.foo.com is just about to be pulled out the cache, it is has some marking as "suspect", so a direct query for an A RR for ns.foo.com is made. This first tries 1.2.3.4 (which we think is ns.foo.com). We do this with norecurse set. If the glue record is right, it returns 1.2.3.4 and it goes into the cache OK. If the glue record is wrong, the query fails and we try the secondaries. This one might be wrong too, in which case we continue until we get a correct one (here ns.bar.net). I spent a few (fruitless) hours trying to work out why 1/2 the internet had incorrect A records for ns.uu.net and in the end concluded (as I say, perhaps niavely) that something like the above would solve the problem. Alex Bligh Xara Networks
Is something like a web page listing the "bogusns"s of the day in order? We could include the broken servers that claim to be root servers for non-existant TLDs like .space. Dean On Thu, 23 Jan 1997, Dima Volodin wrote:
To all DNS admins:
please check that you don't have 199.0.55.3 and 144.228.8.227 mentioned anywhere in your files. If you do, remove such records and change your DNS server software to something more reasonable.
Dima fed up his ears with named's chronic inability to filter out bogus additional records
On Thu, 23 Jan 1997, Dima Volodin wrote:
To all DNS admins:
please check that you don't have 199.0.55.3 and 144.228.8.227 mentioned anywhere in your files. If you do, remove such records and change your DNS server software to something more reasonable.
Add 144.228.1.40 to this list. Dima
And, of possibly more importance to more people, is when people start claiming bogus authority for the reverse of a /8. For example, last week someone was claiming authority for 205.in-addr.arpa and 204.in-addr.arpa instead of for their appropriate /24s. A good quarter of the servers I checked had at least one of these bogus records, rendering reverse lookups for 204 and/or 205 non-functional and messing up anything that relys on reverse DNS working. I think this is a big deal when it happens, especially for the people using the address space it affects. Am I overreacting? If the server admin is unreachable, I think the provider should attempt contact and, if necessary, perhaps even filter the server. Most providers seem to have a "oh, that's bad. We'll get to it in a day or two" attitude. I tend to consider it a serious operational problem that needs to be fixed ASAP. On Thu, 23 Jan 1997, Dean Gaudet wrote:
Is something like a web page listing the "bogusns"s of the day in order? We could include the broken servers that claim to be root servers for non-existant TLDs like .space.
Dean
On Thu, 23 Jan 1997, Dima Volodin wrote:
To all DNS admins:
please check that you don't have 199.0.55.3 and 144.228.8.227 mentioned anywhere in your files. If you do, remove such records and change your DNS server software to something more reasonable.
Dima fed up his ears with named's chronic inability to filter out bogus additional records
On Thu, 23 Jan 1997 13:18:18 -0500 (EST) dvv@sprint.net (Dima Volodin) wrote:
fed up his ears with named's chronic inability to filter out bogus additional records
You could always code it and submit it to the BIND maintainer! Neil -- Neil J. McRae. Alive and Kicking. Domino: In the glow of the night. neil@DOMINO.ORG NetBSD/sparc: 100% SpF (Solaris protection Factor) Free the daemon in your <A HREF="http://www.NetBSD.ORG/">computer!</A>
participants (7)
-
Alex.Bligh -
Dean Gaudet -
dvv＠sprint.net -
Ed Morin -
Marc Slemko -
Neil J. McRae -
Paul A Vixie