Subject: Re: [dnsop] INADDR draft

From: Ólafur Guðmundsson<[email-masked]>
Date: Mon, 07 Mar 2005 09:33:43 -0500

At 12:02 20/02/2005, Daniel Senie wrote:
>I've submitted the latest version. It may not make it through the queue 
>for some time, so it's also viewable on a web server of mine at:
>
>http://www.senie.com/dan/draft-ietf-dnsop-inaddr-required.txt
>
>I'm also posting emails in response to specific comments.

Looks good but there is one omission that I would like to be addressed.
Reverse name can contain RR types other than PTR, for example the new
IPSECKEY RR is explicitly designed to go in the reverse tree to allow
opportunistic IPSEC.
There have been discussions on adding some other RR types there
but no concrete usage has been proposed.

Second issue I would like to raise is the fact that PTR is not a
singleton RR but what does it mean to have multiple PTR records ?
(open question to wg)

         Olafur

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

---

From: Edward Lewis <[email-masked]>
Date: Mon, 7 Mar 2005 08:58:54 -0600

>but no concrete usage has been proposed.

Besides PTR, we also have SOA, NS, ;). 
Seriously, here is a presentation that was given 
at the APNIC meeting about 10 days ago:

http://www.apnic.net/meetings/19/docs/sigs/dns/dns-pres-fujiwara-improving-revdns.pdf

This talks about (re-)introducing A records to the reverse map.

>singleton RR but what does it mean to have multiple PTR records ?

As far as the protocol, it means that the address 
has multiple domain names corresponding to it.

