[dnsop] draft DNSOP minutes for IETF 63

[David Meyer <[e-mail]>]

	Folks, please check for accuracy and completeness. There
	are a few unknowns as well (please search for ???).

	Thanks again to Ted for serving as scribe.

	Dave & Rob

---


#
#	David Meyer
#	[e-mail]
#	Mon Aug 15 09:50:32 2005
#
#	$Header: /home/dmm/SDOs/IETF/meetings/IETF63/dnsop/dnsop.minutes,v 1.1 2005/08/15 16:51:24 dmm Exp $
#


DNSOP Working Group
Meeting Minutes
Monday, 01 Aug 2005

Chairs: Rob Austein <[e-mail]> and David Meyer <[e-mail]>
Scribe: Ted Lemon <[e-mail]>

Agenda
======
Domain Name System Operations (dnsop)

MONDAY, August 1, 1030-1230 (Morning Session II)
------------------------------------------------

CHAIR(s): David Meyer <[e-mail]>
          Rob Austein <[e-mail]>

AGENDA

 o Administriva						   5 minutes

   - Mailing list: [e-mail]
     subscribe dnsop

   - Scribe(s)?
      Jabber
      Other 

   - Blue Sheets

 o Agenda Bashing					   5 minutes
   Meyer                                           

 o Review and status of work items			 

   Newly Approved
   --------------
   draft-ietf-dnsop-ipv6-dns-configuration (Info)	   5 minutes
     Jeong, et al.

   AD Followup
   -------------------------------
   draft-ietf-dnsop-ipv6-dns-issues (Info)		   5 minutes
     Savola

   AD is watching    
   --------------
   draft-ietf-dnsop-dnssec-operational-practices (Info)    5 minutes
     Kolkman, et. al
   
   Active Drafts
   -------------
   draft-ietf-dnsop-serverid-04.txt                       10 minutes
     Wolfe
   draft-ietf-dnsop-bad-dns-res-03.txt			   5 minutes
     Larson/Barber
   draft-ietf-dnsop-inaddr-required-06.txt		   5 minutes
     Senie
   draft-ietf-dnsop-key-rollover-requirements-02.txt	   5 minutes
     Guette, et al.
   draft-ietf-dnsop-respsize-02.txt			   5 minutes
     Vixie/Kato

   Expired Drafts (gauge interest)
   -------------------------------
   draft-kato-dnsop-local-zones-00.txt			   5 minutes
     Vixie/Kato
   draft-huston-6to4-reverse-dns			   5 minutes
     Huston

   Potential WG Items
   ------------------
   draft-durand-dnsop-dont-publish	                   5 minutes
     Durand
   draft-morishita-dnsop-anycast-node-requirements-01.txt 10 minutes
     Morishita						
   draft-krishnaswamy-dnsop-dnssec-split-view-00.txt	   0 minutes
     Krishnaswamy
   draft-kurtis-tld-ops-00.txt                            10 minutes
     Lindqvist
   draft-yan-ipv6-ra-dns-00.txt				   5 minutes
     Yan
   draft-fujiwara-dnsop-bad-dns-auth-02.txt		   5 minutes
     Fujiwara, et al
   draft-fujiwara-dnsop-dns-transport-issue-00.txt	   5 minutes
     Fujiwara
   draft-massar-dnsop-service-00.txt                      10 minutes
     Massar  
   draft-minda-dnsop-using-in-bailiwick-nameservers-01.txt 5 minutes 
     Minda


Overview of Notable Conclusions
===============================

- draft-ietf-dnsop-key-rollover-requirements-02.txt

	Of people in room who had read it, almost all wanted to
	kill this one. Take to list, in form "we will kill this
	unless somebody strongly and coherently objects".

- draft-ietf-dnsop-respsize-02.txt

	WG sees it as ready for  WGLC; However, Kato-san asked
	for time to provide another revision.

- draft-kato-dnsop-local-zones-00.txt

	Not enough of those present had read it to have an
	opinion. Sam Weiler says default should be drop this
	unless somebody wants to stand for it.

	Mark Andrews wants empty zones for bogus names but also
	wants zone transfers of root zone to get rid of .local
	and .localhost issue. for one more revision first.  

- draft-huston-6to4-reverse-dns

	Apnic is running stuff based on this, so the WG needs to
	ask the authors to bring it back.


Meeting Narrative
=================

