IETF 69 DNSOP meeting minutes

Dear WG,

the attached minutes of our Chicago meeting have been available at
<http://www3.ietf.org/proceedings/07jul/minutes/dnsop.txt> since
2007-08-24, yet not been posted to the list.

The final deadline for the overall IETF69 minutes is tomorrow, Wednesday,
2100 UTC.  Please submit any comments asap. Apologies for missing an
earlier post.

Thanks go to John Kristoff (scribe) as well as Jaap Akkerhuis and
George Michaelson (jabber).

-Peter

-----------------------------------------------------------------------------
           dnsop WG minutes for IETF 69, Chicago, IL USA
-----------------------------------------------------------------------------
WG:        DNS Operations (dnsop)
Meeting:   IETF 69, Chicago
Location:  Palmer House Hilton, "Monroe"
Date:      Tuesday, 24 July 2007
Time:      09:00 - 11:30 (UTC -0500)
Chairs:	   Rob Austein, Peter Koch
Minutes:   John Kristoff
Jabber:    xmpp:dnsop <at> jabber.ietf.org
J-Scribe:  Jaap Akkerhuis, George Michaelson 
J-Script:  http://www3.ietf.org/meetings/ietf-logs/dnsop/2007-07-24.html
Audio:     http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf69/ietf69-ch8-tue-am.mp3

[fwd] Last Call: draft-weiler-dnssec-dlv-iana (DNSSEC Lookaside Validation (DLV) IANA Registry) to Informational RFC]

Dear WG,

the IETF wide Last Call mentioned below lasts until 2007-09-20. Since it's
kind of a DNS operational topic, WG participants might be interested.
Discussion should take place on the IETF list, as requested.

-Peter

----- Forwarded message from The IESG <iesg-secretary <at> ietf.org> -----

From: The IESG <iesg-secretary <at> ietf.org>
To: IETF-Announce <ietf-announce <at> ietf.org>
Subject: Last Call: draft-weiler-dnssec-dlv-iana (DNSSEC Lookaside 
 Validation (DLV) IANA Registry) to Informational RFC 
Date: Thu, 23 Aug 2007 16:12:05 -0400
Reply-To: ietf <at> ietf.org

A Last Call mesage was sent earlier today.  It was missing an important
word in paragraph (b).  Please respond based on this text.

The IESG has received a request from an individual submitter to consider
the following document:

- 'DNSSEC Lookaside Validation (DLV) IANA Registry'
   <draft-weiler-dnssec-dlv-iana-00.txt> as an Informational RFC

DNSSEC Lookaside Validation (DLV) is a mechanism for distributing
DNSSEC trust anchors within the DNS protocol.  It is documented
in draft-weiler-dnssec-dlv.  This is a companion document that
describes the action necessary for IANA to implement DLV.

200709 Document Status Update

Dear WG,

find below the list of WG documents and their current status as seen by the
chairs (see also <http://tools.ietf.org/wg/dnsop/>):

o draft-huston-6to4-reverse-dns-07.txt
  <https://datatracker.ietf.org/idtracker/draft-huston-6to4-reverse-dns/>

   <at> IESG, Publication requested
  resolving DISCUSSes

o draft-ietf-dnsop-reflectors-are-evil-04.txt
  <https://datatracker.ietf.org/idtracker/draft-ietf-dnsop-reflectors-are-evil/>

   <at> IESG, Publication requested
  awaiting IETF Last Call

o draft-ietf-dnsop-default-local-zones-02.txt

  passwd WGLC, shepherd discussing NITS review with editor

o draft-ietf-dnsop-reverse-mapping-considerations-05.txt

  under discussion, awaiting WGLC

o draft-ietf-dnsop-as112-ops-00.txt

  EXPIRED
  update expected, then awaiting WGLC

Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP

The IESG has received a request from the Domain Name System Operations 
WG (dnsop) to consider the following document:

- 'Preventing Use of Recursive Nameservers in Reflector Attacks '
   <draft-ietf-dnsop-reflectors-are-evil-04.txt> as a BCP

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2007-09-25. Exceptionally, 
comments may be sent to iesg <at> ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-reflectors-are-evil-04.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14686&rfc_flag=0

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop

Re: Review of draft-ietf-dnsop-respsize-07

On Wed, Jun 27, 2007 at 11:06:26PM +0200,
 Stephane Bortzmeyer <bortzmeyer <at> nic.fr> wrote 
 a message of 83 lines which said:

> First, I would like to say that I believe it is important to have a
> stable and reviewed document about this response size issue since it
> is one we'll typically have to deal with in the future (IPv6,
> DNSsec, IDN, etc).
> 
> This is specially important since worries about response sizes have
> already been used to back political decisions.

Do note that issues about response size did not prevent ICANN to
create this night a TLD with a NS records RRset of 480 bytes...

May be noone worries any more about DNS response size?

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop

Re: secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt

I opposed this document in the DNSOP working group.  I have found some 
additional reasons to oppose this document, in addition to the reasons I 
gave to the DNSOP WG.  I generally agree with Stephen Hanna's findings.

I.   Harm only possible for ENDSO; Update RFC 2671 Instead
II.  Authority Servers not Addressed, but Present More Harm
III. Motivating Attacks Seem Contrived
IV.  Ordinary DDOS Mitigation Appropriate for Reflector Case
V.   Mitigation Options Limited in Authority Case
VI.  Using "Evil" in a RFC Title is Unprofessional
VII. Reflectors are Useful for Scientic Measurement
VIII.Conclusion: Insufficient Harm to Justify Action

