Re: DNS Flag Day - options for EDNS behavior control before then ?

[Mark Andrews]

Correct, there are no knobs in 9.13/9.14 for automatic fallback. 

Apart from a few very old Microsoft Windows DNS servers that don’t respond 
consistently to EDNS queries (they respond with FORMERR to the first query then 
don’t respond for a while to subsequent EDNS queries) there aren’t many servers 
that don’t answer EDNS queries any more.  That said there is still a single TLD 
server that doesn’t respond to EDNS queries at all.

server  { edns no; };

More likely you will strike a server that doesn’t respond to queries with DNS 
COOKIE options present and you will want to turn off sending that option.  This 
can be tested for with “dig +nocookie”.

server  { send-cookie no; };

Most of the problems are with stupid firewall defaults.  The firewall vendors 
want to be seen to be doing “something” with DNS and to hell with planned 
incremental deployment and interoperability.  STD 13 said what nameservers 
should do with unknown flags in the DNS header (ignore) and other changes 
(return FORMERR).  EDNS says to ignore unknown EDNS flags and options and to 
return BADVERS with the currently supported EDNS version for unsupported EDNS 
versions in requests.  These behaviours allow clients to be updated without 
having to update servers.  Firewall that drop queries aren’t doing anyone a 
service.  All they do is break interoperability.

Mark



> On 20 Dec 2018, at 6:39 am, Brandon Applegate  wrote:
> 
> Hello,
> 
> I did some searching on the ML archives and didn’t see what I’m trying to ask.
> 
> Is there anything (i.e. a config knob) in any current version of BIND that 
> allows one to control this ?
> 
> My understanding is that on (around ?) the DNS Flag Day of 2/1/19 - BIND 
> won’t retry (with EDNS disabled) non-answered EDNS queries - rather it will 
> consider them failures ?
> 
> I see that as of now there is this knob:
> 
> --
> server a.b.c.d {
>edns no;
> };
> —
> 
> But I’m talking about the behavior described in the DNS Flag day materials.  
> Is that simply going to be changed in code sometime around/on 2/1/19 ?
> 
> --
> Brandon Applegate - CCIE 10273
> PGP Key fingerprint:
> 0641 D285 A36F 533A 73E5  2541 4920 533C C616 703A
> "For thousands of years men dreamed of pacts with demons.
> Only now are such things possible."
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

DNS Flag Day - options for EDNS behavior control before then ?

[Brandon Applegate]

Hello,

I did some searching on the ML archives and didn’t see what I’m trying to ask.

Is there anything (i.e. a config knob) in any current version of BIND that 
allows one to control this ?

My understanding is that on (around ?) the DNS Flag Day of 2/1/19 - BIND won’t 
retry (with EDNS disabled) non-answered EDNS queries - rather it will consider 
them failures ?

I see that as of now there is this knob:

--
server a.b.c.d {
edns no;
};
—

But I’m talking about the behavior described in the DNS Flag day materials.  Is 
that simply going to be changed in code sometime around/on 2/1/19 ?

--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
0641 D285 A36F 533A 73E5  2541 4920 533C C616 703A
"For thousands of years men dreamed of pacts with demons.
Only now are such things possible."



signature.asc
Description: Message signed with OpenPGP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Questions about delegation

[Cathy Almond]

Hi Bob(s),

All good so far.

