Minutes for DNSOP at IETF-95
minutes-95-dnsop-3

DNSOP Minutes Session One
Date: Wednesday 6 April 2016
Time: 16:20-17:20 ART (19:20-20:20 UTC)

# Paul Hoffman(PH) - resolver-priming draft moving along
no comments

# Olafur Gudmundsson(OG), roadblock-avoidance
no comments

OG --refuse any

PH -- Are you suggesting both solutions go into document and we should 
do both?

OG--yes

# OG -- maintain ds

Shane Kerr (SK) --my only concern with making this standards track is
that I feel like the approach for adding the new DS, there are many options 
there, not very specific and clear

OG --send text

SK  --document does good job of talking about various ways, don’t think 
there is a good answer for a single straightforward way of doing it.

# Stephane Bortzmeyer (SB) --nxdomain cut

Ted Lemon (TL) --please limit to the clarificaiton and not the normative
language

Dave Lawrence (DL) --asking the server to try to keep things consistent
is unnecessary. eventual consistency is good enough.

PH --the problem is that it does exist in the cache, that is what the
cache believes, saying it doesn’t exist unless you do something more
doesn’t make sense, just say may.   We all know what must means.
Should means MUST except in these cases.   You could turn it into may
or is a good idea.

Dan York -- maric fabruza. dig … returns nxdomain. if resolvers abide
by this the whole akamai dns will be off.   Dave then wrote, in a
signed zone, it would work with akamai, our problem is limited to
unsigned zones.

SB --if you have a name server that is broken on ent, in both cases we
have a problem. when we have broken servers we have problems.

Shumon Huque (Verisign) --one thing mentioned during that long train of
messages that is not currently in the draft is the option of
performing NXDOMAIN only on a cache miss.   On a cache miss you have
to perform an upward search anyway.   So probably that option should
be discussed explicitly in the draft.   Section 2 says should should
should do this, only in a later section, 5, it says however if you
have a good reason to ignore this advice because your cache
implementation is not a tree, but I think there is a step inbetween
that is a reasonable option that could be discussed.

SB -isn’t it the same, the case where there is a cached response.

Shumon  --I’m pointing out that it isn’t currently in the document

SB --it is in my head but not in the document

Tim Wicinski (TW) --should go into 02 document.

TW --authors will do a 02 with these comments and a few others, then
take it to the mailing list and see what happens, then go to wglc.

Shumon --implementation sections, they talk about implementations, they
say remove before publication.   I think it would be useful to continue to 
have some information about the implementations

SB --you never modify an rfc, can last a long time, always outdated.

# Duane Wessels (DW) --edns key tag

Warren Kumari (WK) -- one of the authors on a different earlier
document which had it encoded in the qname and one of the issues that
we discovered is if there is a forward which is unaware of this,
client might send it through the forwarder, send it to whoever … this
and that forwarder would appear to have the key tag.   So we came up
with the idea of a uuid, became even more complex, we became concerned
and ran away.

Mark Andrews (MA)--doesn’t need to be complicated.  we want you to know
the set of clients out there, which algorithms are actually in the trust
anchors, so it doesn’t matter if it all comes through the same ip
address.

DW--I disagree, I think the IP address is useful.

PH --we want to know. this is not just data we want to be sending
around the  DNS, there are people who will possibly make decisions
based on this, so  finding that information, having it show up in
places where WE can evaluate  it is important, so I wonder if it is a
large recursor that we recognize,  e.g . a busy TLD or root zone, I
can recognize what a big recursor is, asking  lots of sensible
questioins, small recursor because it asks me every two  weeks for
something sensible, so I want an edns0 option.

Ed Lewis (EL) --I also prefer edns0. why hex?   everywhere else I see
this key tag it’s in decimal.

MA --hex is compact, and no separator.

EL --as an operator this is not convincing. please don’t confuse us.

DW --one thing I worry about, as you probably know, any time you look at
data that comes in the root servers, it’s amazing, I would like to be able 
to differentiate a legitimate signal versus an unintentional signal.   
Otherwise something that happens to match this might be mistaken this for a 
legitimate datum.

