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

[Edward Lewis]

At 8:48 +0000 1/31/08, Lutz Donnerhacke wrote:
>* Edward Lewis wrote:
>>  Why don't servers running BIND 9 seem to have this problem?
>
>Because the "hybrid answers" are not needed by the resolvers out there.
>There might be a problem in the past, but it's gone.

Saying it's gone doesn't prove it.  To be fair to you, it's 
impossible to prove that something does not exist.  Because this is 
an unsolvable problem we should move on to something that can be 
solved.

>I did the same several month ago, while observing that changing glue does
>not trigger a DNSSEC-signature action. I was puzzled and discussed this
>"problem" even with the user above. That's why I heard of his problem now.

I'm not sure if what you are alluding to is the desire for something 
called 'fetch glue' which is an old feature of BIND.  Sorry for being 
hazy on this, but a server could be told to fetch the glue it was 
supposed to serve periodically (or just at zone load).

The practice has been obsoleted.  For one, it's an obvious drain on a 
large glue-holding zone. Two, it's a chance for glue poisoning.

Further, I have seen RFP's for DNS services (external to the global 
public Internet) that explicit request that the authoritative servers 
do not do 'fetch glue.'

What that says to me is that they'd rather have the glue issues 
handled via provisioning than glossed over by the DNS.  My 
interpretation is that we would rather expose issues and solve them 
correctly than smooth them over.

>After this discussion, I'm sure, that ATLAS and Ultra give wrong answers and
>should plan to phase this errornous behaviour out.

You might have drawn this conclusion, but I haven't.  Let's move on 
from that though.

Why am I, speaking as a DNS operator, reluctant to remove hybrids? 
(I am writing this so that you might get some hints as to how to get 
me to do so.)  For one, any change to current practices has to have 
benefits that outweigh the risk of the change.  Put it this way, show 
me that hybrids hurt and should be gone, resulting in a benefit. 
They hurt DNSSEC?  So what, the market for DNSSEC is negligible. 
Let's address my risks, the last time I backed out the hybrids, I got 
hammered with traffic.  You might say it won't happen again, but I'm 
the one that has felt the pain before.

Here's my prescription for removing hybrids.

First, work with Peter Koch and his draft on glue clarifications. 
Objectively define hybrids.  State that the problem is in resolvers 
that suffer Alzheimer's, that is, forgetting why they got an answer. 
Get the document published as an RFC.

RFCs mean something in the world, they might not be the law we run 
by, but they shape it.  You may recall back and forth about RFC 1034, 
4,3,2, step 3b and 4 - a clear RFC is what is needed, not one open to 
wide interpretation.

Second, get the attention of the organizations that deal with 
registry operations.  Not to punish or cajole the registries to act, 
but to afford registries protection.  I.e., lower the impact of my 
risk.  Make me willing to make a change that just might victimize 
someone else.  And make it worth my while to spend time on this 
instead of another pending work item.

You see, hybrids are properly formatted DNS messages.  They are 
equivalent to cache answers, except that there is no DNSSEC ancillary 
data there (which you only notice if you are experimenting with 
DNSSEC).  This isn't a protocol issue at all, you can't "outlaw" any 
set of bits and eliminate hybrids.

It is an operations issue.  And a registry operations issue.  You 
desire to tell registries to stop using glue as cache.  You aren't 
going to get this wish in the court of public opinion (such as this 
list).  You aren't going to get this done just via IETF documents.

Okay, maybe I'm giving you the age-old bureaucrat's stone-wall 
answer.  "Do a lot of work, go through channels and we will get 
around to it. And hopefully you'll get too tired fighting you'll 
accept the situation as it is."  There's a shorter answer that might 
also work.

Try reporting the problem to the customer support for Ultra and not 
to a public list.  Sometimes it is easier to convince an organization 
to change when the report is from outside than from someone like me 
that reads a list and then reports it internally.  Sounds crazy, but 
it helps.  For one, you get more a more sympathetic response to a 
discreet complaint than one that might be construed as a desire to 
embarrass someone (which is usually the biggest outcome in a court of 
public opinion).

It doesn't hurt to have Peter's draft or RFC either to help explain 
your complaint.

From: http://www.neustarultraservices.biz/company/contactus.html:

Customer Support
Email: ultrasupport at neustar.biz
Phone: (888) 367-4820

If that doesn't work, then the court of public opinion is the place to be.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20080131/89c57a1a/attachment.html>