Subject: [DNSOP] Rough Draft of minutes from IETF88

From: Tim Wicinski <[email-masked]>
Date: Tue, 12 Nov 2013 03:20:21 -0500

I've uploaded the minutes, with an initial editing pass. There are 
located here:

http://www.ietf.org/proceedings/88/minutes/minutes-88-dnsop

Big thanks to Stephane Bortzmeyer for doing an first class job on these.

Over the next week or so, I'm going to start moving forward some of the 
discussions that came up during the meeting, and afterwards.

Thanks
tim

---

From: Jelte Jansen <[email-masked]>
Date: Tue, 12 Nov 2013 10:36:56 +0100

> http://www.ietf.org/proceedings/88/minutes/minutes-88-dnsop

I wasn't there, and wasn't able to follow remotely this time, but I
assume that "Evan Hunt: csync is push, competitor (dynamic update, see
Mark Andrews) is pull." was actually the other way around.

And a side note about a later topic, PCP to update Dynamic DNS, I had
actually seen that draft, and object to the statement that 'SRV http is
not yet supported by a lot of browsers'. I haven't been following the
http specs recently but last time I checked, SRV wasn't defined for
http, so browsers *shouldn't* 'support' it.

Jelte

---

From: Tony Finch <[email-masked]>
Date: Tue, 12 Nov 2013 11:47:15 +0000

> http://www.ietf.org/proceedings/88/minutes/minutes-88-dnsop

Re. edns-tcp-chain-query and edns-tcp-keepalive, the minutes say "DNSSEC
requires many round-trips to get all the data needed to validation."

This is probably a correct report of what was said but the statement is
wrong. In most situations you can get everything needed to validate in one
round trip; the problem is that current implementations do not do this.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 12 Nov 2013 10:15:52 -0500 (EST)

> round trip; the problem is that current implementations do not do this.

Really? If I want to validate www.nohats.ca, and I don't have more than
the DS/DNSKEY of ca, how can I do this in one round trip without these
drafts? You mean just adding items in the additional section?

Paul

---

From: Tony Finch <[email-masked]>
Date: Tue, 12 Nov 2013 15:38:43 +0000

> drafts? You mean just adding items in the additional section?

No. Send the following separate queries concurrently:

www.nohats.ca A
www.nohats.ca AAAA
www.nohats.ca DNSKEY
www.nohats.ca DS
    nohats.ca DNSKEY
    nohats.ca DS

I discussed this strategy in more detail in
https://www.ietf.org/mail-archive/web/dnsext/current/msg13540.html

Note that any client which knows it should make a chain query can just as
well send the equivalent separate concurrent queries.

Tony.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 12 Nov 2013 22:38:09 -0500 (EST)

> https://www.ietf.org/mail-archive/web/dnsext/current/msg13540.html

Apart from being messy, it does not work if you want to query and
remember NS records (in case you have to switch from forwarding mode
to being a full recursor) and it fails when CNAME/DNAME is involved,
as you also point out. If the chain gets longer, I guess you are also
increasing the effects of packet loss, as every single query has to
return successfully.

In general, we did not talk yet about putting other entries in the
additional section. Normally, validators strip those out, but if these
are DNSSEC validatable, it could accept these as well. In that way,
a query for bigsite.com could also send DNSSEC validatable data for
its CDN and/or advertisement providers. But that does really change the
semantics of what a dns query is really asking.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Wed, 13 Nov 2013 15:01:05 +1100

In message <[email-masked]>, Paul Wouters w
rites:
> to being a full recursor)

Garbage.  There is absolutely nothing stopping you remembering NS
records returned in the responses above.  If you have to switch the
NS records will be in the A response or not be available at all.

> and it fails when CNAME/DNAME is involved, as you also point out.

It doesn't fail when a CNAME or a DNAME is involved.  The data is
useful to validate the CNAME/DNAME and you just initiate more
queries to validate the target of the CNAME/DNAME.a

> If the chain gets longer, I guess you are also increasing the effects
> of packet loss, as every single query has to return successfully.

Which is why you do it over TCP and let the transport layer handle
the retransmissions.

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 12 Nov 2013 23:24:40 -0500 (EST)

> NS records will be in the A response or not be available at all.

Yes you can ask for the NS records, and the NS records that are in
a completely different zone, at the expense of launching new queries,
adding round trips.

> queries to validate the target of the CNAME/DNAME.a

Yes, more round trips. The idea one to do it in ONE round trip.

> Which is why you do it over TCP and let the transport layer handle

Exactly. Over tcp using query-chain :)

Paul

---

From: Tony Finch <[email-masked]>
Date: Wed, 13 Nov 2013 10:31:37 +0000

Mark Andrews <[email-masked]> wrote:
> Paul Wouters wrote:

I think it is slightly more subtle than that. There is a big question
about how much information about CNAME/DNAME validation chains should be
returned in response to Paul's chain query, especially when the target of
the CNAME is not under the known domain stated by the client. For instance
I bet the client doesn't want to repeatedly receive validation chains for
akadns.net, edgekey.net, akamaiedge.net just because they are quering for
various names in .com. But if the server doesn't send all the validation
chains, the client will require two round trips, just as it would if the
server did not support chain queries.

I would like to see more work done on reducing validation latency within
the existing protocol, for iterative resolvers as well as forwarding
resolvers, so we can get a better idea of when chain queries might help.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Wed, 13 Nov 2013 12:15:06 +0000

> a completely different zone, at the expense of launching new queries,

You can get all the info in two round trips at most. First round trip: ask
for NS records at all the potential zone cuts; second round trip, ask for
the NS target address records and relevant DS+DNSKEY records.

Tony.