EL --I also wonder how I would trust, but don’t just give it a
different way.

Evan Hunt --I still favor qname, agree hex is overly clever, recommended
decimal with punctuation. separate labels has problem with qname 
minimization. General comment, not sure current draft has a clear
statement of what the goal is, but I think we should do what is minimal and 
fastest and meets the goal that we specifically have.   wname does meet that 
goal without upgrading all the middleresolvers. if you use qname it’s
just going to get passed along.

Lars Liman --hex or decimal is a presentation thing, the thing that gets
encoded on the wire should make technical sense. please standardize what’s 
sensible for the wire.

MA --could do qname, then migrate.

OG--pick one.

hum on edns0 option
hum on qname
hum on gtxo

WK --if you have edns0, it’s the recursor that sends the query to the
trust point.   If you have qname it’s the machines behind the thing that 
sends the query.   so it depends on what you want to measure, might even 
want to do both.

DW --I think there are some differences but overall you get the same
data.  You get the trust anchor key tags from both recursive and stubs/end 
machines.

EH -presumably if you are a validating stub passing queries through
validating resolver, queries would be sent from both, although potential 
that a qname would have been cached by the validating resolver. if passing 
queries tfrom validating stub through non-validating resolver, ???

WK --more concrete examples, 4.2.2.2, large recursove resolver, if not
upgraded to support this, and I run a stub resolver that uses this, 4.2.2.2 
will appear to have the new key tag.   that will make it appear that 4.2.2.2 
supports this and has the latest key. that was the concern.

PH --I do not want to slow this down, but I would like to see lots of
discussion on the list, and then can you ask the question of a, b, a+b, 0?

TW --so holding off on the hums until we hash it out on the list

OG --can we ask about not doing it?   Should we kill this effort bc nobody 
has any clue what’s going on and value of experiment may be very low.
lots of hums for continue, none for kill.

OG --tim, can I ask you or Duane to ask explicitly on the mailing list
the questions

TW --yes, we’ll put together the questions and send that off, start that
discussion that way.

PH --a note for the room, if you care about nsec5, there’s going to be a
pres in saag.

# SK --dns over http

PH --I would like to see both adopted, don’t see a reason …, would
like to see the people review it. I was the one who brought up post
versus get, because I was thinking of my model which was not the
binary one.   Fine for binary one to be post.   Get with a body is
known to invoke a lot of tears.

I would strongly like you to do the well known, but slightly change,
someone else might want to do dns over http with get, so if you wanted
to get rid of your second bullet, because you don’t want someone in
javascript to be putting together a dns packet, I would say somebody
else such as me might do it a different wya, and only look at that
group, and to me that is a strong argument for doing the survey
document as well.

John Levine --this is a disgusting crock, but it solves a real
problem. having written production dns servers in perl, don’t share
paul’s concern about writing in javascript. put this on the std track,
people will will write one or two js things, that’s okay.

Christuan Huitema (CH) --I don’t really want, my problem with security
section, there is an issue there what happens if someone uses it in an
enterprise network. that particular construct will go across firewall
just fine, will let you browse your porn site from your work desk,
despite your IT managers’ attempts to block resolution.

SK -willing to add text or copy/paste what you send as recs for sec
considerations for enterprises.  I agree can be concern as with work
of dprive.

Christian--synchronize with dprive

dan--what is wrong with wire messages, cost is dwarfed by transport
cost, much more value to consumers to get easy-to-read dns contents.

SK --don’t remember, my guess is pv did it on an airplane flight, and
did it bc it was easy.

SB --I remember discussing it with you, your answer then, the war system
you can pass any dns request. if you define mapping, always the risk that 
something, unknown qtypes, will be missing fromt eh mapping.

Dan York --at the hackathin this weekend sarah dickinson did an analysis
of google’s offering, it’s in hackathon slides.

SK --that’s actually a good example of the strength of this approach--there 
is no way to do a validating resolver with current google api,

Lars Liman --do we have a problem statement?

SK --yes

