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
> 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
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
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 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, 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
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 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
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 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 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
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
12 matches
Mail list logo