date:20100316

DNSSEC Validating Resolver and Views

2010-03-16 Thread John Marshall

Context: BIND 9.7.0

I have made use of views on a single server for providing
suitable/selective responses to internal, external and guest clients.
This setup has been working for years but is now broken for clients
querying from a guest network (via the guest view) unless the queries
have checking disabled.

- The guest network is not local to the server.
- Internal view and guest view clients are allowed recursion.
- The breakage only relates to queries for internal zones from guest
clients.
- Queries for internal zones from (local) internal clients are fine.
- In the guest view, queries for most zones are forwarded to the
server's internal address (internal view) but queries for some
zones are forwarded to the server's external address (external view)
- The name servers for all of the internal zones live in an internal
signed zone. That zone is visible to the guest and internal views
and its key is listed in trusted-keys{}.
- The zones being queried (below) are unsigned.

Client: 192.168.25.71 is querying the PTR record for its own address.
Server: 172.25.24.16 is querying itself for the DS record for the
parent of the zone which the client is querying (Why?).
There is no DS record in that zone. Neither the child or
parent zones are signed.

16-Mar-2010 18:15:34.761 query-errors: debug 1: client 172.25.24.16#62578: view
internal: query failed (SERVFAIL) for 168.192.in-addr.arpa/IN/DS at query.c:4631
16-Mar-2010 18:15:34.761 query-errors: debug 2: fetch completed at
resolver.c:6117 for 168.192.in-addr.arpa/DS in 1.358282: SERVFAIL/success
[domain:168.192.in-addr.arpa,referral:0,restart:1,qrysent:1,timeout:0,lame:0,neterr:0,badresp:1,adberr:0,findfail:0,valfail:0]
16-Mar-2010 18:15:34.761 query-errors: debug 1: client 192.168.25.71#43718:
view guest: query failed (SERVFAIL) for 71.25.168.192.in-addr.arpa/IN/PTR at
query.c:4631
16-Mar-2010 18:15:34.762 query-errors: debug 2: fetch completed at
resolver.c:3023 for 71.25.168.192.in-addr.arpa/PTR in 2.342775: failure/no
valid DS
[domain:25.168.192.in-addr.arpa,referral:0,restart:2,qrysent:1,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:1]

Is the problem due to the fact that the name servers live in a signed
zone? This view configuration has worked for years. I configured
DNSSEC on the server about 18 months ago. I guess I've just been lucky?