Lars Liman --is this dnsop work? looks like a protocol mechanism.
maybe dnsop has turned into dnsext. if so that’s fine, but if not
might be better to put somewhere else.

TW --until we hear otherwise from ad, it’s fine here.

Robert Edmonds --application-octet-stream, any reason not to register the
wire message format in mime media type registry?

SK --no reason, happy to do that.

Robert Edmonds --then you can use http content-type negotiation

SK --that kind of thing scares me, not sure what the behavior is of web 
    servers if they encounter unknown content-type

PH --it’ll be fine

SB --application type dns exists.

DW --I agree with microsoft, the security statement is not just a
protocol issue but also an intranet issue. not sure why we want to put 
everything on the internet on port 80

SK --because you block everything else.

DW --I don’t think that should be our decision what they block. if
people want to shoot themselves in the foot they should be allowed to.

----------


WG:        DNS Operations (dnsop) Meeting:   IETF 95, Buenos Aires
Location:  Buen Ayre C Date:      Friday 8 April 2016 Time:
10:00-12:00 ART (13:00-15:00 UTC) Chairs:    Tim Wicinski
<tjw.ietf@gmail.com>            Suzanne Woolf <suzworldwide@gmail.com>

*Session Two

<https://www.ietf.org/proceedings/95/slides/slides-95-dnsop-0.pdf>

- Returning New Business

     draft-wkumari-dnsop-cheese-shop   10 min draft-fujiwara-dnsop-
     nsec-aggressiveuse10 min

(Slides?)

Chairs’ question for the room:  Cheese-shop is a simpler proposal for
the root zone. Fujiwara is more ambitious. Should we adopt both
drafts?

Shane Kerr: Consensus on list was not to proceed with cheese-shop.

Warren Kumari: Cheese-shop is for the special case of the root zone.
It’s a simplified case because the root zone changes very slowly, and
it’s okay if a name doesn’t work for 8-12 hours.

Wes Hardaker: Ólafur, how does your faking NSEC records (you are
returning every rrtype) interact with these drafts?

Ólafur Guðmundsson: The lying can be adjusted depending on the traffic
patterns. I think we should focus on Fujiwara, and not on cheese-shop.

Evan Hunt: Why can’t the Fujiwara draft be modified to say it may be
applied to only one zone if you want?

Kazunori Fujiwara: Both cases are important.

Ray Bellis: So, what is our conclusion? Adopt only Fujiwara? Both
drafts?

Tim Wicinski: I wanted us to discuss both. I think the conclusion is
we only move forward with Fujiwara.

Ray Bellis: I agree, we should focus completely on Fujiwara, and not
get distracted by cheese-shop.



- (More) Possibly New Working Group Business

  draft-wallstrom-dnsop-dns-delegation-requirements, Levigneron 15 min

<https://www.ietf.org/proceedings/95/slides/slides-95-dnsop-8.pdf>

(Vincent Levigneron presenting)

Ralf Weber: I support adopting this document. We should focus on the
delegation aspect, not zone transfers and DNS Updates.

Paul Hoffman: I would love to see this adopted by the working group,
but only if we remove almost all the “MUST”s and “SHOULD”s. There’s a
real risk we could put a “MUST” or “SHOULD” in this document that’s
not the same as the base document. This document should reference the
base RFCs, and say, “Here’s our view.” It should be Informational, not
BCP, because BCP is Standards Track. Don’t want to look like we’re re-
doing any of the RFC 2119 language.

Vincent Levigneron: It will remain as an Informational document.

Dan York: I also support adopting this document. Paul, why remove most
of the “MUST”s and “SHOULD”s?

Paul Hoffman: Because there’s a risk of inconsistency between
different RFCs. This document should have no requirements, and just
reference the appropriate base RFCs.

Dan York: I like having the definitive rules in one place, instead of
having to hunt in different RFCs for them. It makes it much easier for
implementers.

Paul Hoffman: Then we’ll have to be very careful that we get it right
here, and when we update RFCs. Sometimes the original RFCs don’t even
use MUST/SHOULD language. We’d have to be careful, and this working
group has not been good at that.

