[dns-operations] EDNS and TLDs

Wed Nov 16 20:10:04 UTC 2016

In message <CA+nkc8BQ0yFyhLCjAM0by-LwOwxxENSEQqanwVkxdywWpeZRVQ at mail.gmail.com>
, Bob Harold writes:
> --94eb2c145a6af2caa505416b9dcf
> Content-Type: text/plain; charset=UTF-8
> 
> On Wed, Nov 16, 2016 at 8:56 AM, Florian Weimer <fweimer at redhat.com> wrote:
> 
> > On 11/16/2016 02:21 PM, Bob Harold wrote:
> >
> >> On Wed, Nov 16, 2016 at 8:00 AM, Florian Weimer <fweimer at redhat.com>
> >> wrote:
> >>
> >> On 10/29/2016 11:06 AM, Phil Regnauld wrote:
> >>>
> >>> Mark Andrews (marka) writes:
> >>>>
> >>>>
> >>>>> Thanks.  Firewall are the biggest problems at the moment.
> >>>>>
> >>>>>
> >>>>         Firewalls in front of DNS servers still puzzle me.
> >>>>
> >>>>
> >>> If you want to run BIND, a packet filter in front of it currently is the
> >>> only way to switch off processing of DNS UPDATE messages in BIND, so I
> >>> can
> >>> see why people do this.
> >>>
> >>> Florian
> >>>
> >>>
> >>> Why not just:
> >>       allow-update { none; };
> >> in BIND?
> >>
> >
> > BIND will still process the DNS UPDATE messages, so that it can return the
> > right response code.
> >
> > I would expect that to be not much work processing than what the firewall
> >> has to do, and less because of the overhead of the firewall.
> >>
> >
> > As far as I know, your configuration change does not disable DNS UPDATE
> > processing because BIND determines the UPDATE capability of a view only
> > after it has found the view, which requires parsing the packet.
> >
> > BIND could have a global flag indicating whether any view has UPDATE
> > capability, an if it is not set, reject UPDATE messages early.  I'm not
> > sure if this change is worth it, or if all DNS UPDATE related bugs have
> > been ironed out.

Lots of FUD being flung around here.

> > Florian
> >
> 
> In general I agree.  If there are bugs in BIND packet processing that are
> not quickly fixed, then using a firewall (or iptables rule) in the interim
> is a reasonable solution.  But I would avoid it if possible.
> Adding an early exit if no updates are permitted might be a reasonable
> optimization to make.

>From the *start* of update processing. 

        /*
         * Update message processing can leak record existance information
         * so check that we are allowed to query this zone.  Additionally
         * if we would refuse all updates for this zone we bail out here.
         */
        CHECK(checkqueryacl(client, dns_zone_getqueryacl(zone), zonename,
                            dns_zone_getupdateacl(zone), ssutable));

Yes, this can give the "wrong" rcode (REFUSED) if we bailout here.

The message will still be parsed either way.  The update section
is examined to find the relevent acl as they are tied to the zone.
A view / option level acl is shared across zones.  At this stage
the only section that has been processed is the ZONE section.  The
prerequiste and update sections are yet to be processed beyond
parsing the message which is required to find TSIG / SIG(0) records
so that ACLs can be checked.

Per record checks are done further down.

UPDATE processing to this point leaks no more information than QUERY
processing leaks.

AXFR and UPDATE both leak that the server is configured for a zone.

Mark

> -- 
> Bob Harold
> 
> --94eb2c145a6af2caa505416b9dcf
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr"><div class=3D"gmail_extra"><div><div class=3D"gmail_signat=
> ure" data-smartmail=3D"gmail_signature"><br></div></div><div class=3D"gmail=
> _quote">On Wed, Nov 16, 2016 at 8:56 AM, Florian Weimer <span dir=3D"ltr">&=
> lt;<a href=3D"mailto:fweimer at redhat.com" target=3D"_blank">fweimer at redhat.c=
> om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
> in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""=
> >On 11/16/2016 02:21 PM, Bob Harold wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex">
> On Wed, Nov 16, 2016 at 8:00 AM, Florian Weimer <<a href=3D"mailto:fweim=
> er at redhat.com" target=3D"_blank">fweimer at redhat.com</a>> wrote:<br>
> <br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex">
> On 10/29/2016 11:06 AM, Phil Regnauld wrote:<br>
> <br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex">
> Mark Andrews (marka) writes:<br>
> <br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex">
> <br>
> Thanks.=C2=A0 Firewall are the biggest problems at the moment.<br>
> <br>
> </blockquote>
> <br>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Firewalls in front of DNS servers still puzzle =
> me.<br>
> <br>
> </blockquote>
> <br>
> If you want to run BIND, a packet filter in front of it currently is the<br=
> >
> only way to switch off processing of DNS UPDATE messages in BIND, so I can<=
> br>
> see why people do this.<br>
> <br>
> Florian<br>
> <br>
> <br>
> </blockquote>
> Why not just:<br>
> =C2=A0 =C2=A0 =C2=A0 allow-update { none; };<br>
> in BIND?<br>
> </blockquote>
> <br></span>
> BIND will still process the DNS UPDATE messages, so that it can return the =
> right response code.<span class=3D""><br>
> <br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex">
> I would expect that to be not much work processing than what the firewall<b=
> r>
> has to do, and less because of the overhead of the firewall.<br>
> </blockquote>
> <br></span>
> As far as I know, your configuration change does not disable DNS UPDATE pro=
> cessing because BIND determines the UPDATE capability of a view only after =
> it has found the view, which requires parsing the packet.<br>
> <br>
> BIND could have a global flag indicating whether any view has UPDATE capabi=
> lity, an if it is not set, reject UPDATE messages early.=C2=A0 I'm not =
> sure if this change is worth it, or if all DNS UPDATE related bugs have bee=
> n ironed out.<span class=3D"HOEnZb"><font color=3D"#888888"><br>
> <br>
> Florian<br>
> </font></span></blockquote></div><br></div><div class=3D"gmail_extra">In ge=
> neral I agree.=C2=A0 If there are bugs in BIND packet processing that are n=
> ot quickly fixed, then using a firewall (or iptables rule) in the interim i=
> s a reasonable solution.=C2=A0 But I would avoid it if possible.</div><div =
> class=3D"gmail_extra">Adding an early exit if no updates are permitted migh=
> t be a reasonable optimization to make.</div><div class=3D"gmail_extra"><br=
> ></div><div class=3D"gmail_extra">--=C2=A0</div><div class=3D"gmail_extra">=
> Bob Harold</div><div class=3D"gmail_extra"><br></div></div>
> 
> --94eb2c145a6af2caa505416b9dcf--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org