Re: 9.11 can't validate sss.gov
On 01/22/2018 09:21 AM, Warren Kumari wrote: http://www.sss.gov works OK, but http://sss.gov always seems to return "The requested service is temporarily unavailable. It is either overloaded or under maintenance. Please try later.". Inconsistency between related things is annoying. I guess props for consistently returning different things. There is a fair bit os disagreement over if a bare domain should resolve / have a web-server listening, but ISTM that if you do, you should have it work I agree that this (at the very least) violates (what I consider to be) reasonable expectation and surprises users. I'm of the opinion that if you have www.sss.gov and sss.gov, that they should behave in very similar and related ways. - My personal preference would be for sss.gov to 30[1267] redirect to www.sss.gov. Ideally any non-HTTPS to HTTPS. I wonder how many people have tried the bare domain and never realized that adding in the 'www' "fixes" it. I expect that there are a lot more than we may think. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic 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: 9.11 can't validate sss.gov
Unrelated to the DNS bit, but still silly / annoying: http://www.sss.gov works OK, but http://sss.gov always seems to return "The requested service is temporarily unavailable. It is either overloaded or under maintenance. Please try later.". There is a fair bit os disagreement over if a bare domain should resolve / have a web-server listening, but ISTM that if you *do*, you should have it work -- I wonder how many people have tried the bare domain and never realized that adding in the 'www' "fixes" it. W On Mon, Jan 22, 2018 at 11:08 AM, Timothy A. Holtzen wrote: > I've informed the selective service (sss.gov) of the issue. They have > supposedly passed it on to their "web support group". We will see if > anything happens but I'm not holding my breath. At least a government > agency should have more influence to get qwest to fix their servers than > I do. > > Timothy A. Holtzen > Campus Network Administrator > Nebraska Wesleyan University > Public PGP key CFB4 3AE8 B726 DEBF 00D9 CCFC 426E 76AF DABC B3D7 > > > On 01/19/2018 05:04 PM, Mark Andrews wrote: >> Yes, qwest were informed years ago that there severs are broken. Report this >> to the .gov site operators. The servers return BADVERS to the queries which >> was never part of the EDNS spec and is a invention of the servers >> developers. FORMERR was permissible by STD13 but this was tightened when >> the EDNS spec was revised to say ignore unknown EDNS options. >> > > > > ___ > 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 -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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: 9.11 can't validate sss.gov
I've informed the selective service (sss.gov) of the issue. They have supposedly passed it on to their "web support group". We will see if anything happens but I'm not holding my breath. At least a government agency should have more influence to get qwest to fix their servers than I do. Timothy A. Holtzen Campus Network Administrator Nebraska Wesleyan University Public PGP key CFB4 3AE8 B726 DEBF 00D9 CCFC 426E 76AF DABC B3D7 On 01/19/2018 05:04 PM, Mark Andrews wrote: > Yes, qwest were informed years ago that there severs are broken. Report this > to the .gov site operators. The servers return BADVERS to the queries which > was never part of the EDNS spec and is a invention of the servers developers. > FORMERR was permissible by STD13 but this was tightened when the EDNS spec > was revised to say ignore unknown EDNS options. > 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: 9.11 can't validate sss.gov
Yes, qwest were informed years ago that there severs are broken. Report this to
the .gov site operators. The servers return BADVERS to the queries which was
never part of the EDNS spec and is a invention of the servers developers.
FORMERR was permissible by STD13 but this was tightened when the EDNS spec was
revised to say ignore unknown EDNS options.
--
Mark Andrews
> On 20 Jan 2018, at 03:39, Tony Finch wrote:
>
> Timothy A. Holtzen wrote:
>
>> I've run into an odd problem. On the same host with nearly identical
>> configurations. Bind 9.10.6 can resolve and DNSSEC validate sss.gov but
>> Bind 9.11.2 cannot.
>
> Ah, this is because sss.gov is hosted on Qwest's DNS servers that have
> broken EDNS logic which is incompatible with DNS cookies.
>
> I have a short script (quoted below) which generates a blacklist of broken
> servers which is included in my `named.conf`.
>
> The number of problem reports I've received is mercifully small - Qwest
> are the worst cookie offenders.
>
>
>
> #!/bin/sh
>
> set -eu
>
> noedns=roles/named/files/named.conf.noedns
>
> : >$noedns
>
> # qwest - bea.gov
> # barclays - myapplication.international.barclays.com
>
> for s insauthns1.qwest.net. \
>sauthns2.qwest.net. \
>ns21.barclays.com. \
>ns22.barclays.net. \
>ns23.barclays.com. \
>ns24.barclays.net.
> do
>dig +noall +nottl +noclass +answer $s a $s
> done |
> sort |
> while read s t a
> do echo "server $a { send-cookie no; }; # $s"
> done>>$noedns
>
>
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode
> Hebrides, Bailey, Fair Isle, Faeroes, Southeast Iceland: Cyclonic 4 or 5,
> occasionally 6 in Hebrides, Bailey and Southeast Iceland. Moderate or rough,
> occasionally very rough in Hebrides and Bailey. Wintry showers. Good,
> occasionally poor.
> ___
> 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
Re: 9.11 can't validate sss.gov
Timothy A. Holtzen wrote:
> I've run into an odd problem. On the same host with nearly identical
> configurations. Bind 9.10.6 can resolve and DNSSEC validate sss.gov but
> Bind 9.11.2 cannot.
Ah, this is because sss.gov is hosted on Qwest's DNS servers that have
broken EDNS logic which is incompatible with DNS cookies.
I have a short script (quoted below) which generates a blacklist of broken
servers which is included in my `named.conf`.
The number of problem reports I've received is mercifully small - Qwest
are the worst cookie offenders.
#!/bin/sh
set -eu
noedns=roles/named/files/named.conf.noedns
: >$noedns
# qwest - bea.gov
# barclays - myapplication.international.barclays.com
for s insauthns1.qwest.net. \
sauthns2.qwest.net. \
ns21.barclays.com. \
ns22.barclays.net. \
ns23.barclays.com. \
ns24.barclays.net.
do
dig +noall +nottl +noclass +answer $s a $s
done |
sort |
while read s t a
do echo "server $a { send-cookie no; }; # $s"
done>>$noedns
Tony.
--
f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode
Hebrides, Bailey, Fair Isle, Faeroes, Southeast Iceland: Cyclonic 4 or 5,
occasionally 6 in Hebrides, Bailey and Southeast Iceland. Moderate or rough,
occasionally very rough in Hebrides and Bailey. Wintry showers. Good,
occasionally poor.___
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
9.11 can't validate sss.gov
I've run into an odd problem. On the same host with nearly identical configurations. Bind 9.10.6 can resolve and DNSSEC validate sss.gov but Bind 9.11.2 cannot. If I turn off DNSSEC validation 9.11.2 resolves it just fine. According to http://dnsviz.net/d/sss.gov/dnssec/ it looks like the the domain is properly signed and valid. I get the following in the log when validation fails. Jan 19 09:26:20 stout named[11872]: dnssec: debug 3: validating sss.gov/A: starting Jan 19 09:26:20 stout named[11872]: dnssec: debug 3: validating sss.gov/A: attempting insecurity proof Jan 19 09:26:20 stout named[11872]: dnssec: debug 3: validating sss.gov/A: checking existence of DS at 'gov' Jan 19 09:26:20 stout named[11872]: dnssec: debug 3: validating sss.gov/A: checking existence of DS at 'sss.gov' Jan 19 09:26:20 stout named[11872]: dnssec: debug 3: validating sss.gov/A: insecurity proof failed Jan 19 09:26:20 stout named[11872]: validating sss.gov/A: got insecure response; parent indicates it should be secure Jan 19 09:26:20 stout named[11872]: dnssec: info: validating sss.gov/A: got insecure response; parent indicates it should be secure Jan 19 09:26:20 stout named[11872]: insecurity proof failed resolving 'sss.gov/A/IN': 2001:428::7#53 Jan 19 09:26:20 stout named[11872]: client @0x7fa6ec5ef6d0 10.9.2.18#39295 (sss.gov): view internal: query: sss.gov IN A +E(0) (10.1.1.5) Jan 19 09:26:21 stout named[11872]: dnssec: debug 3: validating sss.gov/A: starting Jan 19 09:26:21 stout named[11872]: dnssec: debug 3: validating sss.gov/A: attempting insecurity proof Jan 19 09:26:21 stout named[11872]: dnssec: debug 3: validating sss.gov/A: checking existence of DS at 'gov' Jan 19 09:26:21 stout named[11872]: dnssec: debug 3: validating sss.gov/A: checking existence of DS at 'sss.gov' Jan 19 09:26:21 stout named[11872]: dnssec: debug 3: validating sss.gov/A: insecurity proof failed Jan 19 09:26:21 stout named[11872]: validating sss.gov/A: got insecure response; parent indicates it should be secure Jan 19 09:26:21 stout named[11872]: dnssec: info: validating sss.gov/A: got insecure response; parent indicates it should be secure Jan 19 09:26:21 stout named[11872]: insecurity proof failed resolving 'sss.gov/A/IN': 63.150.72.5#53 Jan 19 09:26:23 stout named[11872]: client @0x7fa725012090 2606:1c00:2802:9::6#40869 (sss.gov): view internal: query failed (SERVFAIL) for sss.gov/IN/A at query.c:8302 Jan 19 09:26:23 stout named[11872]: client @0x7fa728a30e50 10.9.2.18#39295 (sss.gov): view internal: query failed (SERVFAIL) for sss.gov/IN/A at query.c:8302 Oddly enough other signed domains seem to validate correctly. What might have changed between 9.10 and 9.11? I'm guessing that 9.11 is probably more closely requiring some kind of standard conformance and sss.gov is maybe not conforming completely. Any thoughts? It is kind of important for us. As a University we are required to verify that our students are properly registered with the selective service(sss.gov). -- Timothy A. Holtzen Campus Network Administrator Nebraska Wesleyan University Public PGP key CFB4 3AE8 B726 DEBF 00D9 CCFC 426E 76AF DABC B3D7 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