Dan York: I think this is good work, that we should continue.

David Conrad: I also strongly support this adoption of this document.
I also like having the definitive rules in one place. That’s better
than forcing people to go back and look at potentially conflicting
documents. A summary document is extremely useful. If there’s a
conflict, then that is a source of education and learning, and we can
file errata if necessary.

John Levine: I think this is useful, but should not be normative. It
should reference previous RFCs. DNS is now enormously complicated. No
matter how many eyes review it, the chance of this document being
accurate and correct is zero. I’d rather have it be our best guess,
with pointers back to the source RFCs, for people to read themselves.

Stuart Cheshire: If we think this task is so hard that the DNS experts
in this room working together have no chance of getting it right, how
can we expect an individual reader to get it right?

(Laughter from attendees in room.)

Paul Hoffman: If this document is going to specify MUST/SHOULD
language then it absolutely needs to be BCP, not Informational, *and*
it must formally update that list of earlier RFCs. That’s been done in
the past. If we’re going to do it we should go the whole way.

Marcus Sanz: +1 to what Paul Hoffman just said. I support this
document being a BCP.

Andrew Sullivan: We tried to do this before, in the DNSEXT WG. It was
a massive failure. Everyone looked at the work and said, “No way.” If
we’re too ambitious, the WG will never complete the document. There’s
a lot of unbelievably stupid beliefs out there, and we want to fix
that. We should get a document out as soon as possible to correct that
misunderstanding and misinformation. There’s lots of bad advice on the
web. Do the fast and easy thing first.

David Conrad: This is an operational document. We’re not trying to
reconcile the DNS specifications into a single omnibus document. There
are specific items that are experienced when one is trying to get DNS
operational. Where we run into things that reflect into earlier base
documents I think it’s appropriate to try to ensure that we get the
answer right and if necessary if that conflicts with former advice
that’s not a bad thing.

Dan York (for Jabber room): A couple of people have agreed with Andrew
Sullivan.

Suzanne Woolf: I hear strong support to continue work on this
document; significant debate about document status.

Peter Koch: What is the noncontroversial set of tests?

Stephane Bortzmeyer: The empty set.

Vincent Levigneron: Many of the test are controversial. Of course the
noncontroversial set is not large. A small document is better than
nothing.

Dan York: We should adopt doc now, decide status later.

Suzanne Woolf: I prefer to know how much work we’re taking on.

Shane Kerr: I was going to ask the same thing.

Suzanne asked for sense of the room for whether to adopt this as a
working group document: ** Adopt this document: Significant hum in
support ** Do not adopt: Silence



  draft-ietf-dnssec-algorithm-update, Wouters 15 min

<https://www.ietf.org/proceedings/95/slides/slides-95-dnsop-2.pdf>

Paul Hoffman: We should not talk about specific algorithms today.

S/MIME used this “SHOULD+” and “MUST-” notation, and it worked very
well. IPSECME has also worked well. I like this as a way of helping
guide developers.

Christian Huitema: Something is wrong with this aesthetically. I’d
hate seeing “SHOULD?” and “MUST+” in RFCs. What about plain English
phrases like “MUST for now”? This is supposed to be English, not a
programming language.

Paul Wouters: The people reading this should be programmers already.

Mike Richardson: I am for doing this work, and this split for
signers/validators is sane and good.  I see that you would pick
validation SHOULD+ in advance of signer SHOULD+, and I think this
makes sense.

Dan York: Is there “MUST+”

Paul Wouters: No.

Dan York: Is the “SHOULD+” and “MUST-” notation documented anywhere?

Paul Wouters: In this document.

Francis Dupont: I do not support “SHOULD-” for RSASHA512.

Paul Wouters: The idea is that algorithms that are dead or not used or
silly should be demoted. Likewise for algorithms that have different
algorithms for NSEC3 and not-NSEC3.

Christian Huitema: What’s the difference between “SHOULD-” and “MAY”?

Paul Wouters: “SHOULD-” means currently “SHOULD”, but we’re thinking
of changing to “MAY” or “MUST NOT”.

