Entrust is definitely aware of the issue and are working on it. Yes it is a misconfiguration. This breaks FaceTime on dual stack machines on dual stack machines.
They reported that they had fixed it earlier today but hadn't when I tested. They acknowledge the report that it was still broken and were going to look at their setup again. Mark In message <a605629600c9a347b5881ffe16f101fb3d823f6...@ndmsscc07.ndc.nasa.gov>, "Bischof, Ralph F. (MSFC-IS40)[NICS]" writes: > > -----Original Message----- > > From: bind-users-bounces+ralph.bischof=nasa....@lists.isc.org > > [mailto:bind-users-bounces+ralph.bischof=nasa....@lists.isc.org] On Behalf > > Of Barry Margolin > > Sent: Tuesday, April 24, 2012 9:37 AM > > To: comp-protocols-dns-b...@isc.org > > Subject: Re: SERVFAIL with ocsp.entrust.net. > > > > In article <mailman.576.1335276428.63724.bind-us...@lists.isc.org>, > > "Bischof, Ralph F. (MSFC-IS40)[NICS]" <ralph.bisc...@nasa.gov> wrote: > > > > > Hello, > > > > > > I have been trying to find out why my caching servers are giving > > > SERVFAIL as an answer for any type of query except for an A record for > > > the domain in the subject. Whether I try a AAAA, TXT, SOA, PTR, TXT, > > > etc, I get a SERVFAIL answer. Yet, it seems that anyone else in the > > > world is getting NOERROR. Now, when I direct the query to the > > > Microsoft DNS servers (8.8.8.8), I also get NOERROR. I have tried > > > different versions of clients (9.4.3-P5 and > > > 9.6-ESV-R4-P3) and get the same response, so I do not think that is > > > the issue. > > > > 8.8.8.8 is Google Public DNS, nothing to do with Microsoft. > > Oops. Had MS on the mind. I honestly meant Google. > > > > > > > When I use a 'dig +trace', the end of the chain shows a server that > > > does not exist in the last answer consisting of the SOA record. In > > > fact, since Sungard is involved, the whole chain makes no sense to me. > > > I have edited out the extra stuff, but here is what I try to do. > > > > They're delegating the ocsp.entrust.net subdomain to gnsX.sungardns.com, > > but those machines are configured to be authoritative for the entire > > entrust.net zone. But they have different contents than the real entrust.n > et > > zone. This is causing confusion in caching servers, because negative > > responses (like the NOANSWER response to AAAA queries) have the wrong > > domain in the authority section. > > Right. I have tried to explain this to both Sungard and Entrust. I don't unde > rstand how this works. Would you agree that this is a misconfiguration? > > > > > > > > First, here is the 'dig +trace' with an A query. I left out the list > > > of the root and gtld servers. > > > [bischrf@nsc1 ~]$ dig +trace ocsp.entrust.net. a ;; Received 300 bytes > > > from 192.149.130.101#53(192.149.130.101) in 0 ms ;; Received 491 bytes > > > from 192.5.5.241#53(f.root-servers.net) in 26 ms > > > > > > entrust.net. 172800 IN NS secondary-ns1.allstream.c > om. > > > entrust.net. 172800 IN NS secondary-ns2.allstream.c > om. > > > entrust.net. 172800 IN NS ns1.entrust.net. > > > entrust.net. 172800 IN NS ns2.entrust.net. > > > ;; Received 203 bytes from 192.42.93.30#53(g.gtld-servers.net) in 115 > > > ms > > > > > > ocsp.entrust.net. 7200 IN NS gns1.sungardns.com. > > > ocsp.entrust.net. 7200 IN NS gns2.sungardns.com. > > > ;; Received 85 bytes from > > > 216.13.122.23#53(secondary-ns1.allstream.com) in > > > 120 ms > > > > > > ocsp.entrust.net. 30 IN A 216.191.247.139 > > > ;; Received 50 bytes from 207.19.96.22#53(gns1.sungardns.com) in 109 > > > ms > > > ------------------------ > > > Then a 'dig +trace' looking for the AAAA record. > > > [bischrf@nsc1 ~]$ dig +trace ocsp.entrust.net. aaaa ;; Received 344 > > > bytes from 192.149.130.101#53(192.149.130.101) in 0 ms ;; Received 491 > > > bytes from 199.7.83.42#53(l.root-servers.net) in 160 ms > > > > > > entrust.net. 172800 IN NS secondary-ns1.allstream.c > om. > > > entrust.net. 172800 IN NS secondary-ns2.allstream.c > om. > > > entrust.net. 172800 IN NS ns1.entrust.net. > > > entrust.net. 172800 IN NS ns2.entrust.net. > > > ;; Received 203 bytes from 192.26.92.30#53(c.gtld-servers.net) in 34 > > > ms > > > > > > ocsp.entrust.net. 7200 IN NS gns1.sungardns.com. > > > ocsp.entrust.net. 7200 IN NS gns2.sungardns.com. > > > ;; Received 85 bytes from 216.191.247.202#53(ns2.entrust.net) in 125 > > > ms > > > > > > entrust.net. 60 IN SOA phlig3.oamp.sgns.net. > > > hostmaster.phlig3.oamp.sgns.net. 42 10800 3600 604800 60 ;; Received > > > 98 bytes from 207.19.96.22#53(gns1.sungardns.com) in 111 ms > > > NOTE: phlig3.oamp.sgns.net does not exist. > > > ---------------------------------- > > > > > > Here is the query that works. > > > [bischrf@nsc1 ~]$ dig ocsp.entrust.net. a > > > > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29329 ;; flags: qr > > > rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 > > > > > > ;; ANSWER SECTION: > > > ocsp.entrust.net. 24 IN A 216.191.247.203 > > > > > > ;; AUTHORITY SECTION: > > > ocsp.entrust.net. 1675 IN NS gns1.sungardns.com. > > > ocsp.entrust.net. 1675 IN NS gns2.sungardns.com. > > > --------------------------- > > > > > > Now a AAAA query. Note there is no authority. > > > [bischrf@nsc1 ~]$ dig ocsp.entrust.net. aaaa > > > > > > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20073 ;; flags: > > > qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > > -------------------------- > > > > > > So now I try to follow the chain. > > > 1) Query entrust.net. for the NS records. I get 4. > > > [bischrf@nsc1 ~]$ dig entrust.net. ns > > > > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17958 ;; flags: qr > > > rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4 > > > > > > ;; ANSWER SECTION: > > > entrust.net. 1617 IN NS ns2.entrust.net. > > > entrust.net. 1617 IN NS secondary-ns1.allstream.c > om. > > > entrust.net. 1617 IN NS ns1.entrust.net. > > > entrust.net. 1617 IN NS secondary-ns2.allstream.c > om. > > > --------------------- > > > > > > 2) I pick one of those and ask for the NS records for ocsp.entrust.net. > > > [bischrf@nsc1 ~]$ dig @ns1.entrust.net. ocsp.entrust.net. ns > > > > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7029 ;; flags: qr > > > rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; WARNING: > > > recursion requested but not available > > > > > > ;; AUTHORITY SECTION: > > > ocsp.entrust.net. 7200 IN NS gns1.sungardns.com. > > > ocsp.entrust.net. 7200 IN NS gns2.sungardns.com. > > > ---------------------- > > > > > > 3) I pick one of those and try a AAAA query. > > > [bischrf@nsc1 ~]$ dig @gns1.sungardns.com. ocsp.entrust.net. aaaa > > > > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4292 ;; flags: qr > > > aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: > > > recursion requested but not available > > > > > > ;; AUTHORITY SECTION: > > > entrust.net. 60 IN SOA phlig3.oamp.sgns.net. > > > hostmaster.phlig3.oamp.sgns.net. 42 10800 3600 604800 60 > > > ------------------------------ > > > > > > Note above that I do get an authority, yet the MNAME does not exist. > > > In fact, when I direct a query to the Microsoft DNS server for the > > > record > > > > MNAME is not involved in resolving names, so why does this matter? For > > most domains, MNAME can be ignored entirely. > > I am pulling at straws. A thought that I had is that the MNAME in the SOA for > entrust.net. was being inserted into my cache for an NS record, therefore th > e caching server tries to go to the nonexistent server for AAAA resolution. O > kay, it was a very longshot. :-) > > > > > "phlig3.oamp.sgns.net", I get a SERVFAIL. > > > [bischrf@nsc1 ~]$ dig @8.8.8.8 phlig3.oamp.sgns.net. > > > > > > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58650 ;; flags: > > > qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > > ------------------------------- > > > > > > So I try to find what is up with that record and I end up with a dead > > > end at the NS records for oamp.sgns.net. I find the NS records, but I > > > cannot get an IP for either one of them. > > > [bischrf@nsc1 ~]$ dig sgns.net. ns > > > > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19454 ;; flags: qr > > > rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 > > > > > > ;; ANSWER SECTION: > > > sgns.net. 1779 IN NS ns2.sungardns.com. > > > sgns.net. 1779 IN NS ns1.sungardns.com. > > > ------------------------------------------- > > > [bischrf@nsc1 ~]$ dig @ns2.sungardns.com. oamp.sgns.net. ns > > > > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64087 ;; flags: qr > > > rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; WARNING: > > > recursion requested but not available > > > > > > ;; AUTHORITY SECTION: > > > oamp.sgns.net. 3600 IN NS phlnn1.oamp.sgns.net. > > > oamp.sgns.net. 3600 IN NS hounn1.oamp.sgns.net. > > > ------------------------------ > > > [bischrf@nsc1 ~]$ dig @ns2.sungardns.com. phlnn1.oamp.sgns.net. > > > > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25825 ;; flags: qr > > > rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; WARNING: > > > recursion requested but not available > > > > > > ;; AUTHORITY SECTION: > > > oamp.sgns.net. 3600 IN NS phlnn1.oamp.sgns.net. > > > oamp.sgns.net. 3600 IN NS hounn1.oamp.sgns.net. > > > ------------------------------------- > > > [bischrf@nsc1 ~]$ dig @ns2.sungardns.com. hounn1.oamp.sgns.net. > > > > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56868 ;; flags: qr > > > rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; WARNING: > > > recursion requested but not available > > > > > > ;; AUTHORITY SECTION: > > > oamp.sgns.net. 3600 IN NS phlnn1.oamp.sgns.net. > > > oamp.sgns.net. 3600 IN NS hounn1.oamp.sgns.net. > > > --------------------------- > > > > > > I did talk with both Sungard and Entrust on what I found and they > > > sent me an email that they fixed "something" last night. How can I > > > troubleshoot more why my servers are reporting SERVFAIL for any non-A > > > types for this domain where it seems that everyone else in the world > > > is getting NOERROR? Thank you for reading this far and any help that you > > can provide. > > > > > > > > > Thank you, > > > Ralph F. Bischof, Jr. > > > NASA Agency IPAM/DNS/DHCP > > > SAIC/NICS > > > 256-544-3982 > > > > -- > > Barry Margolin > > Arlington, MA > > _______________________________________________ > > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscri > be > > from this list > > > > bind-users mailing list > > bind-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users > > > Thank you, > Ralph F. Bischof, Jr. > NASA Agency IPAM/DNS/DHCP > SAIC/NICS > 256-544-3982 > > > > _______________________________________________ > 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
