Re: [dns-operations] need someone else to look at these servers
Hello, Le 15 oct. 2014 à 00:08, Lyle Giese a écrit : A customer is trying to send email to a customer that is using secureserver.net for email. Their MX record points to presmtp.ex3.secureserver.net. This is where things get screwy. Dig(+trace) shows that presemtp.ex3.secureserver.net has the following auth servers: gns1.secureserver.net gns2.secureserver.net gns3.secureserver.net However when I query these servers directly using dig, I get back No servers could be reached. (dig @gns1.secureserver.net presmtp.ex3.secureserver.net) When I use +notcp option, I get back: Warning: EDNS query returned status FORMERR - retry with '+noedns'. If I use +notcp and +noedns, it works and I get the A record. If I use +noedns, it works and I get the A record. Am I doing something wrong or are their servers/load balancers screwed up? I know something is wrong, but would like someone with a bit more knowledge to look at this and give their opinion. We can basically assume that their nameservers don't enable tcp, which is, as far as i know, a behaviour used by some administrators : % nc -zv gns1.secureserver.net 53 nc: connect to gns1.secureserver.net port 53 (tcp) failed: Operation timed out % nc -zv gns2.secureserver.net 53 nc: connect to gns2.secureserver.net port 53 (tcp) failed: Connection refused % nc -zv gns3.secureserver.net 53 nc: connect to gns3.secureserver.net port 53 (tcp) failed: Operation timed out % nc -zv -u gns1.secureserver.net 53 Connection to gns1.secureserver.net 53 port [udp/domain] succeeded! % nc -zv -u gns2.secureserver.net 53 Connection to gns2.secureserver.net 53 port [udp/domain] succeeded! % nc -zv -u gns3.secureserver.net 53 Connection to gns3.secureserver.net 53 port [udp/domain] succeeded! However, the bad thing is that one server is actually dropping TCP packets instead of rejecting them (by the way, you may notice that gns1.secureserver.net and gns3.secureserver.net actually points to the same IP). This behaviour might not help dns recursive servers to fallback to UDP when TCP failed. Best regards Emmanuel Thierry ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What's the story on gmail.fr?
Le 6 juil. 2014 à 17:10, Emmanuel Thierry m...@sekil.fr a écrit :
Le 6 juil. 2014 à 16:34, Stephane Bortzmeyer bortzme...@nic.fr a écrit :
On Sun, Jul 06, 2014 at 03:45:18PM +0200,
sth...@nethelp.no sth...@nethelp.no wrote
a message of 30 lines which said:
But according to the name servers for .fr,
gmail.fr. 172800 IN NS dns1.emarkmonitor.com.
gmail.fr. 172800 IN NS dns2.emarkmonitor.com.
gmail.fr had this set of name servers for a very long time (2010, you
can check in DNSDB if you're not sure).
From my vantage point in Norway (AS 2116), I can't get any answer at
all from dns{1,2}.emarkmonitor.com - thus gmail.fr is for all purposes
nonexistent for our customers.
Same problem for me. No idea of the cause. But it is _not_ specific to
.fr or to Google. Same problem for all domains hosted at
dnsN.emarkmonitor.com, like amazon-blog.biz.
Contrarily to dnsN.emarkmonitor.com, nsN.markmonitor.com replies to queries.
But the answer is still different from google servers :
% dig +short @ns1.google.com gmail.fr
173.194.66.17
173.194.66.18
173.194.66.83
173.194.66.19
% dig +short @ns1.markmonitor.com gmail.fr
72.14.253.83
64.233.161.83
64.233.171.83
By the way, as far as i know french people use gmail.com in place of gmail.fr.
They won't even notice ! ;)
Best regards
Emmanuel Thierry
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What's the story on gmail.fr?
Le 6 juil. 2014 à 16:34, Stephane Bortzmeyer bortzme...@nic.fr a écrit :
On Sun, Jul 06, 2014 at 03:45:18PM +0200,
sth...@nethelp.no sth...@nethelp.no wrote
a message of 30 lines which said:
But according to the name servers for .fr,
gmail.fr. 172800 IN NS dns1.emarkmonitor.com.
gmail.fr. 172800 IN NS dns2.emarkmonitor.com.
gmail.fr had this set of name servers for a very long time (2010, you
can check in DNSDB if you're not sure).
From my vantage point in Norway (AS 2116), I can't get any answer at
all from dns{1,2}.emarkmonitor.com - thus gmail.fr is for all purposes
nonexistent for our customers.
Same problem for me. No idea of the cause. But it is _not_ specific to
.fr or to Google. Same problem for all domains hosted at
dnsN.emarkmonitor.com, like amazon-blog.biz.
Contrarily to dnsN.emarkmonitor.com, nsN.markmonitor.com replies to queries.
But the answer is still different from google servers :
% dig +short @ns1.google.com gmail.fr
173.194.66.17
173.194.66.18
173.194.66.83
173.194.66.19
% dig +short @ns1.markmonitor.com gmail.fr
72.14.253.83
64.233.161.83
64.233.171.83
Best regards.
Emmanuel Thierry
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What's the story on gmail.fr?
Le 6 juil. 2014 à 17:17, Stephane Bortzmeyer bortzme...@nic.fr a écrit : On Sun, Jul 06, 2014 at 05:10:29PM +0200, Emmanuel Thierry m...@sekil.fr wrote a message of 45 lines which said: Contrarily to dnsN.emarkmonitor.com, nsN.markmonitor.com replies to queries. But the answer is still different from google servers : It does not matter what server X or server Y says, even if it is a Google name server: they have no delegation (as I said, the delegation did not change since 2010) and therefore their opinion is irrelevant. Indeed, I was just advocating for a human error as : * a miscommunication between google and markmonitor to state who has to host nameservers * a lack of migration management in markmonitor from formers to new nameservers Best regards Emmanuel Thierry ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Best practices for Linux/UNIX stub resolver failover
Le 30 avr. 2014 à 12:47, Klaus Darilion a écrit : I agree with the bad behavior of the stub resolver. On 22.04.2014 21:04, Chuck Anderson wrote: 2. Use a local DNS daemon on every server with forwarders configured to the network's nameservers, and fix resolv.conf to 127.0.0.1. The problem here is that you add another single point of failure - your local resolver. If it crashes and is not automatically restarted (which is the case for default Unbound and Bind installations) your DNS is broken too. If your local resolver crashes, you might have more concerns to think about than your local DNS service (memory exhaustion on your server for instance). Stable versions of unbound and bind run quite well during months or years without problems. Best regards Emmanuel Thierry ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] most of root NS and com's NS fail from here
Hello, Le 29 avr. 2014 à 19:26, David Conrad a écrit : On Apr 29, 2014, at 3:05 AM, Emmanuel Thierry m...@sekil.fr wrote: If i'm not mistaken, the Chinese filtering is performed on a per-service basis. The (presumably UDP) based traceroute appears to get stuck just after entering the DREN, not at the Chinese border... A UDP traceroute is definitely not reliable as a network debugging tool. UDP is commonly filtered by firewalls in entreprise or managed networks. You need at least a ICMP traceroute or a mtr. As an example, the UDP traceroute gives exactly the same kind of results in my home or servers as Ken Peng, though i don't have any trouble in making DNS queries at it, even with a +notcp flag. What we may observe from tests is that some dns servers failed without an obvious connectivity problem (ping is OK). As a consequence, i think it would be really interesting to test for instance with an arbitrary dns server and see whether it fails or not. Best regards Emmanuel Thierry ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] Graphical timelines for DNSSEC operations
Hello (First time posting on this ML) After several months of waiting, i'm testing DNSSEC deployment with some on my domains, using opendnssec software. However, some principles still are hard to envision for dummies, especially time schedules. As an example, RFC 6781 shows a very clear timeline on section 4.4.2.2 about signature validity. But it miss it for any other operation (KSK or ZSK rollover, DS publication in the parent zone, ...). Concretely, it implies that system administrators who are not DNSSEC experts may have a lot trouble to understand what exactly mean each configuration parameters in softwares stick really tightly to RFC 6781 such as opendnssec. In consequence, DNSSEC configuration looks like black magic that will work (because software is made to do so) but we don't know why... In my very specific case, i don't understand which of my parameters makes the KSK to take one day to be considered as published when my zones TTL are set to 3600. Does material exists to explicit graphically (in an ideal way) each specific key and DNSSEC records life cycle, in the same manner of section 4.4.2.2 ? Thanks Emmanuel Thierry ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Graphical timelines for DNSSEC operations
Hello, Le 13 déc. 2013 à 15:43, Klaus Darilion a écrit : On 13.12.2013 15:21, Emmanuel Thierry wrote: Hello (First time posting on this ML) After several months of waiting, i'm testing DNSSEC deployment with some on my domains, using opendnssec software. However, some principles still are hard to envision for dummies, especially time schedules. As an example, RFC 6781 shows a very clear timeline on section 4.4.2.2 about signature validity. But it miss it for any other operation (KSK or ZSK rollover, DS publication in the parent zone, ...). Concretely, it implies that system administrators who are not DNSSEC experts may have a lot trouble to understand what exactly mean each configuration parameters in softwares stick really tightly to RFC 6781 such as opendnssec. In consequence, DNSSEC configuration looks like black magic that will work (because software is made to do so) but we don't know why... In my very specific case, i don't understand which of my parameters makes the KSK to take one day to be considered as published when my zones TTL are set to 3600. Maybe you have configured a long propagation delay. See https://wiki.opendnssec.org/display/DOCS/kasp.xml Indeed, it worked when i reduced the PropagationDelay field from the Zone block (it was the most logical candidate). Does material exists to explicit graphically (in an ideal way) each specific key and DNSSEC records life cycle, in the same manner of section 4.4.2.2 ? Have you checked: https://wiki.opendnssec.org/display/DOCS/Key+Rollovers and http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing-03 Lot clearer ! I think any system administrator deploying DNSSEC-enabled authoritative servers should have it ! ;) However, i still wonder how, for instance, the PropagationDelay field from the Parent block is used. The zone were automatically marked active when i set it ds-seen. I would have expected OpenDNSSEC to wait for PropagationDelay to mark it active according to the timeline you refer to (PropagationDelay == Dreg ?). Anyway, we are a bit switching to OpenDNSSEC internals. Best regards Emmanuel Thierry ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