Paul Hoffman: If you don’t like the “-” and “+” you can ignore those
modifiers.

Christian Huitema: I don’t like this “-” and “+” and I don’t want to
see it in the next update of RFC 2119.

Ed Lewis: The DNSSEC definition includes local policy. What are you
targeting here?

Paul Wouters: This is targeting implementations, not local policy.

Ed Lewis: Then you need to distinguish between general-purpose
implementations and turnkey. I don’t have to write my code for my use
to meet your spec.

Paul Wouters: If you ignore all the MUSTs you will likely not
interoperate will with other people.

Andrew Sullivan: The DNS community had this fight once before, in
DNSEXT. This strategy is not popular around here. I don’t know why.
What we did is captured in RFC 6944. It is considerably less useful
than this advice. I encourage people to reconsider it. There’s an
archive from 2013 that will allow you to peruse how this conversation
went the last time we had it.

Mike Richardson: If your only interoperable algorithm is marked
SHOULD-, then you had better add a new algorithm, because later on
others may remove support for it, and you won’t interoperate.

Paul Wouters: Yes. Every table needs at least one “MUST”.

Dan York: I support this work. I like the “SHOULD+” and “MUST-”
notation. Will this notation spread to other documents?

Paul Wouters: I talked to Mark Andrews and he said we should never
change any software defaults because that would break fifteen-year-old
scripts. We can’t ever remove any signing algorithm, because then
those old scripts might break. We have to support all the old
algorithms for eternity.

Dan York: Once things are implemented in the DNS, they never die. It’s
impossible to phase things out. However, there’s still value in
providing guidance to newer implementations.

Paul Wouters: We don’t want the case where someone has a signed zone
that effectively becomes an unsigned zone because no one supports
their algorithm any more.

Tim Wicinski: There is support for this work, so we’ll continue it.



- This May (Not) Be Working Group Business

    draft-sullivan-dns-class-useless, Sullivan15 min

<https://www.ietf.org/proceedings/95/slides/slides-95-dnsop-3.pdf>

DNS Classes are an attractive nuisance. People sometimes believe they
are more useful than they really are. Support for DNS Classes is often
implemented badly. Propose that IANA close the DNS DNS Class registry.
New rrtypes will be for all classes.

John Klensin: Chaos was a "different network stack", Hesiod was
something else, more like a hierarchical namespace.  If either "didn’t
work", it would come as a surprise to a lot of users at the time.
"Outlived their usefulness and are creating confusion" would make me a
lot happier than "useless".

Andrew Sullivan: Happy to make that change.

Christian Huitema: This is a great idea. One thing DNS needs is more
entropy bits. We could use the class field for more entropy bits. Just
sayin’. [Presumably joking -- minute taker]

(Laughter from attendees in room.)

Ólafur Guðmundsson: Christian has the uniform of the Bad Idea Fairy.
Andrew, you are brave, but I don’t agree with this. We should continue
to allow the use of classes, with the understanding that such software
may not interoperate with anything else.

Andrew Sullivan: The first version of this document just gave advice.
The feedback was that if things are so bad, we should just close the
registry.

John Levine: I agree we should close the registry. The problem is the
spec is broken. It says a Chaos “A” record and a Hesiod “A” record and
an Internet “A” record are different. Except for “NS” records they’re
all the same. There is no problem that DNS Classes solve, and many
that they introduce.

Mark Andrews: We need to make DNS Classes usable in the future. We can
make operational guidelines that different classes need to be
delegated in parallel. We need to specify that for all new rrtypes, by
default they apply to class “IN” only. DNSSEC records are class-less.
Delegation is class-less. We should not close the registry. We could
have solved the IDNA problem using a class “IDNA”.

Andrew Sullivan: There was a proposal to do IDNA using DNS Classes. It
turns out not to work very well. Part of the reason is that there’s a
lot of software that can’t do it. It might be nice to be able to use
DNS Classes in the future, but there is no path to that future that I
can see.

