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

[Mark Andrews]

> At 7:57 +1100 1/30/08, Mark Andrews wrote:
> 
> >	The world runs without it.  There are lots of zones including
> >	TLD's that cope.
> 
> I was talking on the side with someone wondering why, if this is/was 
> a real problem, why don't all TLDs see this?  That's a good question. 
> My response was that in the case in which I experienced the problem 
> it may have been a combination of factors somewhat unique to the TLD 
> (it being ARPA).  In other cases it might be manifested in the way 
> the registry to DNS interface is constructed.
> 
> >	I think it is time to name the resolver(s) if you really
> >	want to try to ram through this bad engineering decision.
> >	If a resolver don't follow glue it is broken and there are
> >	lots of places where it will fail to resolve names.
> 
> I'm uncomfortable naming names on a public mailing list, I think it 
> is irresponsible to place public reports of problems in the court of 
> public opinion.  I think it leads to mob justice and bully behavior. 
> That is why I refrain from naming the resolvers.
> 
> I take offense to your language regarding "ram through this bad 
> engineering decision."  This thread began with a report that there 
> might be a bug in what Ultra was doing.  I filled in the history to 
> explain that the response was valid and then went on to why it is 
> sent.  I have also been justifying the decisions made back then that 
> lead to where we are.  I mentioned that I "thought" it was Ultra 
> matching Atlas in action, it turns out the Ultra engineers 
> consciously added this response because of a problem on the 
> production network (may be before we acquired them for all I know 
> now).

	It's "trust us".  It has to be this way with nothing to
	back it up.  Short term fixes have a habit of becoming long
	term fixes for no reason other than inertia.  This decision
	is way past time for review.

	Legend had it that nameservers stopped emitting SOA records
	on negative answers to work around a bug in a resolver.
	Rather than fix the bug the whole world lost the ability
	to negatively cache answers.  Would you do that today?

	Putting out glue as answers has negative impacts for
	everybody.  I see the effects pretty regularly on bind-users.
 
> Personally I have had experience with the mistakes of BIND 4 and BIND 
> 8 in this manner.  I had to spend quite a bit of time researching it, 
> the problem is real.  Yes, BIND 9 has corrected that but as an 
> operator I have had to deal with legacy code that was still broken. 
> I'm not calling BIND to fix anything.
> 
> Documenting these responses would be the responsible thing to do.  No 
> one has taken this on.  I don't see the harm in legitimizing them, 
> whatever that means.

	I do, especially when registries do not take active steps
	to correct discrepencies in glue.  If glue doesn't appear
	as a answer then iterative resolvers can take steps to
	ensure that it is not returned to the requester.

> Perhaps once we rid the network of broken 
> resolvers we don't need to see these responses.  But since when has 
> the Internet relied on an attitude that every one has to march to the 
> same beat?  Whatever happened to "be liberal in what you accept?"

	What do you think RFC's are for?  They are to get everyone on
	the same beat otherwise there is anarchy.

> >	I fail to see how you need to be bug for bug compatible
> >	with a resolver.
> 
> What I had in mind was authoritative servers that are built 
> bug-for-bug compatible on purpose.  As far as resolvers, I wouldn't 
> know.  But I do know that one resolver code strain begets another 
> because we have weak specifications.
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 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