Google’s servers don’t add EDNS options to the queries they make so they don’t
see the bogus BADVERS response from the servers.
BADVERS should never be returned to a EDNS version 0 query but these servers do
when the see a EDNS option. There are also other servers that return BADVERS to
any ED
On 27 January 2018 at 19:11, Matthew Pounsett wrote:
> The only thing I can think of that has changed in that time, which has
> ever caused me query issues, is the addition of DNS cookies in the default
> query. Some broken authoritative servers will incorrectly respond with
> things like FORMER
On 27 January 2018 at 16:24, NNEX Support wrote:
> Good thought but no luck, it doesn’t matter how many times I run “dig txt
> rs.dns-oarc.net” or how long I wait it continues to SERVFAIL until I run
> "dig txt rs.dns-oarc.net +trace" Interestingly I've found that running
> "dig txt dns-oarc.net
On 1/27/18 2:47 PM, Rob Sargent wrote:
> you should probably also add these so usitc.gov and sss.gov won’t fail if
> they fail for you:
>
> server 63.150.72.5 { send-cookie no; }; # sauthns1.qwest.net
> server 208.44.130.121 { send-cookie no; }; # sauthns2.qwest.net.
Done, thx.
On 1/27/18 1:36 PM, Rob Sargent wrote:
Just for grins, try adding these lines to your named.conf file [within the
appropriate view] to see if that fixes it. I had to add something like it to
get usitc.gov working for my customers:
server 152.216.7.164 { send-cookie no; }; # ns1.irs.go
Good thought but no luck, it doesn’t matter how many times I run “dig txt
rs.dns-oarc.net” or how long I wait it continues to SERVFAIL until I run "dig
txt rs.dns-oarc.net +trace" Interestingly I've found that running "dig txt
dns-oarc.net +trace" isn't enough to fix it, I actually have to run "
On 1/27/18, PGNet Dev wrote:
> On 1/27/18 11:33 AM, Lee wrote:
>> On 1/27/18, PGNet Dev wrote:
>>> I've a local bind 9.12.0 server. Works for virtually all domains.
>>>
>>> For "irs.gov", it fails,
>>
>> works for me on a local bind 9.11.2 server:
>> $ dig a irs.gov.
>
> Do you any of
>
> // for
On 26 January 2018 at 16:23, NNEX Support wrote:
> I'm sure I'm doing something wrong, but for the life of me I can't figure
> out what. I'm running named 9.12 in a simple recursive setup (built from
> source on CentOS 7).
>
>
[...]
> When I try to run "dig txt rs.dns-oarc.net" I get SERVFAIL.
On 1/27/18 11:33 AM, Lee wrote:
On 1/27/18, PGNet Dev wrote:
I've a local bind 9.12.0 server. Works for virtually all domains.
For "irs.gov", it fails,
works for me on a local bind 9.11.2 server:
$ dig a irs.gov.
Do you any of
// forward first;
// forward only;
// forwarders {
set in yo
On 1/27/18, PGNet Dev wrote:
> I've a local bind 9.12.0 server. Works for virtually all domains.
>
> For "irs.gov", it fails,
works for me on a local bind 9.11.2 server:
$ dig a irs.gov.
; <<>> DiG 9.11.2 <<>> a irs.gov.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, stat
> Works for me, try figuring out if you have a routing problem getting to
> ns[1234].irs.gov.
Hm.
I've traceroute'd from my local network, & from 2 separate VPNs. I.e.,
disparate, unrelated nets.
All 3 fail at the same points. E.g.
at qwest.net,
traceroute to ns1.irs.gov (152.216
I've a local bind 9.12.0 server. Works for virtually all domains.
For "irs.gov", it fails,
dig A irs.gov
; <<>> DiG 9.12.0 <<>> A irs.gov
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAI
12 matches
Mail list logo