Mark Andrews: There is no path *you* can see. *I* can see a path. You
want to close this because *you* can’t see the possibilities. Others
can see the possibilities. I believe doing IDNA using DNS Classes
would have worked.

Suzanne Woolf: Are you volunteering to write this draft?

Mark Andrews: We don’t need to do anything right now. Just go away. We
don’t need to touch DNS Classes. We just need to say rrtypes apply to
class “IN” only.

Ed Lewis: I actually agree with *some* of what Mark Andrews said. When
we did DNSSEC we overlooked message compression and DNS Classes. We
fixed the confusion about message compression. We never fixed the
confusion about DNS Classes. No one cares about this. I think it would
be good to close the registry.

Wes Hardaker: I agree with Mark Andrews. DNS Classes are not the
problem. The problem is badly written software. That doesn’t mean it
couldn’t be useful in the future. This is an education problem. So, we
need better documentation -- a BCP. We should have a document
describing the pitfalls of using classes other than “IN”.

Andrew Sullivan: There are two problems. 1: STD13 says the trees (by
convention) are parallel. In reality it would be a terrible idea to
have the trees not be parallel. Different people would control the
same name in different classes. 2: We don’t truly know if new rrtypes
apply to all classes, or just one. It’s so long since we had other
classes that no one knows. Does the new TLSA rrtype apply to all
classes, or just “IN”?

Wes Hardaker: Are we trying to document reality or change reality? DNS
Classes have not been used for a long time. We can change the rules if
we like.

Peter Koch: With the CLASS registry closed, things like RFC 2136 (DNS
Dynamic Update) would not be possible; registration policy already
sets a high bar; bad ideas will not go away by closing the registry.
Class dependent RRTYPE definitions are a different issue.

Stéphane Bortzmeyer: I support this draft, and closing the DNS Class
registry. I remember the Net4D project a few years ago, which was a
technically flawed idea, encouraged by the belief that DNS Classes
could be used. The draft explains many reasons why trying to use DNS
Classes is a bad idea. In addition, many APIs do not allow specifying
the DNS Class. Even if the APIs exist, they are not widely tested, so
there are likely to be bugs that we have not found yet.

David Lawrence: Which WG is the right venue for this?

Andrew Sullivan: It can be discussed on the IAB Program list inip-
discuss. <https://www.iab.org/mailman/listinfo/inip-discuss> DNSOP is
also a place where this can be discussed.

John Klensin: Seems to me that fixing the spec to remove the parallel
tree language and restrict cross-class RRTYPEs would be
straightforward. I’d even volunteer to do the work, right after we get
i18n nailed down. [Presumably joking -- minute taker] (Laughter from
attendees in room.)

Joe Abley: AD sponsorship would be reasonable.



    draft-valsorda-dnsop-black-lies, Guðmundsson

<https://tools.ietf.org/html/draft-valsorda-dnsop-black-lies-00>
<https://www.ietf.org/proceedings/95/slides/slides-95-dnsop-9.pdf>

David Lawrence: What rcode?

Ólafur Guðmundsson: No error. (The name “exists”.)

David Lawrence: That might cause problems for some applications.

Ólafur Guðmundsson: Yes. For applications that care, bits in the NSEC
record let them derive the information they want.

Paul Hoffman: This is a good document as an Informational RFC. I don’t
think it updates RFC 4770 as shown on slides -- wrong RFC number. I
think it needs a better title.

Aaron Falk: Maybe publish first as Experimental, and then reconsider
Standards Track in a couple of years?

Mark Andrews: This interacts badly with aggressive negative caching.

Ólafur Guðmundsson: Yes, and no. We can tune how far away the ‘next
name’ is, because we’re signing on the fly.

Mark Andrews: With random attacks the space is almost infinite. The
only way to close them down is a negative answer. Extending the ‘next
name’ will not work once people adjust to this.

Ólafur Guðmundsson: Let’s discuss this further on the list. I believe
it’s workable. You do not.



    draft-vavrusa-dnsop-aaaa-for-free, Guðmundsson15 min

<https://www.ietf.org/proceedings/95/slides/slides-95-dnsop-9.pdf>

