<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [dns-operations] Reporting glue as authoritive
data --</title></head><body>
<div>At 8:48 +0000 1/31/08, Lutz Donnerhacke wrote:</div>
<div>>* Edward Lewis wrote:<br>
>> Why don't servers running BIND 9 seem to have this
problem?<br>
><br>
>Because the "hybrid answers" are not needed by the
resolvers out there.</div>
<div>>There might be a problem in the past, but it's gone.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>>I did the same several month ago, while observing that
changing glue does<br>
>not trigger a DNSSEC-signature action. I was puzzled and discussed
this</div>
<div>>"problem" even with the user above. That's why I
heard of his problem now.</div>
<div><br></div>
<div>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).</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.'</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>>After this discussion, I'm sure, that ATLAS and Ultra give
wrong answers and</div>
<div>>should plan to phase this errornous behaviour out.</div>
<div><br></div>
<div>You might have drawn this conclusion, but I haven't. Let's
move on from that though.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>Here's my prescription for removing hybrids.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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.</div>
<div><br></div>
<div>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).</div>
<div><br></div>
<div>It doesn't hurt to have Peter's draft or RFC either to help
explain your complaint.</div>
<div><br></div>
<div>From:
http://www.neustarultraservices.biz/company/contactus.html:</div>
<div><br></div>
<div>Customer Support<br>
Email: ultrasupport@neustar.biz</div>
<div>Phone: (888) 367-4820</div>
<div><br></div>
<div>If that doesn't work, then the court of public opinion is the
place to be.</div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<span
></span>-=-=-=-<br>
Edward
Lewis <span
></span
> <span
></span
> <span
></span
> <span
></span> +1-571-434-5468<br>
NeuStar</div>
<div><br></div>
<div>Think glocally. Act confused.</div>
</body>
</html>