Re: DNSSEC validation failures for www.hrsa.gov

[Jay Ford]

On Sat, 25 Jun 2016, Mark Andrews wrote:

The servers for webfarm.dr.hrsa.gov are not EDNS and DNSSEC compliant.
They are returning FORMERR to queries with EDNS options.  Unknown
EDNS options are supposed to be ignored (RFC 6891).

You can workaround this with a server clause to disable sending the
cookie option with a server clause.

server  { request-sit no; }; // 9.10.x
server  { send-cookie no; }; // 9.11.x


That did it, at least for now.


Now one could argue that FORMERR is legal under RFC 2671 (the initial
EDNS specification) as no options were defined and to use a option
you need to bump the EDNS version but the servers don't do EDNS
version negotiation either as they return FORMERR to a EDNS version 1
query rather than BADVERS.  They also incorrectly copy back unknown
EDNS flags.



Whether this is the cause of your issue I don't know but it won't be
helping.


The HRSA folks claim that their "site is fine".  In hopes of disabusing them 
of that notion I'll have our folks who have to try to use the HRSA site pass 
along the trouble report.


Thanks for the diagnosis & work-around.  Excellent as always & crazy fast, 
too!



Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-f...@uiowa.edu, phone: 319-335-
___
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: DNSSEC validation failures for www.hrsa.gov

[Mark Andrews]

The servers for webfarm.dr.hrsa.gov are not EDNS and DNSSEC compliant.
They are returning FORMERR to queries with EDNS options.  Unknown
EDNS options are supposed to be ignored (RFC 6891).

You can workaround this with a server clause to disable sending the
cookie option with a server clause.

server  { request-sit no; };   // 9.10.x
server  { send-cookie no; };   // 9.11.x

Now one could argue that FORMERR is legal under RFC 2671 (the initial
EDNS specification) as no options were defined and to use a option
you need to bump the EDNS version but the servers don't do EDNS
version negotiation either as they return FORMERR to a EDNS version 1
query rather than BADVERS.  They also incorrectly copy back unknown
EDNS flags.

; <<>> DiG 9.11.0a3 <<>> webfarm.dr.hrsa.gov @ns2.hrsa.gov +edns=1 +noednsneg 
+nocookie +noad +norec +qr
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59618
;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 1, flags:; udp: 4096
;; QUESTION SECTION:
;webfarm.dr.hrsa.gov.   IN  A

;; QUERY SIZE: 48

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 59618
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 1, flags:; udp: 4096
;; QUESTION SECTION:
;webfarm.dr.hrsa.gov.   IN  A

;; Query time: 313 msec
;; SERVER: 162.99.248.222#53(162.99.248.222)
;; WHEN: Sat Jun 25 11:18:55 EST 2016
;; MSG SIZE  rcvd: 48

Whether this is the cause of your issue I don't know but it won't be
helping.

Mark

In message , Jay For
d writes:
> I'm getting DNSSEC validation failures by BIND 9.10.4-P1 for www.hrsa.gov.
> 
> The pertinent log messages are things like:
> 
> lame-servers: info: no valid RRSIG resolving 'webfarm.dr.hrsa.gov/DS/IN':
>  165.112.137.222#53
> lame-servers: info: no valid RRSIG resolving 'webfarm.dr.hrsa.gov/DS/IN':
>  162.99.248.222#53
> lame-servers: info: no valid DS resolving 'webfarm.dr.hrsa.gov/A/IN': 162
> .99.248.222#53
> lame-servers: info: broken trust chain resolving 'webfarm.dr.hrsa.gov/A/I
> N': 165.112.137.222#53
> lame-servers: info: insecurity proof failed resolving 'dr.hrsa.gov/SOA/IN
> ': 162.99.248.222#53
> lame-servers: info: insecurity proof failed resolving 'dr.hrsa.gov/SOA/IN
> ': 165.112.137.222#53
> 
> The dig output is:
> 
> $ dig www.hrsa.gov @dns-spare.uiowa.edu
> 
> ; <<>> DiG 9.10.3-P4-Debian <<>> www.hrsa.gov @dns-spare.uiowa.edu
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 42947
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;www.hrsa.gov.  IN  A
> 
> ;; Query time: 103 msec
> ;; SERVER: fd9a:2c75:7d0c:5::2#53(fd9a:2c75:7d0c:5::2)
> ;; WHEN: Fri Jun 24 18:49:06 CDT 2016
> ;; MSG SIZE  rcvd: 41
> 
> It doesn't fail with a similar config on 9.10.3-P4, but there are admittedly 
> config differences.
> 
> Other DNSSEC-signed things validate fine at both versions, so things are
> mostly OK.
> 
> My guess is that BIND 9.10.4-P1 is checking something more stringently than
> previous versions did, & that something is broken with the DNS for
> www.hrsa.gov, but I can't spot what it is.  There are some very short TTLs (5
> seconds) in the data tree in question, including for SOAs, which seems like a
> really bad idea but I'm not sure it definitely breaks things.  There are also
> some answers with both "AA" & "AD" set, which seems odd, but again, not
> definitely broken.
> 
> dnsviz.net reports a couple of warnings, including a non-AA answer from
> authoritative servers, but it doesn't say it's bogus.
> 
> If anybody can spot something broken for www.hrsa.gov, I'd be very glad to
> hear about it.
> 
> 
> Jay Ford, Network Engineering Group, Information Technology Services
> University of Iowa, Iowa City, IA 52242
> email: jay-f...@uiowa.edu, phone: 319-335-
> ___
> 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