Stuart Cheshire: Clarification: When you say “poison the caches” you
mean “preload caches with correct information”, right?

Ólafur Guðmundsson: Yes.

Andrew Sullivan: The problem is the signalling is needed in any case,
because the chains might be multiple resolvers long. The authoritative
server doesn’t know what’s happening at the other end of the chain. We
know that resolvers that set the DO bit can accept *some* extra
records. Using the DO bit presupposes EDNS0. We still don’t know what
happens with resolvers that don’t set DO and you give them something
extra.

Robert Martin-Legene: You are doing this to make things faster?

Ólafur Guðmundsson: No. The goal is to get more IPv6 connections.

Robert Martin-Legene: Okay.

Ed Lewis: I recommend doing a document search. I know the question of
trustworthiness vs. DNSSEC signed data has been discussed. Has that
ever been documented?

Ólafur Guðmundsson: There was an extensive discussion of this topic
when we were doing DNSSEC. For some reason I don’t recall we decided
not to document this. We also decided not to document negative answer
generation based on NSEC records.

Paul Wouters: We also touched on this while discussing EDNS query
chain. I suggested using the NSEC bitmap to add any queries you want,
like TLSA.

Shane Kerr: Your focus is on communication from recursive resolvers to
authoritative servers, right?

Ólafur Guðmundsson: Yes.

Shane Kerr: Should also do this for stub-to-recursive communication
too. This could halve the query load on recursive resolvers.

Erik Kline: Is there any data that suggests this actually saves RTTs
(for non-validating clients, say...)? Many resolvers ask for AAAA
first, if IPv6 is a possibility for the client.

Ólafur Guðmundsson: I am not aware of any data.

Stuart Cheshire: iOS and OS X start AAAA query first, then A
immediately afterwards (running in parallel).

Erik Nygren: Android (at least in some cases) does the two queries
sequentially, not in parallel.

Christian Huitema: Microsoft does both queries in parallel. Problem
happens if you wait for both responses, which adds latency.



- 6761 Discussion

    draft-adpkja-dnsop-special-names-problem  30 min draft-tldr-sutld-
    ps

<https://tools.ietf.org/html/draft-adpkja-dnsop-special-names-
<problem-02> https://tools.ietf.org/html/draft-tldr-sutld-ps-00>

<https://www.ietf.org/proceedings/95/slides/slides-95-dnsop-10.pdf>

(Warren Kumari & Ted Lemon presenting)

Dan York: Your third bullet says: > DNS names are the installed base,
new name resolution protocols > have to exist under a label reserved
under RFC6761. Names don’t *have* to be reserved under RFC 6761 rules.
In reality, developers are free to do what they want without talking
to the IETF at all.

Warren Kumari: You are right, “have to” is overstating it.

Stuart Cheshire: This document talks almost exclusively about TLDs,
whereas RFC 6761 is not at all about TLDs; it’s about special
behaviors and how names can be algorithmically identified as
triggering those special behaviors. For example,
<https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-dot-arpa>
talks about special behavior relating to “ipv4only.arpa”, which is not
a TLD.

Warren Kumari: Yes, you’re correct.

Ralph Droms (co-author of TLDR draft): The important question is
whether, within these documents, there is a clear and useful list of
problems we can use as the basis for working group development?

Andrew Sullivan: Thanks Ted and Ralph for for writing the TLDR version
of this problem statement. It is orders of magnitude easier to
understand than the adpkja version, and considerably better focussed
on the technical issues.

Ray Bellis: Is the TLDR name an intentional joke (“too long; didn’t
read”)?

Ted Lemon: Yes (with Ralph’s agreement).