As far as applications, they can't easily deal 
with this.  E.g., traceroute will just print one 
of the PTRs.  (There are many apps that look a 
PTR records, traceroute is the only one I've 
really taken time to think about in this context.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Achieving total enlightenment has taught me that ignorance is bliss.

.

---

From: "Niall O'Reilly" <[email-masked]>
Date: Tue, 08 Mar 2005 08:14:58 +0000

On 7 Mar 2005, at 14:58, Edward Lewis wrote:

> As far as the protocol, it means that the address has multiple domain 
> names corresponding to it.
>
> As far as applications, they can't easily deal with this.  E.g., 
> traceroute will just print one of the PTRs.  (There are many apps that 
> look a PTR records, traceroute is the only one I've really taken time 
> to think about in this context.)

Or, worse, hostname may print a new-line separated list of names.

Best regards,

Niall O'Reilly
UCD Computing Services

PGP key ID: AE995ED9 (see www.pgp.net)
Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

.

---

From: [email-masked]
Date: Tue, 08 Mar 2005 18:28:09 +0900 (JST)

> From: Edward Lewis <[email-masked]>

This requires RFC1912 Section 2.3 "Glue A Records" update.

--
Fujiwara, Kazunori	JPRS

.

---

From: Bruce Campbell <[email-masked]>
Date: Tue, 8 Mar 2005 11:20:31 +0100 (CET)

> This requires RFC1912 Section 2.3 "Glue A Records" update.

Common interpretation (based on the examples) is that 'thalt shalt not
have out-of-bailiwick A records in in-addr.arpa zones', leaving the
possibility of having in-bailiwick A records within the zones open.

 From a Registry POV, allowing in-bailiwick glue adds the requirement of
keeping track of the IP addresses used; whilst it is clearly the
responsibility of the child to keep the parent informed about changes,
most people simple do not think about these things until breakage occurs,
with the finger of blame being pointed at the parent for not supporting
the do-what-I-want-not-what-I-say interface correctly.

--==--
Bruce.

.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 8 Mar 2005 10:54:45 -0600

>the do-what-I-want-not-what-I-say interface correctly.

It's true that the RIR's don't have to worry about glue maintenance, 
don't fret - the registrants already do. ;)  The glue is somewhere...

I don't mean to push for the RIR's to maintain glue, just to point 
out that if they do, it isn't "new pain" just "moved pain." ;)

The downside of the RIR's not maintaining glue is an arguable 
(arguable) performance hit of having an iterating name server chase 
down so many name server addresses (independent of old BIND 
problems).  Also, because of old BIND, .net servers (where most of 
the /8 in-addr name servers are) have to give out "extra glue" 
because old BIND got "lost" on the way.  ("Old" BIND.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Terry Manderson <[email-masked]>
Date: Wed, 9 Mar 2005 10:15:29 +1000

I watch this thread with great interest, initially I was
quite adamant that glue should _never_ be seen in the
in-addr.arpa. However...

> don't fret - the registrants already do. ;)  The glue is somewhere...

Whilst the concept of glue records in the in-addr.arpa tree
goes against the pragmatic interpretation of the current RFC,
I don't see that it would be a huge stretch of resources for
this RIR to approach the issue of glue administration provided
that the proposal to do so was presented and accepted at the
APNIC dns-sig outlining the issues of migration, acceptance,
zone file growth, signed zone growth (and most other
stumbling blocks).

> I don't mean to push for the RIR's to maintain glue, just to point out 
> that if they do, it isn't "new pain" just "moved pain." ;)
>
> down so many name server addresses (independent of old BIND problems). 
>  Also, because of old BIND, .net servers (where most of the /8 in-addr 
> name servers are) have to give out "extra glue" because old BIND got 
> "lost" on the way.  ("Old" BIND.)

While I agree that the old bind aspect is an issue, for me the
larger benefits are about reduction in root traversal as
outlined in Fujiwara-san's presentation. Having the resolver go
back to the root 3 or more times to find the non-cached A
records for the NS RRs certainly appears laboured.

Additionally I can also see that from a top wise approach having
glue in the in-addr.arpa tree means that there is a potential
for arpa to be self consistent removing the reliance on the
.net hierarchy for the initial /8 delegations and then the
same follow-on effects in ccTLD/gTLD space for subsequent
delegations to resource holders.

Also, should ip6.arpa delations take hold, having glue in-situ
will probably reduce any adverse scaling effects on performace.

As for the world of lame, and the current APNIC
policy of un-delegating the lame - APNIC might
need to take a fresh look at the way we do things..
(Though I don't think the work there is ground breaking)

If the current RFC is a blocking factor here, I would
be quite happy to work on the draft to see a change.

Terry
--
Terry Manderson			APNIC Secretariat
	[email-masked]			http://www.apnic.net
	tel:  +61 7 3858 3100		fax:  +61 7 3858 3199

.

---

From: Peter Koch <[email-masked]>
Date: Wed, 09 Mar 2005 02:36:24 +0100

> don't fret - the registrants already do. ;)  The glue is somewhere...

to repeat my favorite song: if it isn't there, it's not glue.

> out that if they do, it isn't "new pain" just "moved pain." ;)

Agreed, maintenance pain vs. operational pain (load).
 
> because old BIND got "lost" on the way.  ("Old" BIND.)

Maybe, but then we're touching another contentious issue, which is general
naming recommendations for name servers. That can not to be opened
in this draft.

-Peter
.

---

From: Peter Koch <[email-masked]>
Date: Wed, 09 Mar 2005 02:55:52 +0100

> This talks about (re-)introducing A records to the reverse map.

yes, but while I see the benefits, I'm missing the cost analysis. This
would include large scale application to nameservers serving 10-100k zones
and how resolvers (``recursive servers'') maintain state, i.e. by name,
by IP address or a combination thereof.

> has multiple domain names corresponding to it.

It also means that there's a lot of truncation to appear, which may even lead
to ``accidental DoS'' on the respective IN-ADDR.ARPA servers (see
http://www.ripe.net/ripe/wg/dns/r46-minutes.html).

-Peter
.

---

From: [email-masked]
Date: Wed, 09 Mar 2005 15:44:52 +0900 (JST)

> From: Bruce Campbell <[email-masked]>

In my opinion, as long as it is possible, it is good to reduce
glueless delegations. Current reverse DNS tree has three or four
delegation point, IANA to RIRs, (RIRs to NIRs,) NIRs to LIRs, LIRs to
LIR's customers. Using in-bailiwick A record may cause an error for
most people, but IANA, RIRs, NIRs (, LIRs) can use in-bailiwick A
records correctly. Using in-bailiwick A record in one delegation saves
at least three DNS queries for out-bailiwick A resolving (root, .NET,
RIRs server). Step by step implementation is possible and effective.

And more, there are many people who want to register in-bailiwick A
record in reverse DNS tree.

In DNSSEC, In my opinion, end host should verify and be full
resolving. Then DNS cache effeciency may become low, glueless
delegation resolving cost will become higher.

---

From: Daniel Senie <[email-masked]>
Date: Wed, 09 Mar 2005 02:09:55 -0500

The present discussion regarding glue and its placement is certainly 
interesting, however I am inclined to suggest that any issues related to 
this be published in a separate document from the (now poorly file-named) 
draft-ietf-inaddr-required-xx document. The point of the document I've been 
working on is to encourage the presence of inaddr at all.

I would be in favor of another document that goes into the detail of how 
glue should be constructed, issues and tradeoffs, and so forth.

Comments?

.

---

From: Peter Koch <[email-masked]>
Date: Wed, 09 Mar 2005 15:38:44 +0100

> working on is to encourage the presence of inaddr at all.

fully agreed and apologies offered.

> glue should be constructed, issues and tradeoffs, and so forth.

Yes, covering both terminology and strategies/policies.

-Peter
.

---

From: Florian Weimer <[email-masked]>
Date: Sun, 13 Mar 2005 10:26:11 +0100

* Daniel Senie:

> I've submitted the latest version. It may not make it through the queue for 
> some time, so it's also viewable on a web server of mine at:
>

If your concern is DNS server load, you have your logic backwards.
Most of the examples of IN-ADDR queries you mention are the result of
rather questional activities.  We would be better off if *fewer*
IN-ADDR queries would be performed in the first place.  Just answering
them faster isn't that helpful, IMHO.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html