Subject: draft-costanzo-dns-gl-02.txt

From: "Jesper G. Hoy" <[email-masked]>
Date: Wed, 31 May 2000 20:15:31 -0400

Dear Sirs,

I am writing in support of the draft "draft-costanzo-dns-gl-02.txt".

We publish a popular Windows DNS server and have corresponded with Mr. =
Costanzo (the draft author) about implementing the new DNS RR type =
suggested by his draft as soon as it reaches RFC status.

In my opinion this new "GL" DNS RR type would enjoy a much wider =
acceptance compared to previous "location" RR types "GPOS" and "LOC".

The suggested "GL" RR type uses actual street addresses instead of =
longitudes, latitudes and altitudes, making it much more useful and =
accessible.

I feel that DNS administrators rarely establish "LOC" records, simply =
because they (as most people) have no idea where they are in terms of =
longitudes, latitudes or altitude.

We are quite anxious to implement this in our software, and would like =
to know if there is anything we can do to help the process of promoting =
this draft to an RFC.

Please let me know if we can supply any additional information.

Sincerely,
Jesper G. Hoy

JH Software
2603 Sugar Maple Ct
Monmouth Jct, NJ 08852
Tel/Fax: 732-821-5738
http://www.jhsoft.com

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: "Donnovan Wint" <[email-masked]>
Date: Thu, 1 Jun 2000 10:20:04 -0400

Great idea, but this could be an administration nightmare.  Think
about "the roving" user for starters.

In my opinion, in order for this to work effectively, there needs
to be a system outside of DNS that has management *authority* for the
*data*.

Regards,

---

From: Edward Lewis <[email-masked]>
Date: Thu, 1 Jun 2000 09:00:11 -0400

I am emphatically neutral on this issue, perhaps even radically moderate.
I don't see the need for the record, nor do I see any reason it is not
persued.

I disagree with the argument that "we don't need GL, we have LOC."  I don't
know of many folks who use LOC as it is.  LOC is not alone, most record
types are not widely used.  OTOH, Having both is possible, they don't
impact each other.

The IETF can't stop someone from implementing a DNS feature in their name
server.  The standard does define "unknown" record type handling.  IMHO, I
think the authors/implementors of the draft should do an implementation
without the "blessing" of the IETF and then demonstrate "running code."
Document the record and submit an ID.  It is possible that the ID could go
Informational and evolve into an RFC without WG review.  (There are still
reviews to go through, just not the WG.)

Hypothetically, if the GL record becomes so widely popular that name
servers implementing the record begin to steal serious "market" share from
BIND, I am sure BIND will include it.  I am not suggesting that the DOJ
needs to break up the ISC too, but I could understand a reluctance for
adding GL to BIND at this time - there's just too much else going on.
Don't take this as an indication of reluctance by ISC - I'm talking
hypothetically here.

I see two issues remaining.  One is whether IANA/ICANN should be allowed to
allocate a type number.  The other is whether the GL record should be
"standards track" or part of the DNS standard.  These are the two issues to
be debated, not the relative merit of the GL vs LOC.

>to know if there is anything we can do to help the process of promoting =

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"It takes years of training to know when to do nothing" - Dogbert

Opinions expressed are property of my evil twin, not my employer.

---

From: Mark Gritter <[email-masked]>
Date: Fri, 2 Jun 2000 09:49:30 -0700

On Thu, Jun 01, 2000 at 09:00:11AM -0400, Edward Lewis wrote:
> server.  The standard does define "unknown" record type handling.

Does it?  I would appreciate a reference.

Currently, deployment of new record types (GL or anything else) is 
pretty much predicated on getting BIND to recognize them and properly do
recursive queries.  Otherwise any client software must use non-recursive
queries, which may be undesirable--- especially when behind a firewall.

BIND 8 returns unknown record types as answers only if accompanied by 
a recognized answer type.  If not, you get SERVFAIL.  BIND 9 is at least
more consistent: you get SERVFAIL if any unimplemented RR types are present.
My bug report to ISC resulted in an answer that they needed more IETF 
guidance as to how to deal with this case.

But until handling of unknown record types is better addressed, it's not 
really feasible to deploy a new RR type without putting it on the standards
track so that it gets implemented in BIND.

-- 
Mark Gritter <[email-masked]>
http://www-cs-students.stanford.edu/~mgritter/

---

From: Edward Lewis <[email-masked]>
Date: Fri, 2 Jun 2000 15:48:54 -0400

>Does it?  I would appreciate a reference.

Well, I've been looking and it appears that I was mistaken.  The reason I
thought there was a standard way to handle unknown types was that this came
up in the discussion of local compression.  One issue was that "if a
nameserver doesn't know the format of the RR, then it can't correctly
uncompress the data."

Looking more, in section 4.1.4 of RFC 1035 this appears:
>
>Pointers can only be used for occurances of a domain name where the
>format is not class specific.  If this were not the case, a name server
>or resolver would be required to know the format of all RRs it handled.
>As yet, there are no such cases, but they may occur in future RDATA
>formats.

Notice the middle sentance.  This isn't a positive explicit affirmation of
unknown RR handling, but...

---

From: "D. J. Bernstein" <[email-masked]>
Date: 2 Jun 2000 21:27:58 -0000

Mark Gritter writes:
> BIND 8 returns unknown record types as answers only if accompanied by a
> recognized answer type.  If not, you get SERVFAIL.  BIND 9 is at least

Yikes! Let me make sure I understand:

                   GL?                         GL?
                   -------->                   -------->
   GL-aware client           BIND 8 or 9 cache           GL-aware server
                   <--------                   <--------
                    SERVFAIL                          GL

You're saying that the cache doesn't pass along the packet from the
server, and doesn't save the GL information for future queries? It
simply drops the information and says SERVFAIL?

What exactly do you mean by ``accompanied by a recognized answer type''?
Normally there's only one type in the answer section. Will a CNAME to a
GL work? Or a * query that returns an A and a GL?

---Dan

---

From: Mark Gritter <[email-masked]>
Date: Fri, 2 Jun 2000 16:06:37 -0700

> Yikes! Let me make sure I understand:

Yes.  As was pointed out in previous discussions here, there's at least one
good reason to not cache unrecognized RRs: they may include compressed
names.  (Verifying signatures is another.)

But BIND 8 doesn't pass along anything it doesn't recognize as an
answer (i.e., no recognized RRs) and BIND 9, as I understand it, synthesizes
all responses rather than "forwarding" the response with the unrecognized RR 
in it.
 
> GL work? Or a * query that returns an A and a GL?

With the version of BIND 8 I tried, an ANY query that returns both an A and 
a GL will be passed back to the resolver.  (But subsequent ANY requests will 
return just the A record, of course.)  I don't think CNAMEs work that way 
(I don't recall trying), but you can get the same behavior by putting 
irrelevant records (like TXT) into GL responses--- not that I would want to 
encourage such a thing!

---

From: Edward Lewis <[email-masked]>
Date: Fri, 2 Jun 2000 22:28:41 -0400

>names.  (Verifying signatures is another.)

I'd turn that statement around.  Compression in the non-RFC 1035 RR's is a
bad thing as the RR's format may not be understood in older servers.

DNSSEC is only complicated by compressed names and uppercase names.
(Perhaps the signature verification should not have required the lower
casing of names in the RDATA.)