DNS configuration document, DNS director had something he wanted
to say.   David Kessens. 

David Kessens (AD).   The DNSconf doc has been approved by IESG.
We did stick in IESG ???, was out for review for IESG to make
sure every agreed.   After this review round is done, should be
announced by secretary, sent to RFC editor.   Doc is approved,
should move shortly to RFC editor. 

Rob: So as far as WG is concerned, doc is done.


Harry Carp: IDN issue, in context of ICANN, there are several
members of that council president here, we would like to depart
from Paris knowing more about the current IETF concerns about
IDN.   Is that likely to come up this morning? 

Rob: No, that's an application issue. 

Patrik F�ltstr�m: working with IDN issue here in IETF. People
that want to know more about IDN and IETF can contact me after 
Wednesday lunch. 

David Meyer: I wanted to point out, Olafur asked me for some time
at the end for update on some performance numbers he's been
gathering. 

Just to bring everybody up to date, ipv6 dns conf done.
dns-issues is in AD followup. AD is watching:
dnssec-operational-practices. serverid is active. 

Pekka Savola: Just say about this doc in ad followup that we have
had discussion with Thomas Narten who was providing feedback,
doc has been revised, was published in July, still trying to get
him to follow up on the revision to see whether his concerns are
met.   In meantime, suggest that people in WG who have been
looking at doc should look again, make sure there are no changes
wg would be uncomfortable with. 

Rob Austein: issue with truncation, no feedback from DNSEXT?
Recommend anybody who cares think about it really hard and answer
Pekka.   Pekka, set timeout, after a while go with what you've
got. 

Pekka Savola: Jinmei provided some good feedback, but I would
like some more. 

Suzanne Wolffe: Only need two minutes.   Server ID last call got
substantive comments that go to clarifying rationale, so there
will be another rev.   Want to see chair's comment on last call. 

Rob Austein: David Conrad had comments, woke up during last call,
asked to roll back to what we had 2-3 years ago.   My read on
this, with respect, that is the rough part of rough consensus.
If anybody disagrees, please say so now. 

Sam Weiler: could you go back a slide?   Operational practices -
what do we need to be doing? 

Rob Austein: passed wg last call, ready to send to IESG.   We
think we're done with that. 

David Kessens: ad is watching has little meaning.

Rob Austein: draft tracker knows doc exists, that's all.

Olaf Kolkman: after last call, well after, we got a couple of
people commenting on draft, comments were substantial.   Real
content.  We addressed these issues by setting up open issues on
ML, tried to word smith text, propose solution, set timeouts on
them, didn't get push back on everything, so I think those issues
can be closed.   Another thing that we got feedback on, table
that we use in doc to suggest key sizes.   Hillary Orman, one of
the authors of BCP for determining strength of public keys, 3766,
gave some push back there.    And we haven't addressed that yet.
We will this week, and post another issue to the list, setting
timeout.   Once we incorporated that work, we propose that we
would like to have another review on the doc. 

Rob Austein: another WGLC?

Olaf Kolkman: I think that's in place, but please honor that last
call, because it's really unhandy to get a lot of feedback two
months after last call.   At some point you want to end the work,
as an author.   So please feed back. 

Matt Larsen: I submitted a new version of this draft after
embarrassingly long time, I think I got everybody's comment who
made comments in both of the last calls last year, so please read
new draft, let me know what you think. 

David Meyer: thank you.   I did talk to Daniel a little about
this one (inaddr-required).   There ahd been controversy over
this one, we discussed changing name, he has revision of this,
thinking of changing name, that triggered a bunch of things, so
we'll have that out on the list, there is another version that
hasn't hit repository yet. 

Rob Austein: The key rollover requirement.   This is a doc that
the wg accepted a couple of years ago, TBH I don't think we've
seen a lot of support for doc other than from authors.   We've
had several requests to remove it as wg item.   Never get very
many people who have opinion, a few ask to remove, a few ask to
keep.   Of the relatively small sample, mostly saying get rid of
it.   So we will drop unless there is serious objection. 

