Subject: [dnsop] draft serverid-04

From: Miek Gieben <[email-masked]>
Date: Tue, 5 Apr 2005 11:42:09 +0200

Hello,

Just finished reading serverid-04.txt and I consider it a good
document. But one nagging question remains, as it does not specify
a new mechanism, but only lays down the requirements. Are there any
plans to create a followup draft which actually specifies a new
mechanism? 

--
grtz,
  - Miek

http://www.miek.nl                   http://www.nlnetlabs.nl
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Miek Gieben <[email-masked]>
Date: Tue, 5 Apr 2005 20:26:56 +0200

[On 05 Apr, @ 20:14, Paul wrote in "Re: [dnsop] draft serverid-04 ..."]
> > document. But one nagging question remains, as it does not specify a new
> > mechanism, but only lays down the requirements. Are there any plans to
> > create a followup draft which actually specifies a new mechanism?
> 
> i'm planning to submit a draft recommending that "id" be bidirectional
> (so, both clientid and serverid) with the client's id being the solicitation
> of the server's id.  this doesn't require rev'ing the EDNS version number

but will that still require more than one query? As I see it, the
whole idea of this draft and the one from Rob (which implements the
EDNS tweaking you mention), is to retrieve this information with
a single query.

--
grtz,
  - Miek

---

From: Paul Vixie <[email-masked]>
Date: 05 Apr 2005 18:14:34 +0000

i'm planning to submit a draft recommending that "id" be bidirectional
(so, both clientid and serverid) with the client's id being the solicitation
of the server's id.  this doesn't require rev'ing the EDNS version number
or anything hard like that.  i will propose a registry of attributes so
that the client can, if it wants to, offer an opaque universal identifier,
a nat-opaque transport address, current latitude and longitude, preferred
human language, and other things to be defined later.  this is primarily
for mobility support, since i'm not confused into thinking that the internet
is the web or vice versa.  but since we've not succeeded in keeping dns
server operators from producing policy-based rather than fact-based answers,
i think it's time that we fully support non-universal dns.  obviously this
will require that caching be disabled in policy-based responses.  and it's
a loophole that the alternate-roots crowd will just love.  but it's time
to answer the community's needs in this regard.

to that end, i don't think that the current draft goes nearly far enough.
-- 
Paul Vixie
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: [email-masked]
Date: Tue, 5 Apr 2005 20:45:06 +0000

> to that end, i don't think that the current draft goes nearly far enough.

	01apr is a few weeks back thataway... :)
	that said, i'm in favor of the client being 
	able to give up information about itself.

--bill
.

---

From: Rob Austein <[email-masked]>
Date: Tue, 05 Apr 2005 18:16:19 -0400

<hat wg-co-chair=on>

  In my opinion, Paul is proposing that we attempt to solve a
  different problem than dnsop-serverid and austein-nsid attempt to
  solve.  This says nothing about the merits of Paul's proposal-to-be,
  just that, again in my opinion, it is a nontrivial change in goal.

  The goal of dnsop-serverid and austein-nsid is to attempt to answer
  loud cries for help that we have been receiving from the root zone
  server operators (among others) for many years now.

</hat>

<hat wg-co-chair=off just-another-bozo=on>

  Personally, I do not view the tasks of identifying the server and
  identifying the client as at all symmetric in a protocol like DNS,
  so it's not obvious to me that such mechanisms should be linked.

</hat>

<hat wg-co-chair=on>

  Since dnsop-serverid is in WG last call, it would be useful to know
  whether the WG:

  a) Agrees with my characterization of Paul's proposal as a change (or
     expansion, if you prefer) of the goals for this work item;

  b) Agrees with Paul on this change in goals.

  Silence will be interpreted as "yes" on (a) and "no" on (b).

  Finally, please note that nothing above rules out future work along
  the lines Paul suggests.  The issue on the table is just whether we
  need to reopen dnsop-serverid to address Paul's point.

</hat>
.

---

From: Paul Vixie <[email-masked]>
Date: 05 Apr 2005 23:58:58 +0000

> > (so, both clientid and serverid) with the client's id being the
> > solicitation of the server's id.  this doesn't require rev'ing the EDNS
> > version number
> 
> but will that still require more than one query?

