Subject: Re: LOC

From: Mark Andrews <[email-masked]>
Date: Thu, 05 Oct 2006 15:17:25 +1000

SIZE         The diameter of a sphere enclosing the described entity, in
             centimeters, expressed as a pair of four-bit unsigned
             integers, each ranging from zero to nine, with the most
             significant four bits representing the base and the second
             number representing the power of ten by which to multiply
             the base.  This allows sizes from 0e0 (<1cm) to 9e9
             (90,000km) to be expressed.  This representation was chosen
             such that the hexadecimal representation can be read by
             eye; 0x15 = 1e5.  Four-bit values greater than 9 are
             undefined, as are values with a base of zero and a non-zero
             exponent.

             Since 20000000m (represented by the value 0x29) is greater
             than the equatorial diameter of the WGS 84 ellipsoid
             (12756274m), it is therefore suitable for use as a
             "worldwide" size.

	Do values 0 to a base other than 0 make any sense?

-- 
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DHCP.  Email [email-masked].
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Joe Abley <[email-masked]>
Date: Thu, 5 Oct 2006 13:07:55 -0400

> 	Do values 0 to a base other than 0 make any sense?

Surely they make as much sense as 0^0 :-)

Joe

---

From: Dean Anderson <[email-masked]>
Date: Thu, 5 Oct 2006 12:48:57 -0400 (EDT)

What about earth orbit?  Doesn't the ISS have internet?

What about Mars rovers? Other future spacecraft?

What's the point of saving a few bits, or making undecoded hex readable 
to the eye?

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Chris Thompson <[email-masked]>
Date: Thu, 5 Oct 2006 18:33:52 +0100 (BST)

Dean Anderson <[email-masked]> writes

> What about Mars rovers? Other future spacecraft?

RFC 1876 defines locations relative to the GPS reference spheroid.
Nothing off the Earth, whether spacecraft or planet [or Pluto] is 
likely to be even approximately stationary in this frame of reference!

Well, maybe one could use dynamic DNS update to track the varying
Earth-Mars vector in real time...

> What's the point of saving a few bits, or making undecoded hex readable 

It's the ugliest part of a specifcation not noted for its aesthetic charm.

> Surely they make as much sense as 0^0 :-)

The choice of the word "base" in RFC 1876 is rather unfortunate,
I think. What it's saying is "[very small sphere radius] should 
be represented as 0e0, not as 0e1, 0e2, ... or 0e9".