DNSSEC validation failures for www.hrsa.gov

[Jay Ford]

I'm getting DNSSEC validation failures by BIND 9.10.4-P1 for www.hrsa.gov.

The pertinent log messages are things like:

   lame-servers: info: no valid RRSIG resolving 'webfarm.dr.hrsa.gov/DS/IN': 
165.112.137.222#53
   lame-servers: info: no valid RRSIG resolving 'webfarm.dr.hrsa.gov/DS/IN': 
162.99.248.222#53
   lame-servers: info: no valid DS resolving 'webfarm.dr.hrsa.gov/A/IN': 
162.99.248.222#53
   lame-servers: info: broken trust chain resolving 'webfarm.dr.hrsa.gov/A/IN': 
165.112.137.222#53
   lame-servers: info: insecurity proof failed resolving 'dr.hrsa.gov/SOA/IN': 
162.99.248.222#53
   lame-servers: info: insecurity proof failed resolving 'dr.hrsa.gov/SOA/IN': 
165.112.137.222#53

The dig output is:

   $ dig www.hrsa.gov @dns-spare.uiowa.edu

   ; <<>> DiG 9.10.3-P4-Debian <<>> www.hrsa.gov @dns-spare.uiowa.edu
   ;; global options: +cmd
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 42947
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

   ;; OPT PSEUDOSECTION:
   ; EDNS: version: 0, flags:; udp: 4096
   ;; QUESTION SECTION:
   ;www.hrsa.gov.  IN  A

   ;; Query time: 103 msec
   ;; SERVER: fd9a:2c75:7d0c:5::2#53(fd9a:2c75:7d0c:5::2)
   ;; WHEN: Fri Jun 24 18:49:06 CDT 2016
   ;; MSG SIZE  rcvd: 41

It doesn't fail with a similar config on 9.10.3-P4, but there are admittedly 
config differences.


Other DNSSEC-signed things validate fine at both versions, so things are
mostly OK.

My guess is that BIND 9.10.4-P1 is checking something more stringently than
previous versions did, & that something is broken with the DNS for
www.hrsa.gov, but I can't spot what it is.  There are some very short TTLs (5
seconds) in the data tree in question, including for SOAs, which seems like a
really bad idea but I'm not sure it definitely breaks things.  There are also
some answers with both "AA" & "AD" set, which seems odd, but again, not
definitely broken.

dnsviz.net reports a couple of warnings, including a non-AA answer from
authoritative servers, but it doesn't say it's bogus.

If anybody can spot something broken for www.hrsa.gov, I'd be very glad to
hear about it.


Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-f...@uiowa.edu, phone: 319-335-
___
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: Testing

[Bill Christensen]

Polo

On 6/24/16 6:29 PM, John W. Blue wrote:

Marco

Sent from Nine 

*From:* Dan Mahoney 
*Sent:* Jun 24, 2016 6:28 PM
*To:* bind-us...@isc.org
*Subject:* Testing

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


___
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



--
Bill Christensen
http://SustainableSources.com
http://LinkedIn.com/in/billc108

___
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

Testing SMTP

[Dan Mahoney]

Sorry for the noise, please ignore.

-Dan Mahoney
ISC Ops team
___
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

Testing

[Dan Mahoney]

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