Stuart Cheshire: As I’ve said already on the mailing list, the adpkja
draft focusses far too much on the question of the names, and
completely ignores any consideration of the new behaviors people want.
Here at the IETF we’re interested in writing software, and how that
software behaves. The use of algorithmically recognizable names is
merely a means to that end. At this IETF (arcing Bof) we’ve discussed
carrying around an extra resolution context in a tuple, and why that’s
not practical. The “gethostbyname” family of APIs don’t have any way
to specify a context. We could expand that family of APIs to take a
string plus a context identifier, but then we would need an IETF
working group to debate who owns the namespace of context identifiers.
We’d need a context identifier for the context identifiers.
Recognizing that adding more layers of indirection doesn’t solve the
problem, we need a way to have a name be self-describing. That means
that something about the name tells you the context you use to look it
up. That technical motivation behind doing this seems to be completely
ignored by the adpkja draft, at present. That’s what I think is
missing.

We need to remember that there are two layers here. There is the API
layer of “gethostbyname” and friends, and then there is the on-the-
wire DNS protocol layer. We assume that those two layers are tied
together, but we know they are not. There has been the /etc/hosts file
since the start, there’s NetBIOS, Multicast DNS, dot-onion, the
nsswitch mechanism in Linux that let any developer plug in whatever
they want to do. Without some cooperation we just have chaos. It feels
like the adpkja draft is about defending ICANN’s revenue. Honestly,
what the “gethostbyname” APIs mean depends exactly what vendors like
Microsoft, Android and Apple feel they ought to mean. As long as the
DNS and the IETF provide a useful service for the public good then we
all support that, but there is no law that says we are obliged to make
APIs that funnel money to ICANN.

David Conrad: As far as I know, ICANN has no opinion here. There is no
assertion that anyone has to abide by anything that ICANN says with
regards to that namespace. We have RFC 2860 (Memorandum of
Understanding Concerning the Technical Work of the IANA) that says the
IETF has the ability to reserve special names. My view of RFC 6761 is
that it is a mechanism by which that could be exercised. That has
absolutely nothing to do with the new gTLD program. The issue is that
we have a multipolar world in an environment that assumes a unipolar
world.

Warren Kumari: In some cases what the IETF says and what ICANN says
doesn’t really matter. We are not the police here, we have no ability
to stop developers doing what they want. If we provide a way that it
is easy and friendly, maybe they will follow it, but if someone wants
to create a dot-something, or a different name resolution mechanism,
like hashtags in twitter, there is nothing we can do to stop them.

Suzanne Woolf: The IETF arcing BoF discussed these issues, and those
drafts are good reading about these namespace issues.

Ted Lemon: The whole point of the TLDR draft was to up-level the
conversation. When we talk about solutions before we talk about what
the problems are we wind up not clearly seeing the things we are
giving up or the things we are getting. I don’t disagree with what you
said, Stuart, but for now I want to discuss specifically what the
problems we are trying to solve, and not how we are going to solve
them. I wanted to make that crystal clear in the document.

Ralph Droms: In whatever document we take forward we should be sure to
capture what David Conrad just said.

Ted Lemon: There are three problems I have become aware of since we
wrote document that aren’t in the current version. I don’t remember
the details but I have them in my notebook. There has been some
discussion specifically about how to document the issue David Conrad
raised.

Peter Koch: I take offense in being accused of co-conspiring
protecting ICANN’s income; this is not about ICANN, it’s about the
IETF behaving consistent: consistent with the architecture, consistent
with the 2860 MoU and consistent with the 6761 procedure to start
with; also we do have identified open issues in 6761 - and that was
the task.

Stuart Cheshire: Peter is making a good point. I was not accusing any
of the authors of the adpkja draft of having ICANN’s income as their
primary interest. My comment was addressed at this document: that
right now it completely ignores the special behaviors that developers
want. That’s what I think is unbalanced about this document. It’s all
about the names, and not about the behaviors. The document is not
balanced right now.

Suzanne Woolf: What I’d like to have conversation focus on for now is
that we do have two drafts that between them list some specific issues
and what I think we need to be working towards is a list of issues so
that we can then start saying, “If we do this then it will solve this
subset of the challenges.” Because I saw a relative small number of
hands raised by people who have read the drafts I think what we need
to do is solicit more comments and discussion on the lists, and focus
on the technical and operational pieces of this. We need to spend the
next few weeks focussing on what the symptoms we are trying to
alleviate look like.

Thanks to everyone for contributing.

See you in Berlin.



END