Re: Problem looking up domain dryfire.com

[Mark Andrews]

In message <9f949ee6-6386-c986-698e-e4a46e6cf...@thelounge.net>, Reindl Harald 
writes:
> Am 16.08.2016 um 11:04 schrieb Eivind Olsen:
> > I'm seeing some odd problems where BIND (9.10.4-P2) has issues resolving
> > getsurfed.com. This is when using the "510 Software Group" BIND 9.10 for
> > RHEL/CentOS/Fedora.
>
> why do you use a 3rd party package?
>
> no problem here with bind-9.10.4-1.P2.fc24.x86_64 from the Fedora repos

Presumably bind-9.10.4-1.P2.fc24.x86_64 doesn't have DNS COOKIE
support enabled or you would be seeing these diagnostic messages.

BIND 9.11 has DNS COOKIE support on by default.  DiG also has it
turned on.  If you go to https://ednscomp.isc.org/compliance/summary.html
you can see how authoritative server support is improving for unknown
EDNS options.  That page tracks all EDNS extension methods.

The point of writing RFC's is to avoid issues like this.  RFC 6891
is clear about how a nameserver handles unknown EDNS versions and
unknown EDNS options.  This server doesn't handle either event
properly.  It's predecessor, RFC 2671, was also completely clear
about handling unknown EDNS versions.  One of the changes between
RFC 2671 and RFC 6891 was to clarify unknown EDNS option handling.

ISC has a online EDNS compliance tester .
You can point it at any zone to test how the servers behave.  Below
is the output for dryfire.com.

Mark

Checking: 'dryfire.com' as at 2016-08-19T06:10:51Z

dryfire.com @213.162.97.177 (dns0.getsurfed.com.): dns=ok edns=ok edns1=status 
edns@512=ok ednsopt=status,nosoa edns1opt=status do=ok ednsflags=ok 
edns@512tcp=timeout optlist=status,nosoa
dryfire.com @213.162.97.178 (dns1.getsurfed.com.): dns=ok edns=ok edns1=status 
edns@512=ok ednsopt=status,nosoa edns1opt=status do=ok ednsflags=ok 
edns@512tcp=timeout optlist=status,nosoa

The Following Tests Failed

EDNS - Unknown Version Handling (edns1)

dig +nocookie +norec +noad +edns=1 +noednsneg soa zone @server
expect: BADVERS
expect: OPT record with version set to 0
expect: not to see SOA
See RFC6891, 6.1.3. OPT Record TTL Field Use

EDNS - Unknown Option Handling (ednsopt)

dig +nocookie +norec +noad +ednsopt=100 soa zone @server
expect: SOA
expect: NOERROR
expect: OPT record with version set to 0
expect: that the option will not be present in response
See RFC6891, 6.1.2 Wire Format

EDNS - Unknown Version with Unknown Option Handling (edns1opt)

dig +nocookie +norec +noad +edns=1 +noednsneg +ednsopt=100 soa zone @server
expect: BADVERS
expect: OPT record with version set to 0
expect: not to see SOA
expect: that the option will not be present in response
See RFC6891

EDNS - over TCP Response (edns@512tcp)

dig +vc +nocookie +norec +noad +edns +dnssec +bufsize=512 dnskey zone @server
expect: NOERROR
expect: OPT record with version set to 0
See RFC5966 and See RFC6891

EDNS - Supported Options Probe (optlist)

dig +edns +noad +norec +nsid +subnet=0.0.0.0/0 +expire +cookie -q zone @server
expect: NOERROR
expect: OPT record with version set to 0
See RFC6891

Codes

ok - test passed.
nosoa - SOA record not found when expected.
status - expected rcode status code not found.
timeout - lookup timed out.

To retrieve this report in the future: 
https://ednscomp.isc.org/ednscomp/85c5dc541f

> > I can do manual lookups of the domain with "dig" and point it to their
> > servers (dns0.getsurfed.com, dns1.getsurfed.com) but it fails for me if
> > I go through my BIND installation.
> >
> > The named.run log contains lines like this:
> >
> > 16-Aug-2016 10:48:40.693 lame-servers: info: 17 unexpected RCODE
> > resolving 'dryfire.com/NS/IN': 213.162.97.178#53
> > 16-Aug-2016 10:48:40.749 lame-servers: info: 17 unexpected RCODE
> > resolving 'dryfire.com/NS/IN': 213.162.97.177#53
> >
> > A search for "17 unexpected RCODE" seems to indicate this might be
> > caused by incompatibility between SIT/DNS cookies and older versions of
> > NSD. Is this also what's happening in my case here?
>
> ;; ANSWER SECTION:
> dryfire.com.21600   IN  A   109.109.232.98
>
> ;; ANSWER SECTION:
> dryfire.com.21595   IN  NS  dns0.getsurfed.com.
> dryfire.com.21595   IN  NS  dns1.getsurfed.com.
>
>

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