It doesn't matter whether the authoritative servers for the delegated
subdomain are in the parent or the delegated zone.  (Actually, they
could be somewhere completely different - and if they are, it just needs
to be possible for recursive servers following the delegation to be able
resolve them - don't put their A and  RRs into the parent zone).

Either way, the delegation NS records need to exist in the parent zone
(this has to happen, even if the parent is also delegating to itself).

Glue is needed to solve the 'chicken and egg' problem - so if you're
delegating a child zone to nameservers that are in the child zone
themselves, then you need glue in the parent.  (If the nameservers
you're delegating to have names in the parent zone, then you're going to
have their A and  RRsets in the parent zone anyway).



While you're setting this up...

What also matters is that the responses from the delegated servers for
the delegated zone are consistent with the delegation.  This is
sometimes misunderstood or overlooked in GTM configurations and then
causes problems later for resolvers.  Make sure that:

1.  The GTMs are configured to respond with an SOA RR and NS RRset that
is for the zone that has been delegated to them, not the parent zone (a
commonly-seen pitfall that causes client resolution failures because
this is a lame delegation.

2.  The GTMs are configured to respond with NS RRs that are the names
that you delegated from the parent (and that those names can be
resolved) - this is just basic DNS sanity stuff, and although DNS can be
quite accommodating when it's not, it's best to get it consistent.

3.  Don't overlook that the GTMs will need to answer queries for 
and any other record types - as in, they need to be authoritative for
the entire delegated zone, not just proxying the RRs that they 'know'
about.  This means responding with 'no answer no error' for a name that
exists as an A record when queried for the  record instead, and
similar scenarios.  So make sure that the GTMs are fully and correctly
configured.

4.  If you've delegated across an intermediate zone (e.g. from
example.com to zone1.my.example.com) you need to make sure that queries
for anything in my.example.com are handled correctly - that is, that the
servers for example.com reply with 'no answer no error'.

Why?  Because my.example.com implicitly exists as a name, but is empty -
has no RRs and responding NXDOMAIN will cause problems for
zone1.my.example.com.

(This scenario is typically encountered by validating resolvers querying
for DS RRsets which live in the parent zone; they are queried-for by
validators, even if the responses they're validating aren't signed.
This is to check that the parent doesn't 'say' that the child zone
should be signed, in which case receiving unsigned query responses from
the child zone's servers is a DNSSEC-validation failure).

-

The null forwarders you wouldn't ordinarily need, unless the parent zone
server is a mixed-mode resolver/auth server with global forwarding from
which you've delegated the subdomain.  In that case, if you don't want
your recursive client queries to follow the global forwarding when you
resolve them, but to use the delegation instead, then you need null
forwarders set-up.

Info here: https://kb.isc.org/docs/aa-00538

Cathy
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Questions about delegation

[Bob Harold]

On Wed, Dec 19, 2018 at 10:51 AM Bob McDonald  wrote:

> I have a DNS server that serves a zone for domain example.org.
> That DNS server lives at 192.0.2.53
> As part of hosting that domain, a child domain is delegated. (
> gtm-int.example.org.)
> There are two NS records as follows:
> gtm-int.example.org. IN NS gtm-int-east.example.org.
> gtm-int.example.org. IN NS gtm-int-west.example.org.
> gtm-int-east.example.org. IN A 203.0.113.53
> gtm-int-west.example.org. IN A 198.51.100.53
> (and yes, in this case the delegated child domain lives on two F5 GTMs)
>
> The devices hosting the delegated child domain both contain NS records
> which match the parent's NS records for the child domain and they contain
> glue records which also match the parent's A records for the NS records.
>
> Here are my curiosities:
>
> 1) should the NS records for the delegated child domain be hosts which
> reside in the parent domain or the delegated child domain? (or does it
> matter as long as the glue is correct?)
> gtm-int.example.org. IN NS gtm-int-east.example.org.
> gtm-int.example.org. IN NS gtm-int-west.example.org.
> gtm-int-east.example.org. IN A 203.0.113.53
> gtm-int-west.example.org. IN A 198.51.100.53
> -OR-
> gtm-int.example.org. IN NS gtm-int-east.gtm-int.example.org
> .
> gtm-int.example.org. IN NS gtm-int-west.gtm-int.example.org
> .
> gtm-int-east.gtm-int.example.org . IN A
> 203.0.113.53
> gtm-int-west.gtm-int.example.org . IN A
> 198.51.100.53
>
> 2) Do I need to specify a null forwarder statement for the parent domain?
> (to prevent query forwarding to the delegated child domain)
>
> Regards,
>
> Bob
>

If I get this wrong, someone will correct me.  But as I understand it...

1. Your choice.  Glue is needed if the servers are in the child zone.

2. No.  I don't know what a "null" forwarder statement is, but your F5's
are acting as Authoritative DNS servers.  Forwarding only applies to DNS
Resolvers, and is only used if you don't want the resolver to follow the NS
records (like when firewalls are in the way).