But this is all light relief, isn't it? Does anyone really use
LOC records? (I know, off-topic, that's a question for DNSOPS...)

-- 
Chris Thompson
Email: cet1 [at] cam.ac.uk

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 Oct 2006 06:54:34 +1000

> What's the point of saving a few bits, or making undecoded hex readable 

	What's the point about arguing about the range and wire format
	years after it has been defined?

	Rehashing old arguements is not productive.

	All I'm after is clarification of what should be legally/sensibly
	there using that format.

	People are starting to write DNS comformance test suites and they
	are asking vendors (not just ISC has been asked about LOC) about
	the corner cases some of which there are no clear answers for.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 9 Oct 2006 13:01:43 +0200

I forgot to CC namedroppers in my conversation with Mark. Let me  
provide the abstract of that conversation in order to get back to the  
technical core of this discussion.

The problem is that mathematically  0e0==0eY for each Y.  But DNSSEC  
(and possibly other applications) are pretty picky about the wire  
encoding of the value being 0e0 or 0eY. This may be a problem when a  
signer interprets a 0 size field in the master file as 0e0 value  
while a server interprets a 0 in the master file as 0eY.

I think that in the presence of DNSSEC this is the only place where  
0eY hurts the DNS protocol. So, this is something that could be  
clarified in draft-ietf-dnsext-dnssec-bis-updates. Where we clarify  
that a size field being 0 should always be encoded as two 4-bit zeros.

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: Mark Andrews <[email-masked]>
Date: Mon, 09 Oct 2006 21:26:35 +1000

> 0eY hurts the DNS protocol.
>
> So, this is something that could be  

	That's reasonable to me though I would also list it in
	the erratra for RFC 1876.
 
> --Apple-Mail-24--451605944
> content-type: application/pgp-signature; x-mac-type=70674453;
> 	name=PGP.sig
> content-description: This is a digitally signed message part
> content-disposition: inline; filename=PGP.sig
> content-transfer-encoding: 7bit
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
> Comment: This message is locally signed.
> 
> iD8DBQFFKiwctN/ca3YJIocRAvnYAJ9tNkD6YzTI1l4SMWSSr6ohXedroACgoQIz
> TsYXIljmwrd7HGdTE6Fw8ys=
> =Z2h/
> -----END PGP SIGNATURE-----
> 
> --Apple-Mail-24--451605944--

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 9 Oct 2006 14:18:05 +0200

> 	the erratra for RFC 1876.

So, Anywhere were the signer can take a different interpretation of  
the master zone file format than the signer there may be a problem.  
Are there other RRs where this could be a problem?

I remember trying to be relatively liberal when parsing TXT RR data  
in Net::DNS::RR::TXT; Most of the people forget adding quotes ore use  
single instead of as string delimiters but that could pose a similar  
problem.  I think that adding a note do bis-updates about this  
wouldn't hurt.

Any other RRs that may be subtly ambiguous under zone-file <-> wire  
format?

--Olaf

---

From: wayne <[email-masked]>
Date: Mon, 09 Oct 2006 10:26:45 -0500

In <[email-masked]> "Olaf M. Kolkman" <[email-masked]> writes:

> The problem is that mathematically  0e0==0eY for each Y.  [snip]

> [ ... ]                        So, this is something that could be

OK, I guess I'm confused.  Doesn't RFC1876 already say that?  Wasn't
the relevant part of RFC1876 quoted in the first post in this thread?

From RFC1876 section 2 "RDATA Format"

SIZE         [...]
                               Four-bit values greater than 9 are
             undefined, as are values with a base of zero and a non-zero
             exponent.

That seems to me to say that 0eY for Y > 0 is undefined.  A resolver
is free to drop into a game of nethack if it wants to upon reception
of a LOC record with 0e3.

-wayne

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 9 Oct 2006 21:43:20 +0200

>>
>> So, Anywhere were the signer can take a different interpretation  
>> of the master zone file format than the signer there may be a  
>> problem. Are there other RRs where this could be a problem?
>

That should have read:

So, Anywhere were the signer can take a different interpretation of  
the master zone file format than the nameserver serving the data  
there may be a problem. Are there other RRs where this could be a  
problem?

In other words signer and nameserver interpret same zonefile text- 
blob as different wireformat.

--Olaf

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 9 Oct 2006 13:59:48 -0700 (PDT)

On Mon, 9 Oct 2006, Olaf M. Kolkman wrote:

> I remember trying to be relatively liberal when parsing TXT RR data in 
> Net::DNS::RR::TXT; Most of the people forget adding quotes ore use single 
> instead of as string delimiters but that could pose a similar problem.  I 
> think that adding a note do bis-updates about this wouldn't hurt.

That reminds me. I could not properly decide when asked by somebody
recently if TXT field in DNS can or can not have UTF context. Now 
obviously it happens, the question is really would various TXT DNS
record parsers have problems with any 8-bit context there. And another 
issue is that since there is no additional 'type' field indicating
if data would or would not be UTF8 the parsers are going to have an 
issue. This all got me thinking that it maybe better to just define
new UTF8TXT type record which parsers would always know to have UTF8 
text/comment context and leave TXT for ASCII.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Mon, 9 Oct 2006 16:23:05 -0500

At 21:43 +0200 10/9/06, Olaf M. Kolkman wrote:

>In other words signer and nameserver interpret same zonefile text-blob
>as different wireformat.

I don't know that there is an easy answer to that one.

Up to now, the zone file format was only standardized for 
documentation purposes.  Unless rsync'd or otherwise file system 
manipulated, a zone file written by process was read back by the same 
process - or a reincarnation of it usually using the same or similar 
source code.

Personally I have never been fond of declaring the zone file syntax a 
standard, but that's the what folks have wanted.  So now we face 
having two disjoint representations of the same values (the zone file 
format and the wire format versions of each RR set).

One approach would be to instruct the signers, servers, et.al., to 
exclusively read and write in wire format, leaving zonefiles just for 
us humans.  But that ain't gonna happen.

Perhaps when we rehash LOC we just add the good words to tighten it 
up.  It is just at proposed standard now anyway, right?

Or we could begin to encourage all implementations to essentially to 
a AXFR to a disk file when preparing a copy for consumption by 
another process.  (Like from signer to server, or a server storing a 
copy in case the machine reboots.)  And likewise, read a "binary" 
file as that in addition to zone file format.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Secrets of Success #107: Why arrive at 7am for the good parking space?
Come in at 11am while the early birds drive out to lunch.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 Oct 2006 08:47:48 +1000

> of a LOC record with 0e3.

	You are right.  I should have re-re-re-read that.  Mea culpa.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 Oct 2006 09:06:33 +1000

> documentation purposes. 

	I would argue that it was also defined to allow zones to be
	transfered outside to the DNS protocol.

RFC 1034

4.3.5. Zone maintenance and transfers

Part of the job of a zone administrator is to maintain the zones at all
of the name servers which are authoritative for the zone.  When the
inevitable changes are made, they must be distributed to all of the name
servers.  While this distribution can be accomplished using FTP or some
other ad hoc procedure, the preferred method is the zone transfer part
of the DNS protocol.

> Unless rsync'd or otherwise file system 

If it was wanted to do just that then there would not be a well defined
format that defines a zone.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 9 Oct 2006 18:16:44 -0500

It's a matter of interpretation, but the quoted text below states 
that the preferred method is the zone transfer.  The text conveys 
that the zone file format is more or less a safety net, for use in 
situations outside the protocol.

Perhaps the ship has sailed but I'd say that trying to maintain two 
renderings of the same statement (a resource record in wire format 
and zone file format) is too much work.  I can barely see the sails 
of that ship now - whether it be that it is crossing successfully 
over the horizon or is sinking in the drink I cannot say.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 Oct 2006 09:44:19 +1000

> text/comment context and leave TXT for ASCII.

	I don't think we need a UTF8TXT type.

	TXT itself needs to be clarified as escape handling is not
	well defined.  Allowing CRLN within a quoted text string
	was never a good idea as each os has its own eol convention.

	named uses the same escape handling as it does for domain
	names.