no.  it uses the presence of an ID option inside the EDNS OPT RR in the
request to signal the desire to see one in the response.

> As I see it, the whole idea of this draft and the one from Rob (which
> implements the EDNS tweaking you mention), is to retrieve this
> information with a single query.

yes, that's still the goal.  and to rob's observation that the need for
this in clients isn't symmetric to the need for it in servers, i think we
can answer that by making a small change to the serverid and/or nsid drafts
making it symmetrical, saying that no client-side options are defined at
this time, and making the server's response into an attribute/value list.
-- 
Paul Vixie
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: David Conrad <[email-masked]>
Date: Wed, 6 Apr 2005 00:38:43 -0700

Hi,

Apologies in advance for the length of this message.  As a person 
'somewhat' involved in inflicting this topic into dnsop in the first 
place and being listed as a co-author (although Suzanne should get the 
credit for keeping this alive), I have to admit I'm confused.

My intent in writing the original draft was to document existing 
practice and behavior (a txt query in the chaos class for 
{version,hostname}.bind) and suggest an alternative with minimal 
changes that would be less offensive to other vendors (a txt query in 
the chaos class for {version,id}.server).

The reason I suggested the approach I did was that I figured the folks 
who implemented chaos/txt *.bind (which, surprisingly enough, isn't 
just BIND) would find it trivial to change the string queried for. 
Mucking about with anything any more complicated than that (e.g., OPT 
RRs, the status opcode, multiple questions per query, or whatever) 
would imply code changes and thus, require significantly more work (in 
a relative sense).  In fact, as I was coming up with my original draft, 
I asked some other DNS server implementors if they'd be willing to do 
chaos/txt id.server and they had indicated that it wouldn't be out of 
the question.

The reason I thought this functionality would be useful was because the 
root servers were then just beginning (!) to be anycasted and one of 
the concerns expressed about this approach for strengthening the roots 
was that if an anycast root server instance went off into the weeds, it 
would be nice to be able to identify the culprit instance.

In other words, my goal was to suggest something _simple_ to meet an 
actual and immediate _operational_ need.  A novel and heretical 
thought, I know.  I was and am perfectly well aware that my original 
proposal was far from optimal, however I felt it had the best chance of 
actually being implemented in real live operational servers before hell 
froze over.

Unfortunately, after a particularly unpleasant public exchange with 
Randy Bush (for which I belatedly apologize to dnsop participants who 
had to wade through it), I gave up in disgust.  Subsequently, Suzannne 
took on the responsibility of continuing tilting at this particular 
windmill.

I have now actually read the current draft and I must be missing 
something.  I apologize if this has been hashed out while I was off 
being distracted by other things and the answer is obvious to everyone 
else, but...

One of the major objections against the original server.id approach was 
that the chaos/txt query would only be sent after someone noticed the 
server at a particular IP address was being bad, implying this reactive 
query could take a different path and end up identifying the wrong 
server.

However, unless the "good answer" (the characteristics of which are 
described in the draft) exists in each and every query, anyone 
experiencing difficulties that require identification of a particular 
server will need to send additional queries with the necessary flags to 
include the {opt RR, status opcode, additional question, whatever} that 
tells the server to identify itself.  Obviously, if you have to do 
this, the query might take a different path and get you no closer to 
what you need to know than an out-of-band approach.

If I assume the identifying thingie is always on, then you get into the 
problems of dealing with DNS servers/load balancers/firewalls/NAT boxes 
that do not (and likely never will) understand such esoterica as any of 
the possible solutions discussed.  This implies we'll have to do the 
same sort of silliness we do with EDNS0 which also implies the 
identifying thingie simply can't be used.

Of course, one could argue that broken and/or obsolete servers would 
get replaced but experience has shown it exceedingly difficult to get 
people to upgrade their servers, even for root level exploits in those 
servers.

A more reasonable argument can be made that DNS servers/load 
balancers/firewalls/NAT boxes/etc. may treat class chaos queries 
different than class IN queries, however class chaos queries are 
obviously made today and they get responded to, thus there is at least 
some running code that indicates they 'work' (for some definition of 
that variable).  This obviously can't be said of any of the in-band 
proposals.

