0

I know that the authoritative name servers for google.com are ns1-4.google.com.

Now, I do this:

dig google.com @ns1.google.com

And the response is:

; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> google.com @ns1.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64710
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.            IN  A

;; ANSWER SECTION:
google.com.     292 IN  A   172.217.167.174

;; Query time: 1 msec
;; SERVER: 216.239.32.10#53(216.239.32.10)
;; WHEN: Sun Jun 30 12:53:09 IST 2019
;; MSG SIZE  rcvd: 44

Now, as per my understanding, there should be an authoritative bit that should be set in this response, but from the output flags, it seems like there's no authoritative bit set (No aa flags). Moreover, how can recursion be available from an authoritative nameserver (How can there be a ra flag)

I think I'm missing some basic thing here, I'd appreciate some light on the same.

Thanks in advance.

pathfinder
  • 25
  • 1
  • 4

1 Answers1

1

I'm unable to reproduce the behavior described in the question. And yes, can confirm, what you saw shouldn't be like that for an authoritative server.

Could it be that you or your ISP is intercepting all DNS traffic and sending it to local recursive nameservers instead of the intended destination?
Does your observed issue only affect the Google nameservers or all servers?

Alternatively I suppose it is possible that Google had some serious issues, but to me this seems like a very strange failure mode.

Håkan Lindqvist
  • 33,741
  • 5
  • 65
  • 90
  • Hi, seems like this is an issue with my ISP, like you said. This behaviour is the same for all domains, not only with google. Migrating my computer to a different ISP's network produced the intended behaviour. Could you suggest a workaround for this with my original ISP? One approach I can think of is DNS-over-TLS or DNSSEC, I'm not sure. – pathfinder Jun 30 '19 at 11:03
  • @airforceone To query authoritative servers directly (for troubleshooting purposes or to run your own recursive nameserver), the solution that comes to mind would be some VPN or tunneling solution to a network where your DNS traffic is not intercepted. Ie, I don't see any solution that directly uses that same internet connection with the traffic intercept. The fundamental problem is that if your ISP wants to intercept traffic that is not for them, the more specific solutions will not make things work better, they will just make your ISP's intercept into a DoS. – Håkan Lindqvist Jun 30 '19 at 11:25
  • @airforceone That said, both of your proposed technologies have their own problems in this context. DNSSEC allows you to reject data that has been tampered with when querying a signed zone, it cannot stop your ISP from intercepting traffic in the first place. DoT basically isn't a thing for authoritative servers (so far), so don't expect to be able to use it in this context; but still if they want to intercept DoT, they certainly can and it will just break it. – Håkan Lindqvist Jun 30 '19 at 11:28