Subject: [dnsext] I-D Action:draft-ietf-dnsext-dnsproxy-03.txt

From: [email-masked]
Date: Tue, 3 Mar 2009 01:00:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS Extensions Working Group of the IETF.

	Title           : DNS Proxy Implementation Guidelines
	Author(s)       : R. Bellis
	Filename        : draft-ietf-dnsext-dnsproxy-03.txt
	Pages           : 13
	Date            : 2009-03-03

This document provides guidelines for the implementation of DNS
proxies, as found in broadband gateways and other similar network
devices.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnsproxy-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: [email-masked]
Date: Tue, 3 Mar 2009 09:26:34 +0000

>    Filename        : draft-ietf-dnsext-dnsproxy-03.txt

This small update addresses the editorial nits found by Alex Bligh.

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Alex Bligh <[email-masked]>
Date: Tue, 03 Mar 2009 09:55:42 +0000

I suspect there is probably no useful answer to this, but anyway.

I think $subject is a useful draft. I hope it gets turned into an RFC (let's
say RFC54321). One very useful product of that would be that next time a
relative goes into PC World to buy a piece of ADSL hardware, and says
"please tell me which one to pick", I can say "just make sure it has
RFC54321 support in the big list of numbers on the back". More
realistically, ISPs could make purchasing decisions for bulk CPE based
on RFC54321 compliance, or put in RFC54321 compliance as a tender
requirement.

Or can they? As everything in the document is a "SHOULD" / "SHOULD NOT",
no CPE will break any mandatory requirement. Therefore, is every bit of
CPE right now not already compliant? Or to pick a less extreme example,
is CPE that meets every requirement but two "SHOULDs" compliant? It seems
to me it is.

I appreciate the purpose of the document is to guide, but another way to
look at it would be to say "to comply with this RFC, you must meet all
the specs in it; your CPE will not explode if it doesn't meet the
requirements, nor will the internet police arrest you, but you won't
comply with the RFC". Then we do (effectively) a s/SHOULD/MUST/g on
the document.

I know that changes the nature of the document from a "helping hand BCP"
to a "gold standard for CPE DNS behaviour", but I am having second thoughts
(but remain undecided) as to whether or not that's a bad thing.

Alex

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 04 Mar 2009 08:22:26 +1100

> comply with the RFC". Then we do (effectively) a s/SHOULD/MUST/g on
 
	There are MUSTs in the document.  Part of the problem is that
	it is written to account for both a DPI firewall and a plain
	DNS proxy which is not inspecting data.

	Writing a document that is focused on firewalls and DNS may be
	one way to work around this.

	Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 04 Mar 2009 11:56:49 +1100

Section 4.4.3. IP Fragmentation doesn't mention about the
	handling of out of order fragments.

	Mark

---

From: Alex Bligh <[email-masked]>
Date: Wed, 04 Mar 2009 09:23:38 +0000

Ray,

4.5.  Secret Key Transaction Authentication for DNS (TSIG)
>    As per Section 4.3, DNS proxies SHOULD be capable of proxying packets
>    containing TKEY [RFC2930] Resource Records.

All the provisions within 4.3 are MUSTs.

Alex

---

From: Alex Bligh <[email-masked]>
Date: Wed, 04 Mar 2009 09:27:06 +0000

> 	DNS proxy which is not inspecting data.

True, but not many (6, that are not explicitly referring to MUSTs from
other RFCs, though granted these are important).

>       Part of the problem is that

Sure. But I think there are 'SHOULD's in there which are not specific
to both. For instance (all from section 4):

   DNS proxies SHOULD therefore be prepared to receive and forward
   queries over TCP.

   However some proxies have been observed to either reject (with a
   FORMERR response code) or black-hole any packet containing an OPT RR.
   As per Section 4.1 proxies SHOULD NOT refuse to proxy such packets.

   Therefore proxies SHOULD (whichever of options 2 or 3 above is in
   use) be capable of forwarding UDP packets up to a payload size of at
   least 4096 octets.

   Since UDP packets larger than 512 octets are now expected in normal
   operation, proxies SHOULD NOT truncate UDP packets that exceed that
   size.

I think my argument could be applied to section 4 of the document,
if not sections 5 and 6.

Alex

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 4 Mar 2009 09:15:57 -0500

> I think my argument could be applied to section 4 of the document,

[no hat]

Remember that MUST is a word that brooks no exceptions.  Are you
arguing that, for the cases above, under no circumstances should the
device behave as described?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 04 Mar 2009 15:16:18 +0000