Re: Problem looking up domain dryfire.com

[Reindl Harald]

Am 16.08.2016 um 11:04 schrieb Eivind Olsen:

I'm seeing some odd problems where BIND (9.10.4-P2) has issues resolving
getsurfed.com. This is when using the "510 Software Group" BIND 9.10 for
RHEL/CentOS/Fedora.


why do you use a 3rd party package?

no problem here with bind-9.10.4-1.P2.fc24.x86_64 from the Fedora repos


I can do manual lookups of the domain with "dig" and point it to their
servers (dns0.getsurfed.com, dns1.getsurfed.com) but it fails for me if
I go through my BIND installation.

The named.run log contains lines like this:

16-Aug-2016 10:48:40.693 lame-servers: info: 17 unexpected RCODE
resolving 'dryfire.com/NS/IN': 213.162.97.178#53
16-Aug-2016 10:48:40.749 lame-servers: info: 17 unexpected RCODE
resolving 'dryfire.com/NS/IN': 213.162.97.177#53

A search for "17 unexpected RCODE" seems to indicate this might be
caused by incompatibility between SIT/DNS cookies and older versions of
NSD. Is this also what's happening in my case here?


;; ANSWER SECTION:
dryfire.com.21600   IN  A   109.109.232.98

;; ANSWER SECTION:
dryfire.com.21595   IN  NS  dns0.getsurfed.com.
dryfire.com.21595   IN  NS  dns1.getsurfed.com.



signature.asc
Description: OpenPGP digital signature
___
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: Problem looking up domain dryfire.com

[Mark Andrews]

The nameservers are broken.  They send back rcode 17 (which is yet
to be assigned) when they see a query with a EDNS option present
rather than ignore the option as required by RFC 6891.  They also
send back RCODE 17 rather than BADVERS (16) when send a EDNS(1)
query.   The servers also don't answer over TCP which is a third issue.

The operators should contact their nameserver vendor for a fix or
otherwise replace them.

EDNS compliance test results for dryfire.com can be found at
https://ednscomp.isc.org/ednscomp/210f3a1e3e

You can work around this in the short term by adding server clauses
for the servers to tell named to not send EDNS COOKIES to them.
This of course does not scale.

server  { request-sit no; };9.10.x
servet  { send-cookie no; };9.11.0 onwards

Mark

; <<>> DiG 9.11.0b3 <<>> +dnssec dryfire.com ns @213.162.97.178
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: ?17, id: 29228
;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; Query time: 440 msec
;; SERVER: 213.162.97.178#53(213.162.97.178)
;; WHEN: Tue Aug 16 20:58:42 EST 2016
;; MSG SIZE  rcvd: 23

; <<>> DiG 9.11.0b3 <<>> +dnssec dryfire.com ns @213.162.97.178 +nocookie
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49671
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;dryfire.com.   IN  NS

;; ANSWER SECTION:
dryfire.com.21600   IN  NS  dns0.getsurfed.com.
dryfire.com.21600   IN  NS  dns1.getsurfed.com.

;; Query time: 367 msec
;; SERVER: 213.162.97.178#53(213.162.97.178)
;; WHEN: Tue Aug 16 20:59:37 EST 2016
;; MSG SIZE  rcvd: 88


; <<>> DiG 9.11.0b3 <<>> +dnssec dryfire.com ns @213.162.97.178 +nocookie 
+edns=1 +noednsneg
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: ?17, id: 8994
;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; Query time: 541 msec
;; SERVER: 213.162.97.178#53(213.162.97.178)
;; WHEN: Tue Aug 16 21:06:13 EST 2016
;; MSG SIZE  rcvd: 23