I.   Harm only possible for ENDSO; Update RFC 2671 Instead

The maximum non-EDNS amplification factor is 8 (512 byte maximum
response / 64 byte minimum query)  The non-EDNS attack has been possble 
for over 20 years, but there have been no significant problems reported 
in that time.  There is no reason to think the non-EDNS case presents 
any problem, nor has that case ever presented a problem.

The significant harm posed by the attack described in this document is a 
result of EDNS extensions which allow DNS servers to respond with upto 
8K byte long response to a relatively short EDNSO query.

The EDNSO extension considered some security vulnerabilies created by 
the protocol extension. RFC 2671 states:

6 - Security Considerations

Re: Re: secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt

FYI, I see I missed a number of typo's with 'ENDS'. This should read
instead 'EDNS'. It is fixed below.

		--Dean

On Mon, 24 Sep 2007, Dean Anderson wrote:

> I opposed this document in the DNSOP working group.  I have found some 
> additional reasons to oppose this document, in addition to the reasons I 
> gave to the DNSOP WG.  I generally agree with Stephen Hanna's findings.
> 
> I.   Harm only possible for EDNSO; Update RFC 2671 Instead
> II.  Authority Servers not Addressed, but Present More Harm
> III. Motivating Attacks Seem Contrived
> IV.  Ordinary DDOS Mitigation Appropriate for Reflector Case
> V.   Mitigation Options Limited in Authority Case
> VI.  Using "Evil" in a RFC Title is Unprofessional
> VII. Reflectors are Useful for Scientic Measurement
> VIII.Conclusion: Insufficient Harm to Justify Action
> 
> 
> I.   Harm only possible for EDNSO; Update RFC 2671 Instead
> 
> The maximum non-EDNS amplification factor is 8 (512 byte maximum
> response / 64 byte minimum query)  The non-EDNS attack has been possble 
> for over 20 years, but there have been no significant problems reported 
> in that time.  There is no reason to think the non-EDNS case presents 
> any problem, nor has that case ever presented a problem.
> 
> The significant harm posed by the attack described in this document is a 

Re: getaddrinfo() and searching

On 27-sep-2007, at 3:33, Mark Andrews wrote:

>> So your issue that the results are inconsistent is certainly real.

>> I'd say that the best way to avoid this is not having a search domain
>> at all, or at the very least not several.

> 	Which is a totally unreasonable suggestion.

It's not. Even without IPv6, having search domains means you can get  
unexpected results. If that's not acceptable, don't complain, but put  
a period behind your FQDNs.

> 	The problem here is not the search but different stoping
> 	critera depending apon the address families supported by
> 	the host or requested by the application.

> 	We wrote a API that failed to account for the usual use
> 	senario.  In fact the guidance in there is the direct
> 	opposite of what should be done with the usual use senario.

I thought the solution would be hard or would be suboptimal in the  
common case, but I think that doesn't have to be so.

In my example, MacOS would go through the search domains and keep  
going until it found AAAA records for IPv6 or IPv4+IPv6 applications  
(and presumably look for A records if there were no AAAA records and  
IPv4 was present/requested also).

So basically, both the "answers = 0, noerror" and "nxdomain"  

Re: Re: getaddrinfo() and searching

On Thu, Sep 27, 2007 at 05:42:38PM +0200, Iljitsch van Beijnum wrote:

> It's not. Even without IPv6, having search domains means you can get  
> unexpected results. If that's not acceptable, don't complain, but put  
> a period behind your FQDNs.

thanks, Iljitsch, for bringing this into dnsop. I think that the problem
of determinism in following the search path is very well worth investigating.
To some extent it's related to RFC 1535 and we've at least had this under
"A.O.B." in one of the recent meetings, if I remember correctly.

> No, it's a DNS issue, so it should go to dnsop. dnsop people: see  
> discussion between Mark, Keith and me that started under the subject  
> "renumbering" on the ietf discussion list.

The semantics of search paths in mixed or dual stack environments need to
be clear, independent of a particular API, at least as long as the search
path isn't set API specific.  Seems that we should at least have a look into
this, see what implementations do and what operational and maybe security
consequences are.

-Peter

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop

Re: Re: getaddrinfo() and searching

> On 27-sep-2007, at 3:33, Mark Andrews wrote:
> 
> >> So your issue that the results are inconsistent is certainly real.
> 
> >> I'd say that the best way to avoid this is not having a search domain
> >> at all, or at the very least not several.
> 
> > 	Which is a totally unreasonable suggestion.
> 
> It's not. Even without IPv6, having search domains means you can get  
> unexpected results. If that's not acceptable, don't complain, but put  
> a period behind your FQDNs.

	Please state were in RFC 952 a final period is legal in
	a hostname. 

	Remember applications take HOSTNAMES not DOMAIN NAMES.
	There are HOSTNAMES that you cannot store in the DNS.
	There are DOMAIN NAMES that are not legal HOSTNAMES.

> > 	The problem here is not the search but different stoping
> > 	critera depending apon the address families supported by
> > 	the host or requested by the application.
> 
> > 	We wrote a API that failed to account for the usual use
> > 	senario.  In fact the guidance in there is the direct
> > 	opposite of what should be done with the usual use senario.
> 
> I thought the solution would be hard or would be suboptimal in the