Again, these queries still work fine with +cd passed to dig, so I'm
obviously missing something with respect to DNSSEC configuration. I
only just noticed this today (we don't use the guest network much) so I
don't know whether this problem surfaced with 9.7.0 or DNSSEC things
happening higher up.

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

Dealing with "unexpected RCODE (SERVFAIL)"

2010-03-16 Thread Ruben Laban

Hello list,

In my logs I see numerous line like these:

Mar 16 04:59:13 mx02 named[4606]: unexpected RCODE (SERVFAIL) 
resolving 'hotmeil.com/MX/IN': 10.2.1.3#53
Mar 16 04:59:14 mx02 named[4606]: unexpected RCODE (SERVFAIL) 
resolving 'hotmeil.com/MX/IN': 10.0.1.3#53
Mar 16 04:59:15 mx02 named[4606]: unexpected RCODE (SERVFAIL) 
resolving 'hotmeil.com/MX/IN': 10.1.1.3#53

The hostname that's being tried to resolve obviously has a typo in it, users 
tend to make such mistakes a lot.

In our case mx02 runs it own caching nameserver, which uses our internal 
caching nameservers (10,[012].1.3) as forwarders.

Is there something I can change in the configuration of either (or both) mx02 
or 10.[012].1.3 to prevent "the unexpected"?

Is it safe to ignore these error completely (either in our filters or in 
bind's configuration)? I'm a bit hesitant to do so, since I got the feeling 
that I might miss out on actual problems occuring (other than users not being 
able to spell).

I google'd around several times, but could never find any useful information 
on this subject.
-- 
Regards,

Ruben Laban
Senior Systems and Network Administrator
ISM eCompany
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Dealing with "unexpected RCODE (SERVFAIL)"

2010-03-16 Thread Matus UHLAR - fantomas

On 16.03.10 09:45, Ruben Laban wrote:
> In my logs I see numerous line like these:
> 
> Mar 16 04:59:13 mx02 named[4606]: unexpected RCODE (SERVFAIL) 
> resolving 'hotmeil.com/MX/IN': 10.2.1.3#53
> Mar 16 04:59:14 mx02 named[4606]: unexpected RCODE (SERVFAIL) 
> resolving 'hotmeil.com/MX/IN': 10.0.1.3#53
> Mar 16 04:59:15 mx02 named[4606]: unexpected RCODE (SERVFAIL) 
> resolving 'hotmeil.com/MX/IN': 10.1.1.3#53
> 
> The hostname that's being tried to resolve obviously has a typo in it, users 
> tend to make such mistakes a lot.
> 
> In our case mx02 runs it own caching nameserver, which uses our internal 
> caching nameservers (10,[012].1.3) as forwarders.
> 
> Is there something I can change in the configuration of either (or both) mx02 
> or 10.[012].1.3 to prevent "the unexpected"?

the microsoft's nameservers are providing only A and TXT records for
hotmeil.com. They return ". IN SOA (NOERROR)" for other questions.
This is apparently invalid and causes the SERVFAIL.

seems it's time to blame microsoft.

> Is it safe to ignore these error completely (either in our filters or in 
> bind's configuration)? I'm a bit hesitant to do so, since I got the feeling 
> that I might miss out on actual problems occuring (other than users not being 
> able to spell).

you can ignore it or set up own empty version of hotemil.com. Or, fill bug
in their reporting system.

-- 
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I intend to live forever - so far so good. 
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC Validating Resolver and Views

2010-03-16 Thread John Marshall

On Tue, 16 Mar 2010 08:14:40 + (UTC), John Marshall wrote:
>
> Client: 192.168.25.71 is querying the PTR record for its own address.
> Server: 172.25.24.16 is querying itself for the DS record for the
>   parent of the zone which the client is querying (Why?).
> There is no DS record in that zone.  Neither the child or
> parent zones are signed.
>
> 16-Mar-2010 18:15:34.761 query-errors: debug 1: client 172.25.24.16#62578: 
> view internal: query failed (SERVFAIL) for 168.192.in-addr.arpa/IN/DS at 
> query.c:4631
> 16-Mar-2010 18:15:34.761 query-errors: debug 2: fetch completed at 
> resolver.c:6117 for 168.192.in-addr.arpa/DS in 1.358282: SERVFAIL/success 
> [domain:168.192.in-addr.arpa,referral:0,restart:1,qrysent:1,timeout:0,lame:0,neterr:0,badresp:1,adberr:0,findfail:0,valfail:0]
> 16-Mar-2010 18:15:34.761 query-errors: debug 1: client 192.168.25.71#43718: 
> view guest: query failed (SERVFAIL) for 71.25.168.192.in-addr.arpa/IN/PTR at 
> query.c:4631
> 16-Mar-2010 18:15:34.762 query-errors: debug 2: fetch completed at 
> resolver.c:3023 for 71.25.168.192.in-addr.arpa/PTR in 2.342775: failure/no 
> valid DS 
> [domain:25.168.192.in-addr.arpa,referral:0,restart:2,qrysent:1,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:1]

I should have checked syslog before posting.  It shows this going on at
the same time...

Mar 16 18:15:33 rwsrv03 named[679]: error (chase DS servers) resolving 
'168.192.in-addr.arpa/DS/IN': 172.25.24.17#53
Mar 16 18:15:33 rwsrv03 named[679]: error (no valid RRSIG) resolving 
'192.in-addr.arpa/NS/IN': 204.61.216.50#53
Mar 16 18:15:33 rwsrv03 named[679]: error (no valid RRSIG) resolving 
'192.in-addr.arpa/NS/IN': 192.35.51.32#53
Mar 16 18:15:34 rwsrv03 named[679]: error (no valid RRSIG) resolving 
'192.in-addr.arpa/NS/IN': 199.212.0.63#53
Mar 16 18:15:34 rwsrv03 named[679]: error (no valid RRSIG) resolving 
'192.in-addr.arpa/NS/IN': 199.71.0.63#53
Mar 16 18:15:34 rwsrv03 named[679]: error (no valid RRSIG) resolving 
'192.in-addr.arpa/NS/IN': 192.42.93.32#53
Mar 16 18:15:34 rwsrv03 named[679]: error (no valid RRSIG) resolving 
'192.in-addr.arpa/NS/IN': 63.243.194.2#53
Mar 16 18:15:34 rwsrv03 named[679]: error (no valid RRSIG) resolving 
'192.in-addr.arpa/NS/IN': 72.52.71.2#53
Mar 16 18:15:34 rwsrv03 named[679]: error (no valid DS) resolving 
'71.25.168.192.in-addr.arpa/PTR/IN': 172.25.24.16#53

I don't understand this.  If the client needs an answer from
25.168.192.in-addr.arpa. and we are hosting that zone and its parent
zone (both unsigned, both in our internal view), why are we looking
higher for DS records?

If I grant the guest clients access to the internal view, all is well.
Things seem to go wobbly, unless checking is disabled, when we forward
the guest view queries to the internal view.

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

41 matches

Mail list logo