[dns-operations] Reporting glue as authoritive data -- Bug!

[Mark Andrews]

> At 14:34 -0600 1/30/08, Emilio Perea wrote:
> 
> >It would be nice to have more details of the "hammering" that took
> >place.  I don't doubt that there are lots of buggy resolvers out there,
> >but not knowing any details it seems presumptuous to assume that the
> >problem MUST be with ResolverX rather than Ultradns.  If it could be
> >shown that ResolverX has the same problem with (e.g.) BIND 9, your claim
> >that there are resolvers that need hybrid answers (and that they need to
> >be catered to) would be much easier to accept.
> >
> >Right now all you seem to be saying is that without hybrid answers an
> >(unnamed) resolver is a PITA for Ultradns.  I'm sure that's true, but
> >it's still a bug in Ultradns isn't it?  What am I missing?
> 
> The .com and .net (Verisign's ATLAS) servers have the same behavior. 
> It isn't just Ultra that does this, it's not case of Ultra blaming 
> someone else.  Try
> 
> dig: $ dig auth60.ns.uu.net +norec @a.gtld-servers.net
>   and compare with this
> dig: $ dig +norec dns1.fqdn.org @tld1.ultradns.net
> 
> Both put the glue into the answer section.  ATLAS repeats the record 
> in the additional.
> 
> My historical knowledge of this is based on the operations of the 
> in-addr.arpa servers, which saw problems ensue when we removed Ultra 
> servers from our set.  (Not that the Ultra servers were saving the 
> day, but the removal caused the .com and .net servers to cease 
> sending hybrid answers for us.)
> 
> The problem hit ARPA hard.  All of the ARPA servers are in the NET 
> domain.  All of the NET servers are in the COM domain.  I call this a 
> "double side step" in that the iteration process would have to start 
> two sets of lookups at the root, one for NET and one for COM. 
> Ordinarily any zone would have some servers in bailiwick and some 
> servers in just one other TLD.  The double hit on ARPA was the reason 
> the weakness in the (*old* BIND) software got exposed.

	Or you could say that those zones were causing excessive work
	to be done by iterative resolvers and they aborted the queries
	to protect themselves.  How many levels of indirection are
	reasonable before a resolver gives up.

	192.in-addr.arpa's delagation is reasably sane now.  You would
	have to loose all of chia.arin.net, dill.arin.net,
	epazote.arin.net and figwort.arin.net to reach BIND 8's old
	limits.
 
> As far as the hammering, I don't have details on that.  That happened 
> before I was affiliated with Ultra.  As I've said, I do know the 
> cited brand of buggy resolvers, but I don't see why dragging that 
> into the list is needed.
> 
> The reason why it is still in place in the Ultra servers is because 
> we (they) had a bad experience when doing the right thing and haven't 
> been able to verify with the "victims" (okay, those running the buggy 
> resolver might not be true victims) that it is okay to remove the 
> hybrids.
> 
> What I have been saying about documenting the hybrids isn't to 
> legitimize them or even encourage them, but to make the situation 
> known.
> 
> Why don't servers running BIND 9 seem to have this problem?  A guess 
> would be that they don't have any delegations that have the "double 
> side step" as seen in ARPA.  Or the set of buggy resolvers out there 
> don't hit the "newer" TLDs.  Until last week, no one seemed to notice 
> the hybrids for about 2 years (judging from how far back I had to go 
> to find my old mail on it) so no one has thought about cleaning them 
> up.
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                +1-571-434-5468
> NeuStar
> 
> Think glocally.  Act confused.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.oarci.net
> http://lists.oarci.net/mailman/listinfo/dns-operations
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org