> device behave as described?

First, as per the message that started the thread, I am more interested
in investigating the question as to whether the draft should contain
more mandatory elements, so compliance with it means more, rather than
pushing a particular line.

Second, assuming the answer to that investigation is "yes", then (at
least with the four above) I think the answer to your question is
"yes, for the device to be compliant". As I said, if the device is
not compliant with the resultant RFC, it will still work, the police
won't arrive, and it will be compliant with a slew of other RFCs.
However, it won't be compliant with this one. Which means that an
ISP who asks in tender documents to CPE manufacturers "Is
the device RFCnnnn compliant?" will receive the answer no, which in
turn puts some more pressure on manufacturers to make it compliant.

The point I'm getting at is are we just trying to put together a helpful
set of guidelines for CPE manufacturers as to how they should design
the DNS part of their equipment (in which case /arguably/ the document
is really a BCP), or are we trying to specify a standard which, if
a CPE manufacturer wishes to meet it, specifies mandatory behaviour
compliance with which is sufficient to guarantee that the purpose of
the draft is met. Right now, CPE could meet all six of the 'MUST's
and be a complete pig; I suspect it could fail every (or nearly every)
of the tests sequence that inspired Roy's draft. It would be interesting
to know how many of those CPE tested would be compliant with all 6 MUST
requirements (as technically the manufacturer could claim compliance
without meeting any of the 'SHOULD's).

Alex

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 4 Mar 2009 10:24:35 -0500

[no hat]

Not without explaining why they don't meet the SHOULDs, in my reading
of RFC 2119.  In particular, I think RFC 2119 is perfectly clear that
SHOULD does not mean "optional", and it seems that your argument
depends on such an understanding of SHOULD.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 04 Mar 2009 16:20:57 +0000

Hang on. RFC2119 says:

> 3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.

So, my understanding is that an CPE vendor who claims to have "carefully
weighed" their failure to meet all the SHOULD recommendations could
claim compliance. There would be no objective method of disproving
compliance. It would be far easier to show whether their hardware
did "sensible stuff or not" on a full bench evaluation. But that
doesn't give the advantage of being able to accurately specify in
a tender document (or whatever) that you want full compliance with
(say) each of the 'SHOULD' recommendations in 2119.

There isn't a requirement (moral, legal or otherwise) to publicly explain
/why/ you don't meet any SHOULD requirements.

If your point is "well, SHOULD requirements are just as effective, or
nearly as effective, to put on vendor pressure" and that is indeed
the case, then that rather surprises me, but there would be no
need to change things.

If we treat this an an RFC that specifies correct behaviour for CPE,
then I think it is indeed the case that with regard to most of the
'SHOULD's in section 4, there are no valid reasons in particular
circumstances to ignore that item. Sure, vendors /can/ ignore
them, but then their CPE will not be compliant with RFCnnnn. This is
nothing new. For instance, RFC3597 says "name servers and resolvers
MUST handle RRs of unknown type transparently." (pretty close to one
of the "SHOULD"s in section 4). One that doesn't (and there are many)
is simply not compliant with RFC3597.

Alex

---

From: [email-masked]
Date: Wed, 4 Mar 2009 16:49:17 +0000

> is simply not compliant with RFC3597.

Alex,

The intent of the draft is *not* to proscribe behaviour that is not 
otherwise mandated elsewhere.  As per the title, these are "guidelines", 
they are not "rules".

If there are mismatches in requirements language between RFCs that I've 
cited and the draft then I believe those should be corrected.  The TKEY 
paragraph in §4.5 appears to be one such case - I'm not aware of any 
others.

cheers,

Ray

---

From: Alex Bligh <[email-masked]>
Date: Wed, 04 Mar 2009 16:58:33 +0000

> otherwise mandated elsewhere.  As per the title, these are "guidelines",

Well, if that is to remain the intent of the draft, then no changes
need to be made (apart from the inconsistency with the quoted RFC
that I pointed out). I was just wondering whether it was worth
repurposing your excellent draft to be a standard-defining document,
but it appears there is a distinct lack of support for this.

Alex

---

From: [email-masked]
Date: Wed, 4 Mar 2009 17:02:15 +0000

> but it appears there is a distinct lack of support for this.

I think possibly a separate draft updating RFC 1035 that specifically 
deprecates the 512 byte limit and mandates EDNS0 support might be of use.

However I'd like this current draft to be published before the end of the 
decade ;-)

cheers,

Ray