David Meyer: Continuing on.   Alain isn't here?   How many have
read this one?   (don't publish)   I think there were substantial
comments on this one. 

Alain Durand: we missed deadline, so I promise that will be done soon.   I'm still waiting for some text that some people promised to send me, so would like to see in my mailbox.

David Meyer: was just updated moments before draft cutoff.
respsize.   Has anyone seen revision?   I didn't see a lot of
traffic about this one.   I guess since we don't have authors
here, will take to list. 

Bill Manning: I think one of the reasons for bring back to wg is
that this is in ICANN formal procedures, and it's difficult to
reference a doc that doesn't exist anymore.   It's
extraordinarily helpful to have a persistent doc for those kinds
of reasons. 

Rob Austein: last time wg considered WGLC, author said it's not
ready because I have a hidden surprise in doc.   Since then
people have found it, auth has dropped objection.   My sense is
we should go for WGLC. 

Ted Lemon: There are some textual problems with it, some points
are missing.   No substantive issues, just editing. 

Akira Kato: the one of the modification of the doc is written
the parse script in appendix, I got the comment from Pekka last
minute, and maybe something regarding to tcp misunderstood, so we
may need to modify before the last call is being taken.   If you
have any other comments on doc, please pass to the list. 

David Meyer: Do you have another revision?

Akira Kato: maybe we are going to work on. 

David Meyer: so you want to revise.

Akira Kato: yes.

David Meyer: Expired drafts.   Interest?   Local-zones draft?
Rob were thinking, keep these or kill them.   Other one is keff's
reverse dns draft.   What we wanted to do was try to gauge
interest in working group.  Informally, temperature. 

Rob Austein: slightly different states.   Kato-san didn't think
local-zones draft was ready.   Jeff's draft, he wanted to take it
as wg item, couldn't get anybody to read it. 

David Meyer: how many people read local zones doc?   Of those,
how many think it's valuable?   We need to take it onto the
list. 

George Michaelson: we hope to be able to put something up on
agenda, we have it in deployment, there is a test service, has
had zero promotion, included text in SOA of zone, we now have
about fifty to seventy live 6to4 reverse registration, service
basically works, concerns about scaling and resiliency, there is
a test service. 

Rob Austein: to be clear, implements this draft? 

George Michaelson: yes, with knobs and frobs.

Rob Austein: So this draft describes code that is in use out there now, operational.

David Meyer: how many people read?   How many people think to bring it back?   Okay.   dnsop-service.

Sam Weiler: I want to go back to local-zones doc.   It looks
interesting, but if nobody is advocate for it, I think we should
drop it.   I'd be delighted to hear from Kato-san that we still
think it's a good idea.   But by default, should drop. 

Mark Andrews: I think local zones should be split into two.   One
to do reversal namespace, in terms of doing automatic
construction of empty zones, reverse namespaces, ipv6
locally-signed local addresses draft.   This one's a good place
to split that part out, do for 1918 addresses, anything that fits
in that same class of problem.   .local, .localhost, largely
solved by choosing different rationale for how stub resolves,
local caching services keep root zone.   Keeping copy of root
zone locally would address the issue in terms of .local, don't
get traffic to the root, just zone transfers from the roots.
Slightly different issues: separating them apart, there's a few
of them, name service should by default return name error on
those things, would be a good idea. 

Jeroen: doing lot of ipv6 stuff, need to be able to detect what
is closest bubble broker.   Simply specify where your web server
is, where mail server is, so basically you would have.   So this
is what you normally stick into DNS for SRV.   Why not make a
.service domain?   If you have any cast address which has
.service, then you get local version.   You could request
_website service, would get local services.   Etc.   So user
doesn't have to configure anything local.   When traveling, use
example network.   This would make configuration issue almost
nul.   You need anycast DNS address somewhere so that you can
have local announcement. 

Tunnel service discovery.   You could always have local tunnel service.

Alain Durand: first, how does this relate draft-yamamoto naptr
service discovery?  

Jeroen: it specifies that the application which is going to look
at DNS, If you don't have dsp protocol, 6to4, etc, or if
different service, then you connect to a service which is not
intended to be used in this way. 

Keith Moore: completely invalid assumption.

Rob Austein: not wearing chair hat.   I'm not sure whether I read
this in draft, maybe clarity issue, may be a problem.  Looks like
you're proposing that this be a pseudo-top-level domain.   You
probably don't want to go there.   Secondly, there's a bit of
history behind anycast DNS, several years of excitement we had
with DNS conf stuff.   Thirdly, we could have long interesting
discussion about appropriate service names, maybe Mr. Moore would
have something to say.   You're just moving the problem. 

Keith Moore: there are a lot of topics about this that are right.
We already have a lot of really bad service discovery mechanisms.
No better than DHCP or Apple's stuff or a lot of those things.
Any time you try to put DNS below IP.   The notion is that the
local net knows what's good for you.   Not true in may cases, not
true in general.   We don't need another one.   Not an
improvement over the bad stuff we have already, not worth
pursuing.   I would agree about TLD issues and anycast issues,
service name issues, huge numbers of ratholes. 

Alain Durand: would like to remind, this is an issue that was
looked at in tc bof at Minneapolis, as followup to that on
Thursday, allow-w bof, should be brought up at another time. 

Michael Sanf: maybe missing something, if problem is that you
have service that is discovered by different protocols, can
already use NAPTRs and SRV as defined in RFC3958. 

David Meyer: Of the people who have read this, is this a
candidate for a WG item?   Okay, moving right along, split view,
author is not here.   Make sure everybody knows we have it as
potential item.   Anybody not signed the blue sheet. 

Rob Austein: WG needs to read.   Split DNS is something we're
stuck with.  That being the case, we have to know how to do it
with DNSSEC.   I don't know that this doc is right, but we need
to look at this space. 

David Meyer: kurtis-tld-ops

Kurtis Lindqvist: not going to talk about doc too much in detail.
History: got stuck with.   Had a question about ICANN about
requirements to run TLD.   IAB realized there are none.   So it
thought that maybe this would be good thing to have.   I got
elected, this got dumped on me.   So I started writing something
up.   The IAB had discussed this, not an IAB issue, really DNSOP,
IAB wanted to make sure it got written up, so I started,
circulated this to usual suspects, got quite a lot of feedback.
Stole large chunks of text from ?? document.   When putting
comments into single doc, ready for pub, I realized that the
feedback was going in two different directions. 

Intention is not to have some sort of document you must adhere
to.  More like a check list.   Description of trade offs.  Hard to
come up with list of things TLD operator would have to adhere to.
Very hard to come up with single set of minimal requirements. 

So the operational guidelines doc would be some sort of best
practice doc.   Slave server, master server setup.   TLD
operations doc is unclear to me, what we would like to do.   How
do we do register, EPP, whatever?   Probably doesn't belong in
DNSOP.   BCP.   I see two issues.   Having operational guidelines
just for TLDs seems out of scope.   Would a doc like this make
any sense? 

Rob Austein: chair hat off.   I think proposed split makes sense.
Considerations, tradeoffs, sounds like an excellent idea.
Hesitant to promise there will be no normative language.   Might
be appropriate.   Jump off bridge when we get to it. 

Secondly, TLD ops, I agree we don't know where that should be
written, okay to start here, move if you want to.   Probably
normative reference to first one. 

Kurtis Lindqvist: don't have strong feeling who should do it. 

Lars Liman: doing op recommendations, we've been trying to do
that for more than ten years now.   Requirements for DNS
operations vary wildly between who we are, where you are, and
what your environment is, so focusing on tradeoffs and
consequences is fine, general recommendations we've been there. 

Kurtis Lindqvist: no requirements.   I don't think there is
normative language going into doc like this. 

Lars Liman: I do agree would dbe very glad to see doc that
enumerates stuff, says this is the bad consequence you're going
to get if you do this, also this is the good consequence you'll
get if you do this. 

Ted Lemon: I want to concentrate on second one.   Want to remind
that ISOC has  a program of doing courses for starting TLD
registries, not long ago doc was published, I think it would be
nice to catch up with these folks. 

Bill Manning: having trod this road in past, author of 2010,
2780, flaws in these docs seem to be re-emerging here.   2780 is
targeted toward TLD service.   You really need to be very clear
and concise - TLD or registry?   Separable tasks.   Ops for
machine, or guidance on how to maintain service?   Will echo
Liman: wide range of things that you can have for an
authoritative server. 

Kurtis Lindqvist: if you look at doc, I tried to address this.
Root of doc goes through physical security, etc.   One of
discussions in usual suspect group is does it make sense?   I'm
not sure I have a strong view of that.   Service is more
important than actual machine, I think. 

Antti: I think our registrars will be effected by changes in
limans spaces if you do pre-validation of host on how they work
the DNS. 

Kurtis Lindqvist: I'm not even sure PPP is part of that doc.
The second doc I'm proposing, I'm looking for input on what
should do there.   Maybe look at ISOC doc.   More framework than
technical. 

Yasiki Orange JPRS: As bill manning said, there are so many
varieties in each TLD service operation.   Technical and political
style.   Number of domains in each TLD so very different.   SO I
think that it has another difficult issue than root server
operation.   RFC2780.   But I personally think this is one of the
good approach, need to go to BCP.   But an we have to discuss and
brush up this document for the TLD communities.   Including
worldwide TLD.   But don't forget that there are so many
varieties. 

Kurtis Lindqvist: the fact that this varies, wide scope that you
and Liman are bringing up is more of an issue if you put
normative language in there.   That was the reason why I didn't
want normative language.   It's not that if you can't collect
entire range of issues in one doc, you shouldn't write doc. 

Yasiki: I will make presentation.

George Michaelson: I'm with APNIC, we act as secondary to large
number of CCTLDs in our region and internationally.   There's an
aspect of this that documenting this raises the bar, but
formalizing some of the behaviors could raise the bar to the
point where we can't be sure if we can offer this service.
ICANN is hammering on them.   If you're saying we can be more
relaxed about this, that's putting us in a funny place, because
it's implying that it's okay, it's good to document this, but a
side effect of this is that things will get tighter. 

Kurtis Lindqvist: as far as I know there was never any pressure
from ICANN to develop this document. 

George Michaelson: I with draw that comment.

Elakoff ???: I am afraid of handing loaded weapon to ICANN without
knowing at what size ??? I should design the bullet for.   This
WG should narrowly focus on DNS issues and nothing else.
Splitting and dumping one doc to another group, I would argue
against working on registry operations in DNSOP. 

Robertin Martin: I would like to second what peter says.
Second, ways of running TLD reflects what comes from, some other
domains would benefit.   Title should be how to run a zone setup.
Also for other people, google.com is probably more important than
my TLD. 

David Meyer: Next, bad-dns-auth.

Rob Austein: in the interest of time, would like to open door on
what has changed - people want to get to lunch. 

I'm Fijuwarea: BIND 8 caching server problem, I think is not
DNSOP issue.   I contacted to ISC.   If possible, ?? and I will
write new ID about authoritative DNS server?. 

David Meyer: what would you like WG to do with your document?
Adopt? 

Fijuwara-san: I couldn't update this ID, but will continue next time.

David Meyer: ipv6-ra-dns

DING Zhemin.   Updating DNS configuration.  Propose new method to
perform DNS update using stateless addrconf.   New document to
transfer domain name option.   New RA/RS option.   Type is domain
name option, length means whether host or router does DNS
updates. By default router.  

When we send RA messages it is required if we want to send domain
name option, bundle it with prefix option.   Simple procedure.
DNS update.   First step is optional - send messenger to router.
Router sends RA option back with DNO.   IPv6 host will
auto-configure the address and its complete the domain name, then
send it back using RAs messenger.   The host can directly update
to DNS server or can use router to perform the DNS update.
Questions? 

Olaf Kolhman: security?   I haven't read draft, TBH, but when I
saw little diagram there, was thinking security, key exchange.
If router does update, key exchange is simple, but if it's an IP
host that enters a domain, how does it get ?? 

DING: we prefer to use router.   Added host option for probably
some network administrator would like to use. 

Alain Durand: I'm not sure even router updating DNS is good
enough, may have key for some part of address, but how will he
trust the host to have right host ID?   If you have DHCP server,
easier because server allocates address, but not the case with
router. 

Also, you are assuming that all the host on subnet share the same
domain.   In my experience that's not the case.   Also that there
is only one domain on subnet, in my experience this is not the
case. 

DING: probably we didn't make assumptions more clear.
Enterprise network, campers network, so in this network the
relation between host and router is trusted, so of course
security is a concern, in this draft we are addressing security
in another draft, it's a very big issue. 

Rob Austein: chair hat off, there may be portions people want to
drop.   Core part is worth discussing, maybe not in this WG.
One of the hard parts of IPv6, stateless, we have absolutely no
explanation for how to do reverse tree update.   In DHCP, DHCP
server does.   If we deal with security issues.   Potentially
useful part of this is to provide reverse translation.   For
forward, host does its own update.   That said, this now reduces
to a previously unsolved problem - total lack of any security
model in stateless autoconf.   Helps in that now keys are only in
possession of router.   Probably an improvement.   Whether you can
trust data is a separate issue.   My recommendation would be to
focus this strictly on the reverse tree update, leave the rest
out.   FQDNs, please.   Not a local suffix that you just add. 

Tatuya-san: i read doc, have technical questions, but before
going into that, have bigger level question.   I think some of
the people pointed this out, but in my understanding the basic
consensus of router advertisement is that we don't want to put
higher-layer stuff in it.   When we discussed how to discover
DNS requesting server addresses, there was a proposal to include
info in RA, even for fundamental level information there was a
lot of disagreement, opposition to that.   At the same time there
are another people who supported that approach, but even for such
fundamental functionality, there were a lot of push backs to that
type of approach, so I'm afraid this one will face even stronger
push backs to the use of router advertisements for such
application level information.   If you think it's okay, please
go ahead, I cannot stop that. 

DING; appreciate comments.

David Hankins: I didn't see any mention of how you expect to
overcome race conditions.   As far as I know, there's no teardown
event in router advertisements.   So nobody knows to remove the
entries.   This rapidly becomes a cesspool, a swamp.   What
happens if two different clients think they have the same name?
Were you going to address that in a different draft? 

DING: definitely name collision is a big problem.

David Meyer: where would you source an identity for the client?

DING: how to solve the problem?   We are working on it.

Alain Durand: I would like to comment on Rob's comment.   This is
useful ih teh reverse tree.   If we do not make this secure,
there is no point in doing it. 

DING: that's why we propose using router.

Alain Durand: if you don't secure host to router, useless.

Rob Austein: Alain and I agree on this.   The one value I see
from this is getting rid of temptation to put keys in reverse
tree onto laptops. 

Ilitsch: security isn't always necessary.

Ted Lemon: use DNSSEC.

Keith Moore: host knows what its name is, if network doesn't
agree, shouldn't be making assertions.   Instead configuration
error should be reported.   To change hostname is jus broken.
We don't need to further that.   If this thing has a purpose,
it's to set the reverse path, it is reasonable to set binding
between address and resource records.   Probably the update
needs to happen via a different path. 

David Meyer: moving right along, dnsop-using-in-bailiwick-nameservers

Minda-san, JPRS: Many people know that reverse DNS lookup is
slow.   Lame delegation?   No, there are two reasons.   One,
hostname of namesever is used the standard name.   This causes
gluelessness.   Actually case is glue-less on caching name server. 

When glue of nameserver is not obtained, caching name server is
retrieved from root namserver again.  Takes time to repeat. 

BIND 8 glueless issue, on caching name server stops answering
client and starts iterative query to find the address of
nameserver.   After timeout, client retries, takes 5-10 seconds
or more.   Other implementation does not have this issue. 

Solution: in-bailiwick nameserver in .ARPA.
ns01.16.11.202.in-addr.arpa. 

Mark Andrews: I really don't think we should make decisions based
on the fact that BIND 8 is broken.   As an author, I know it's
broken.   And nobody really should be running BIND 8 anymore.
Replace it. 

George Micahelson, APNIC.  We discuss operational aspects of
managing the reverse tree in regional registry meetings, if you
want to talk to us about operational changes, you really do need
to come to that process.   Your slides imply that there is a
delegation tree, not that straightforward.   In IPv4 and IPv6
reverse, delegation of glue is probably not where you think it
is.   So if you are going to document this issue, you need to
think about what is the assumption of the boundary of the glue.
Your effective saving in round trips may not be accurate in that
circumstance.   I really think you need to bring that to a
different forum. 

Rob Austein: chair hat on.   One clarification to BIND * issue.
It is not that the victim is running BIND 8.   BIND 8 is beating
up on other servers. 

Peter Kord: My usual rant, bailiwick should be less religious.
My concern with this is that it probably doesn't scale.
Assuming a clear cache, counting number of ops needed to go down
to those names.   So this is about easy access to additional
date, IP addresses of nameservers.   Usually the recursive
resolvers operate with caching, more often than not TLD servers
names and addresses will be available.  I challenge your
calculations - unless you do weird things, cache is almost never
empty.   For scaling, working for TLD registry which has 6m
delegated domains, if only a fraction of our customers would
follow advice and switch from relying on ISPs ore registrars to
be named in the delegation, would switch to in-zone, in-domain
naming scheme, there would be much more trouble due to
inconsistencies.   Out of our 6m domains, we delegate to no more
than 50k Name servers.   You would end up with millions of
nameservers. 

Olaf Kohlman: in a few slides up you mention DNSSEC performance.
DNSSEC has its own validation chain that doesn't' depend on where
glue is.   At the moment you get the delegation down the tree,
...   you don't need to resolve glue to follow that chain.   I'm
challenging that statement about reduced cost - I don't think
it's relevant. 

Mark: ???   The reason NS records exist in the first place is to
make changes to addresses easy in terms of one place where it has
to be done.   Going to in-bailiwick breaks what we designed the
DNS for initially.  We could just as easily put an A record in
there.   The NS record is there so that you can break the simple
one place to change when you are changing the name server's
address. 

Sam Weiler: I'm not sure I completely agree with Olaf about
DNSSEC validation.   Resolver should only check main path, but
it's reasonable, but not advisable to check glue.  

Morishita-san: BGP anycast node for authoritative name server
requirements. 

Rob Austein: chair hat on.   Where might be an appropriate place
to do this.   Biggest chunk is anycast stuff, might be more
appropriate over in the GROW working group.   Portions of this are
covered by Kurtis' work.   Non-IETF venues, probably ought to get
reviewed there.  

David Meyer: two more items. Lixia Zhang has a brief talk she
wants to give us on DoS mitigation technique, then Olaf wants a
minute on DNSSEC performance. 

Lixia Zhang: We planned to rev draft, didn't get to it.   DNS'
hierarchical structure provides an easy target for DDos.   We
propose another solution.   We got idea from Paul Mocapetris'
paper 20 years, ago, administrator defines TTL values for reach
RR as prt of the zone definition. 

Rob Austein: a number of resolvers have a limit to the TTL they
will accept. 

Lixia Zhang: change ceiling to one month or longer.   There is
also concern, what if you have to fetch halfway through TTL?
Would increase query rate?   Measurement shows that on root
servers, 90% are junks, so this could potentially, if refreshed
often, increase legitimate queries from 2% to 4%.   What if cache
got poisoned, bad info stays longer?   Bad implementation, need
to do something to fix it.   Other issues? 

??: thank you for writing this up, but there's a problem.   If I
postulate a DNS-signed zone world, TTLs of a week long will
affect your time to compromise recovery.   One week si going to
be extraordinarily long for signed zones.   Unacceptable
tradeoff.   Using TTLs as a tool, that's unacceptable. 

Olaf Kohlman: I was going to say the same.   Signature lifetime
cuts off TTL.   Keeping a short DNSSEC signature lifetime
protects your children in case of key compromise.   Tradeoffs
need to be made.   That's going to set time limit, not TTL. 

Sam Weiler: I see a couple of things here.   We're wanting to see
queries repeated fairly often so we don't have easy rollover.
Resolvers should be able to continue using old data.   One is to
communicate this in protocol by updating TTLs.   Has advantage of
letting old resolvers be more resistant to DOS attacks.   Another
thing you could do is have resolvers not actually hard expire the
data - if they can't reach the servers, they just keep using the
old data. 

Lixia Zhang: another engineering tradeoff.

(lots of boos and yells from the peanut gallery)

Mossan Suicy: I would like to know how much availability you can
gain. 

Lixia Zhang: student didn't get data ready.   Gigantic DNS
lookup, Most servers are stable. 

David Meyer: last one.

Robert Martin: Over the last period of time, within center, one
of the things people have been complaining a little bit about is
that time it takes IANA to do a change to the root.   Some people
are complaining about months, others are complaining about a
week.  Upping to week, might be bad. 

Lars Liman: two comments.   That's an administrative thing you
have to approve IANA.   And you cannot set TTL in record set.
You might have to change a number of servers in record set on
short notice, outside your control.   Business partner goes
bankrupt.   Natural disaster.   Too long TTL is not a good
thing. 

Peter Koch again: ttl on delegations in root zone may have less
influence than one may think since they are likely overwritten by
NS records coming out of authoritative zone. 

Rob Austein: we cut off comment already long ago.

Lixia Zhang: continue:

Olaf Kohlman: was not on agenda, have measurements of DNSSEC on K
root servers.   15 minute presentation, no work item, and I am
lined up to do same presentation in a little work group for
DNSSEC deployment later this week.   Russ: when? 

August 3rd at 10:30.   Room 315.   So not going to give
presentation, come Wednesday.