Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

In message <46726B00-1592-4F0B-9E95-960D1645E6D8@puck.nether.net>, Jared Mauch 
writes:
> 
> On Oct 20, 2011, at 1:52 PM, Hemant Singh (shemant) wrote:
> 
> > 
> > -----Original Message-----
> > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
> > Of Jared Mauch
> > Sent: Thursday, October 20, 2011 12:50 PM
> > To: Jeroen Massar
> > Cc: IPv6 Operations; draft-ietf-v6ops-6204bis@tools.ietf.org
> > Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis
> > 
> > 
> >> This is a long war against the firewall culture that we are unlikely to
> > win.  The less clued out there continue to set local security policies
> > in a way that >break and inhibit the proper use of technology.  While
> > this may seem defeatist, we should certainly continue to educate these
> > folks.
> > 
> > See RFC 4890, section 4.3.1.  
> > 
> > Hemant
> 
> Yeah, but try to make someone who says "i'm from IT/Security" i'm here to hel
> p read/know what a RFC is.
> 
> Lost cause in most cases.  These are the same folks who think that TCP/53 is 
> just for zone transfers and will keep their head in the sand about dnssec/edn
> s0 too.

If you block PTB you get slow connections.
If you block DNS responses > 512 bytes you get slow DNS lookups.
If you block fragmented UDP you get slow DNS lookups.
If you block TCP/53 you get DNS lookup failures.

All of these are very noticable when they are occuring.

On the DNS side of things (the last 3) these are usually self
inflicted and can be self corrected.  Even Microsoft now accepts
TCP/53 to their servers though it took several years of complaints.

When I've encounted web sites that block PTB I've usually been able
to get the problem fixed.  For TCP/53 there is now a RFC that make
TCP/53 a MUST, overriding the stupid SHOULD on RFC 1123.

People do correct these sorts of faults.  I see this being done
regularly.  Yes, it is a slow process.

As for TCP/53, *all* of the root servers are currently sending out
incorrect referral for COM/NET etc as they are, incorrectly, dropping
glue records.  Only additional data is supposed to be dropped and
while glue is in the additional section it is *not* additional data.
This behaviour can cause referrals to fail.  GOV experienced such
failures a couple of months back and the solution was to upgrade the
servers to ones that set TC=1 when glue doesn't fit when the glue
matched the query.

Upgrading the root servers to alway set TC=1 when glue doesn't fit
will fix the TCP/53 isn't required myth.  Some of them already set
TC=1 when the glue matches the query and it doesn't fit.

Mark

> - jared
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org