Subject: [dns-dir] Topics for the DNS Directorate?

From: Peter Koch <[email-masked]>
Date: Sun, 26 Oct 2008 14:53:44 +0100

Dear fellow DNS directorate members,

our next teleconference is routinely scheduled for next Monday,
03-NOV-2008, 15:00 UTC.  In Dublin we also agreed to have a dinner meeting
on Monday during the IETF week.  Any topics for either event?

Best regards,
    Peter
_______________________________________________
dns-dir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dns-dir

---

From: Peter Koch <[email-masked]>
Date: Mon, 27 Oct 2008 20:33:22 +0100

> on Monday during the IETF week.  Any topics for either event?

it's a bit late but following up to hallway discussions during the RIPE meeting
I'd like to suggest we do have a conf call next monday and start away with
these two agenda items:

1) Role of the DNS in current IPv4/IPv6 transition/translation/migration
   proposals
   Which drafts to look at, which WG sessions to follow in Minneapolis
    and how to organize review and advice

2) IPR claims by TS Glassey
   Mutual information on the state of affairs (probably avoiding discussion
   of the merits)

Best regards,
   Peter

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Oct 2008 09:31:02 -0400

>    and how to organize review and advice

This one is explicitly about the DNS:

http://tools.ietf.org/html/draft-bagnulo-behave-dns64

For reasons I don't completely fathom, Marcelo wanted my name on that  
as an author.  I have made some suggestions, and I think there's  
probably text directly lifted from an email I sent him.  I'm not sure  
I agree with everything in it, though.

There's also this:

http://tools.ietf.org/html/draft-wing-behave-learn-prefix-00

It discusses how to learn the prefix that it being added to an A  
record to get a AAAA, among other things.  This will be useful in case  
the translation is performed at the end node.

There are a couple ways the DNS translation stuff could work.  The  
first is to put a box in the network that does it.  Whatever the  
proponents might say, this is not entirely dissimilar to the old DNS- 
ALG.  Note, however, that the idea is really to make this work like  
part of the recursion-providing nameserver, so the stub contacts the  
ISP's recursing nameserver (call this Irn, so I can type less).  Irn  
performs the lookup, then does DNSSEC validation (assuming that's  
turned on), and _then_ does translation and hands back to the client.   
This obviously breaks if the end node is doing validation itself.

To get around the "broken endpoint validation" problem, it appears  
there are a couple options.  One is to perform the translation anyway,  
and have some additional bits (an EDNS0 option, a new RR in the  
additional section [ick], whatever) to tell the end node that  
translation has happened.  The end node can then un-translate,  
validate again, then re-translate and proceed as normal.  This seems  
to me to be a wheel that does no work, however, so I suggested that  
the translation-aware, security-aware DNS recursing server should do  
different things and send different responses depending on the DO and  
CD bits in a DNS query (this is the text I think is in Marcelo's  
draft).  It sort of sucks, but it's the best thing I've come up with  
yet.

I think it might also be worth looking at these, but I haven't really  
looked at them:

http://tools.ietf.org/html/draft-baker-behave-v4v6-translation

http://tools.ietf.org/html/draft-baker-behave-v4v6-framework