Lastly, regardless of whether the identifying thingie is always on or 
not, I believe in the vast majority of cases, you'll need some DNS 
savvy person to actually research and discover that a server instance 
is misbehaving.  As such, for an in-band solution to be any different 
than an out-of-band solution, you'll need to log every response on the 
off chance that badness will occur.  This seems unlikely to me.

With regards to the other disadvantages of the current approach (which, 
by extension can be applied to the id.server approach):

- section 3.2, #2

If there is anyone today who is actually using the CHAOS class as it 
was originally intended, I would be fascinated to hear about it.

While I was not the one who chose to use the CHAOS class for this 
query, I would bet that person's life (:-)) that the version.bind query 
or functional equivalent is the _only_ current use of that class.  
Given class CH is specified in RFC 1034/1035 and it is both inadvisable 
and has proven well nigh impossible (at least in the real world) to 
remove anything defined and implemented in the Internet today, I would 
argue that we might as well take advantage of the CHAOS class's 
existence.  This particular use of the CHAOS class is supported by the 
DNS specifications -- the only protocol violation that might occur is 
in those name servers that are used for CHAOS naming.  I suspect this 
set of name servers is rather small.

Of course it can be (and has been) argued that implementing class CH is 
a waste of time.  I don't disagree.  I know of at least one DNS server 
implementation that implements only the ability to answer a TXT query 
for a particular string (no points for guessing what string).  
Alternatively, an implementor may choose to not implement the 
identification mechanism (whatever it might be) and simply accept the 
fact that they will be decreasing the chances that their server will be 
used in anycast/load balancing situations.  That's fine too.  There are 
plenty of DNS servers out there these days.

- section 3.2, #3

As I mentioned above, there are multiple implementations that support 
the general concept, if not the exact implementation of chaos/txt 
version.bind.  Those implementations include BIND, Nominum ANS, 
PowerDNS, MyDNS, and NSD (at least).  There are probably others, but I 
didn't bother to investigate further.  There were some folks who, when 
I asked, indicated it would be a lot easier for them to get management 
to agree if the TLD was changed to something less vendor specific, thus 
I chose "server".  Of the folk I spoke to who didn't dismiss the idea 
out of hand due to the use of class CH, all indicated id.server would 
be an acceptable alternative.  However, this was a (long) while back, 
so things might have changed.

In any event, what am I missing?  Is there some reason we're trying to 
make this more complicated that it has to be?  Or is this yet another 
example of the OSIfication of the IETF?

Thanks,
-drc

.

---

From: Miek Gieben <[email-masked]>
Date: Wed, 6 Apr 2005 15:05:27 +0200

[On 06 Apr, @ 00:16, Rob wrote in "Re: [dnsop] draft serverid-04 ..."]
>   need to reopen dnsop-serverid to address Paul's point.

I think Paul's idea has some merit. Also I think that serverid should
go forward to at least document the current practise.

The whole id.server stuff is already the defacto standard, there is
nothing the IETF can do about that,

--
grtz,
  - Miek

---

From: Peter Koch <[email-masked]>
Date: Wed, 06 Apr 2005 15:49:49 +0200

>      expansion, if you prefer) of the goals for this work item;

Learning more about the resolvers out there would be *very* helpful, but
that isn't achieved by them providing an ID, they'd have to tell their
version (or feature list or ...). That, however could lead to all those
"intelligent" features of webservers, giving blinking domain names to
resolver X and those with smell and taste to resolver Y. That's only very
remotely related to "hostname.bind". Also, I do not yet understand why
the resolver should "pay" for the server's ID by presenting its own first,
especially since the ID need not be meaningful and may even change over
time. We aimed at debugging, not feature negotiation.

>   b) Agrees with Paul on this change in goals.

I'd like to have an agreed upon debugging aid *soon*.

>   Silence will be interpreted as "yes" on (a) and "no" on (b).

You may take these as my words of silence.

-Peter
.

---

From: Bruce Campbell <[email-masked]>
Date: Wed, 6 Apr 2005 17:17:35 +0200 (CEST)

On Wed, 6 Apr 2005, Peter Koch wrote:

> Also, I do not yet understand why
> time.