-- 
Bob Harold
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Red Hat BIND Security Advisory CVE-2018-5742

[Cathy Almond]

https://access.redhat.com/security/cve/cve-2018-5742

FYI and just to clarify, Red Hat Security Advisory CVE-2018-5742 does
not exist in any version of BIND available directly from ISC; it is
present solely in the version(s) identified by Red Hat in their own
distribution(s).

The problem was accidentally introduced during a backport of the NTA
(Negative Trust Anchor) feature from ISC BIND 9.11.

Both Red Hat and CentOS have BIND distributions that are affected.

The associated defect reports can be found here:

https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-5742

https://bugs.centos.org/view.php?id=15528

For anyone who would like to take this opportunity to migrate to a
supported ISC version of BIND, please see our downloads page:

https://www.isc.org/downloads/

We realise that for many, access to packaged versions of BIND 9 is the
reason that they chose to run the version of BIND offered by their OS
platform rather than building their own.  You might be interested to
hear that we're working on providing packaged builds of ISC BIND for
some platforms.  Details here:

https://www.isc.org/blogs/bind-9-packages/

For a comparison of feature availability in different versions of BIND
from ISC, see:

https://kb.isc.org/docs/aa-01310

(Please also note that BIND 9.9 and 9.10 from ISC are now EOL).

Cathy Almond
ISC Support
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Questions about delegation

[Bob McDonald]

I have a DNS server that serves a zone for domain example.org.
That DNS server lives at 192.0.2.53
As part of hosting that domain, a child domain is delegated. (
gtm-int.example.org.)
There are two NS records as follows:
gtm-int.example.org. IN NS gtm-int-east.example.org.
gtm-int.example.org. IN NS gtm-int-west.example.org.
gtm-int-east.example.org. IN A 203.0.113.53
gtm-int-west.example.org. IN A 198.51.100.53
(and yes, in this case the delegated child domain lives on two F5 GTMs)

The devices hosting the delegated child domain both contain NS records
which match the parent's NS records for the child domain and they contain
glue records which also match the parent's A records for the NS records.

Here are my curiosities:

1) should the NS records for the delegated child domain be hosts which
reside in the parent domain or the delegated child domain? (or does it
matter as long as the glue is correct?)
gtm-int.example.org. IN NS gtm-int-east.example.org.
gtm-int.example.org. IN NS gtm-int-west.example.org.
gtm-int-east.example.org. IN A 203.0.113.53
gtm-int-west.example.org. IN A 198.51.100.53
-OR-
gtm-int.example.org. IN NS gtm-int-east.gtm-int.example.org
.
gtm-int.example.org. IN NS gtm-int-west.gtm-int.example.org
.
gtm-int-east.gtm-int.example.org . IN A
203.0.113.53
gtm-int-west.gtm-int.example.org . IN A
198.51.100.53

2) Do I need to specify a null forwarder statement for the parent domain?
(to prevent query forwarding to the delegated child domain)

Regards,

Bob
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND and persistent connections

[Tony Finch]

Browne, Stuart via bind-users  wrote:
>
> I was wondering if anybody had any thoughts on how to limit the
> concurrency or at least the lifetime of these persistent connections
> within BIND.

If you are running BIND 9.12, you have a bunch of new options related to
RFC 7827 EDNS TCP keepalive (see below for examples). The timeouts default
to 30 seconds (same as before the options were added). They also affect
connections that don't use the EDNS keepalive option.

I have reduced mine, mainly to reduce the concurrency used by Android
DNS-over-TLS. (I'm using nginx as a DoT proxy so there's one back-end TCP
connection per client TLS connection.)

tcp-idle-timeout 50; # 5 seconds
tcp-initial-timeout 25; # 2.5s minimum permitted
tcp-keepalive-timeout 50; # 5 seconds
tcp-advertised-timeout 50; # 5 seconds

Excessive concurrency is still a problem.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Viking, North Utsire, South Utsire: Southeasterly 6 to gale 8, occasionally
severe gale 9 at first. Very rough or high, becoming rough later. Rain then
showers. Good occasionally poor at first.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users