In message <9634ef8af31f19965c5c3b2db3f98...@gluping.no>, Eivind Olsen writes:
> Hello.
> 
> I'm seeing some odd problems where BIND (9.10.4-P2) has issues resolving 
> getsurfed.com. This is when using the "510 Software Group" BIND 9.10 for 
> RHEL/CentOS/Fedora.
> 
> I can do manual lookups of the domain with "dig" and point it to their 
> servers (dns0.getsurfed.com, dns1.getsurfed.com) but it fails for me if 
> I go through my BIND installation.
> 
> The named.run log contains lines like this:
> 
> 16-Aug-2016 10:48:40.693 lame-servers: info: 17 unexpected RCODE 
> resolving 'dryfire.com/NS/IN': 213.162.97.178#53
> 16-Aug-2016 10:48:40.749 lame-servers: info: 17 unexpected RCODE 
> resolving 'dryfire.com/NS/IN': 213.162.97.177#53
> 
> A search for "17 unexpected RCODE" seems to indicate this might be 
> caused by incompatibility between SIT/DNS cookies and older versions of 
> NSD. Is this also what's happening in my case here?
> 
> Regards
> Eivind Olsen
> ___
> 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

Re: Problem looking up domain dryfire.com

[Mukund Sivaraman]

On Tue, Aug 16, 2016 at 11:04:14AM +0200, Eivind Olsen wrote:
> Hello.
> 
> I'm seeing some odd problems where BIND (9.10.4-P2) has issues resolving
> getsurfed.com. This is when using the "510 Software Group" BIND 9.10 for
> RHEL/CentOS/Fedora.
> 
> I can do manual lookups of the domain with "dig" and point it to their
> servers (dns0.getsurfed.com, dns1.getsurfed.com) but it fails for me if I go
> through my BIND installation.
> 
> The named.run log contains lines like this:
> 
> 16-Aug-2016 10:48:40.693 lame-servers: info: 17 unexpected RCODE resolving
> 'dryfire.com/NS/IN': 213.162.97.178#53
> 16-Aug-2016 10:48:40.749 lame-servers: info: 17 unexpected RCODE resolving
> 'dryfire.com/NS/IN': 213.162.97.177#53
> 
> A search for "17 unexpected RCODE" seems to indicate this might be caused by
> incompatibility between SIT/DNS cookies and older versions of NSD. Is this
> also what's happening in my case here?

Possibly:

[muks@jurassic bind9]$ bin/dig +cookie @dns0.getsurfed.com. getsurfed.com.

; <<>> DiG 9.11.0a3 <<>> +cookie @dns0.getsurfed.com. getsurfed.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: ?17, id: 39495
;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; Query time: 189 msec
;; SERVER: 213.162.97.177#53(213.162.97.177)
;; WHEN: Tue Aug 16 15:50:50 IST 2016
;; MSG SIZE  rcvd: 23

[muks@jurassic bind9]$ bin/dig +nocookie @dns0.getsurfed.com. getsurfed.com.

; <<>> DiG 9.11.0a3 <<>> +nocookie @dns0.getsurfed.com. getsurfed.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38178
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;getsurfed.com. IN  A

;; ANSWER SECTION:
getsurfed.com.  21600   IN  A   213.162.97.82

;; AUTHORITY SECTION:
getsurfed.com.  21600   IN  NS  dns0.getsurfed.com.
getsurfed.com.  21600   IN  NS  dns1.getsurfed.com.

;; ADDITIONAL SECTION:
dns0.getsurfed.com. 3600IN  A   213.162.97.177
dns1.getsurfed.com. 3600IN  A   213.162.97.178

;; Query time: 189 msec
;; SERVER: 213.162.97.177#53(213.162.97.177)
;; WHEN: Tue Aug 16 15:50:52 IST 2016
;; MSG SIZE  rcvd: 128

[muks@jurassic bind9]$ 

Mukund


signature.asc
Description: PGP signature
___
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

Problem looking up domain dryfire.com

[Eivind Olsen]

Hello.

I'm seeing some odd problems where BIND (9.10.4-P2) has issues resolving 
getsurfed.com. This is when using the "510 Software Group" BIND 9.10 for 
RHEL/CentOS/Fedora.


I can do manual lookups of the domain with "dig" and point it to their 
servers (dns0.getsurfed.com, dns1.getsurfed.com) but it fails for me if 
I go through my BIND installation.


The named.run log contains lines like this:

16-Aug-2016 10:48:40.693 lame-servers: info: 17 unexpected RCODE 
resolving 'dryfire.com/NS/IN': 213.162.97.178#53
16-Aug-2016 10:48:40.749 lame-servers: info: 17 unexpected RCODE 
resolving 'dryfire.com/NS/IN': 213.162.97.177#53


A search for "17 unexpected RCODE" seems to indicate this might be 
caused by incompatibility between SIT/DNS cookies and older versions of 
NSD. Is this also what's happening in my case here?


Regards
Eivind Olsen
___
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