The client does need to 'pay' to get that information, although I suspect
my reasoning is somewhat different than other's.

If you have a 'small' option to set on the inbound packet that results in
the server's outbound packet being significantly larger due to debugging
information, the miscreants will eventually stumble on it as being yet
another nifty method by which DNS can be used as an amplification attack
against a 3rd party.

In the long run, this would result in administrators disabling the
debug/identifier 'feature' to avoid being used for such an attack, which
is not what we want.

It would be better for any debugging solution to have a penalty so it does
not get used in such a fashion, and thus administrators leave it enabled.
If the penalty is the client handing out _a_ string (preferably with a
minimum size), that is acceptable.

( Yes yes, other aspects of DNS can still be used as amplifiers, but
  theres no point us making it too easy. )

> I'd like to have an agreed upon debugging aid *soon*.

urm... I'll agree with Paul in (ab)using EDNS0 for client/server ID,
because its slightly more elegant than magic-string in the query section,
but I don't agree with a complete change in goals for server-id.

I'd like to see server-id continue to be used as the case for having a
diagnostic interface enabled, to document old practice, and _to contain a
pointer to the preferred practice_.  Since the last point is missing,
don't publish server-id-04 at the present time.

( I don't think publishing-as-RFC a document that says 'something with
  these properties would be cool, but we don't have that yet' is a good
  idea. )

-- 
  Bruce Campbell.
.

---

From: Peter Koch <[email-masked]>
Date: Wed, 06 Apr 2005 20:03:21 +0200

>   theres no point us making it too easy. )

the amplification is not larger than with a standard DNS query, even without
DNSSEC.

> because its slightly more elegant than magic-string in the query section,

Just to clarify: i do not believe a TLD in any class gives sooner results
than an EDNS0 option, so we agree here.

>   these properties would be cool, but we don't have that yet' is a good

You want the word 'requirements' in the title?

-Peter
.

---

From: David Conrad <[email-masked]>
Date: Wed, 6 Apr 2005 11:18:44 -0700

Hi Peter,

> than an EDNS0 option, so we agree here.

Why do you believe this?

Rgds,
-drc

.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 7 Apr 2005 12:26:24 +0200

[Yes, I know we should not FTT.]

On Tue, Apr 05, 2005 at 06:14:34PM +0000,
 Paul Vixie <[email-masked]> wrote 
 a message of 23 lines which said:

> obviously this will require that caching be disabled in policy-based
> responses.

This is not mandatory. HTTP has similar features and they don't imply
cache disabling. See RFC 2616, 13.6 "Caching Negotiated Responses".

.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 7 Apr 2005 16:22:30 +0200

On Thu, Apr 07, 2005 at 01:54:41PM +0000,
 Paul Vixie <[email-masked]> wrote 
 a message of 16 lines which said:

> as long as the requestor knows to only reuse if the same request
> criteria was present, caching would be fine.  a caching requestor
> would then have to be willing to cache several different responses,
> each having the same q-tuple but different request criteria.

Yes, this is what the HTTP proxy/cache Squid does. See for instance
http://www.squid-cache.org/bugs/show_bug.cgi?id=649.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Paul Vixie <[email-masked]>
Date: Thu, 07 Apr 2005 13:54:41 +0000

> [Yes, I know we should not FTT.]

believe it or not i'm not just trolling with this stuff.

> cache disabling. See RFC 2616, 13.6 "Caching Negotiated Responses".

upon reflection, you're right.  as long as the requestor knows to only
reuse if the same request criteria was present, caching would be fine.
a caching requestor would then have to be willing to cache several
different responses, each having the same q-tuple but different request
criteria.  this is dangerous since it will involve talking to ed lewis
in his most agitated state.  mostly listening, actually.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: David Conrad <[email-masked]>
Date: Sun, 17 Apr 2005 12:12:26 -0700

On Apr 6, 2005, at 12:38 AM, David Conrad wrote:
> [a very long rantish message]

It appears that despite (or more likely, as a result of) trying to 
explain in detail my concerns about the server-id draft, I left folks 
with some confusion about how I feel about it.

I will try to be more succinct:

I do not think the draft should move forward without significant 
modification.

Rgds,
-drc

.