Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck)

From: Mark Andrews <[email-masked]>
Date: Sat, 27 Jun 2009 17:06:34 +1000

In message <2BEF3C0F30F143D18E720A3E36001E1D@localhost>, "George Barwood" write
s:
> 
> ----- Original Message ----- 
> From: "Mark Andrews" <[email-masked]>
> To: <[email-masked]>
> Cc: "Mark Andrews" <[email-masked]>; "Alex Bligh" <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Friday, June 26, 2009 11:50 PM
> Subject: Re: Real data (was Re: [dnsext] Danger of coming unstuck) 
> 
> 
> > 
> > In message <[email-masked].>, [email-masked]
> > roshi.com writes:
> >> On Sat, Jun 27, 2009 at 12:20:05AM +1000, Mark Andrews wrote:
> >> > 
> >> > In message <[email-masked]>, Alex Bligh writes:
> >> > > 
> >> > > > I'm not aware of any specific problem with higher-grade firewalls
> >> > > > interfering with the subsequent queries sent between the recursive
> >> > > > resolvers and authoritative servers.
> >> > > 
> >> > > Sometimes the issue is with the configuration rather than the
> >> > > device. The following is a snippet from a PIX config.
> >> > > 
> >> > > policy-map type inspect dns preset_dns_map
> >> > >  parameters
> >> > >   message-length maximum 512
> >> > > 
> >> > > A google search for "message-length maximum 512" suggests this
> >> > > is not uncommon, and indeed appears to be splashed over a number
> >> > > of cisco.com example configs.
> >> > 
> >> > And you will also see people saying to raise this to 4096.
> >> > 
> >> > Mark
> >> > 
> >> 
> >> is there any good reason not to?  if, of course, they 
> >> want to follow the protocol...
> > 
> > The protocol was extended 10 years ago give or take a couple of
> > months.  These firewalls were written well after the extension was
> > published.  Firewall designers need to understand the protocols
> > they are playing with.  It was not like there were not active
> > examples around when these were designed.  The designers just didn't
> > do their home work.
> 
> Isn't it the firewall configuration, rather than the firewall designer?

It's the designers that added "message-length maximum <value>" to the
firewall's syntax. 

> Regardless, system administrators did follow the existing standard, 
> and I think it is rather the fault of RFC 2671 for breaking an existing
> standard.

RFC 2671 allows the two parties involved to negotiate the use of
additional features.  This is common to lots of protocols.  It is also
all that should be reqired.
 
> I suggest an extension mechanism that allows for DNSSEC messages to be 
> conveyed through the existing deployed transport ( 512 byte UDP packets ) 
> should have been defined, and this can still be done, along the lines of my 
> "EDNS Page Option to handle large responses", 
> http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg01278.html

Multiple messages were thought about and rejected.  We still need the MORE
bit for TCP at some point.

> The goal should be to allow DNSSEC to be deployed without reconfiguring
> firewalls or anything other than the DNS software.

Sorry, firewalls should not be a reason to not do something.  That's the
tail wagging the dog.  10 years should have been enough for firewall vendor
to fix their products especially when we complained to most of the over
5 years ago about their in action.  It's the firewalls role to adapt to
changes in the protocols.
 
> > Network Working Group                                            P. Vixie
> > Request for Comments: 2671                                            ISC
> > Category: Standards Track                                     August 1999
> > 
> > If they want to live by RFC1034 then they should examine the queries
> > and return FORMERR on them for having garbage in the additional
> > section.  This would have made extending the DNS predicable.
> 
> No, there is nothing in RFC1034 or RFC 1035 that specifies that 
> an OPT record should cause a FORMERR. In any communications 
> standard there may be reserved areas in the packet format that are 
> not defined, and may be used at some future point to extend the protocol.

FORMERR is the error code to be returned when you don't understand the
query.  That is the point of the error code.

> These can be header bits, code points ( e.g. RR TYPE codes ), 
> or correctly formatted records where the meaning is not defined.
>
> The proper way to process reserved areas is to ignore them.
> Unfortunately many implementations get this wrong, so it would have
> been better if the original standard had been more explicit on this principle.

There are lots of things RFC 103[345] should have done better however it
was reasonable for the time.  The additional section was not a reserved
area in queries.

> > Alternatively they should examine the queries and set the allowed
> > response size based on the EDNS options in the query.  There is no
> > need for a one size solution.
> > 
> > And for the record there have been larger than 512 bytes responses
> > over UDP between co-operating machines as long as I've been involved
> > with DNS and thats over 20 years now.  EDNS just provided a standards
> > based mechanism for doing so.  We had code to catch and handle
> > responses from such servers years before EDNS was dreamed of.
> > 
> > Mark
> > 
> >> 
> >> --bill
> >> 
> >> --
> >> 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/>
> > -- 
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
> > 
> > --
> > 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/>
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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/>