[dns-operations] hosting. nameservers partial unreachable
--- Begin Message ---
Hello,
to day I noticed unreachable nameserver [a-d].nic.hosting. via IPv4
approved by at least two locations by such script:
for transport in tcp notcp; do
for protocol in 4 6; do
for host in a b c d; do
printf "${host}.nic.hosting/${protocol}/${transport}:"
if dig -${protocol} @${host}.nic.hosting. hosting. soa +timeout=1 +retry=1
+short +${transport} 2>/dev/null | grep --silent hostmaster.centralnic.net; then
printf "ok\n";
else
printf "fail\n";
fi
done
done
done
from AS31334 and AS15451:
a.nic.hosting/4/tcp:fail
b.nic.hosting/4/tcp:fail
c.nic.hosting/4/tcp:fail
d.nic.hosting/4/tcp:fail
a.nic.hosting/6/tcp:ok
b.nic.hosting/6/tcp:ok
c.nic.hosting/6/tcp:ok
d.nic.hosting/6/tcp:ok
a.nic.hosting/4/notcp:fail
b.nic.hosting/4/notcp:fail
c.nic.hosting/4/notcp:fail
d.nic.hosting/4/notcp:fail
a.nic.hosting/6/notcp:ok
b.nic.hosting/6/notcp:ok
c.nic.hosting/6/notcp:ok
d.nic.hosting/6/notcp:ok
from other locations I got 16x ok
Sometimes I also saw some OK for IPv4, too bit resolver so not retry as often.
Any hints?
Andreas
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] why does that domain resolve?
Am 11.06.21 um 20:00 schrieb Warren Kumari: > So, what are people's favorite tools, especially those that you can just > point a user at? Warren, you mention both important tools - https://zonemaster.net - https://dnsviz.net Both are also good for automated self monitoring as they can be build and run locally. Sometimes I use also the EDNS Compliance Tester - https://ednscomp.isc.org Andreas ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] why does that domain resolve?
Am 05.06.21 um 14:56 schrieb Mats Dufberg: > 3. The .xa NS returns a referral to the NS of house.xa. > 4. The resolver send a request for "www.house.xa. A" to an house.xa NS. > > To force the use of NS from the zone the DNS protocal has to be rewritten, > and if that is done, why not remove the NS from the zone and make them > authoritative records of the parent? That's a good question. What are NS records good for, if for $reason no resolver implement step 3.5: 3.5 The resolver ask of the glue-NS for "house.xa." NS to get a authoritative list of "house.xa." NS Andreas ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] why does that domain resolve?
Am 04.06.21 um 17:52 schrieb A. Schulze: > So I wonder, why do so many resolver [1] obviously do only follow a > delegation and ignore authoritative data? Is "being client centric" a candidate for a "dns-flag-day-2022"? Consider .com like to intercept gmail.com. Changing the delegation in .com would be enough. Really? Andreas ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] why does that domain resolve?
Hello, we found the domain "xn--80atcidr8i.xn--p1ai." in one of our logs. the TLD "xn--p1ai." delegate "xn--80atcidr8i.xn--p1ai." to two working nameservers. But these nameserver choose to announce "ns1.example.com" and "ns2.example.com" as authoritative. These names are garbage. But most resolver do not fail to give an answer for "xn--80atcidr8i.xn--p1ai. /A" So I wonder, why do so many resolver [1] obviously do only follow a delegation and ignore authoritative data? Is it really some sort of "Hey, you asked for $domain/A, the setup is so broken, but I tried really my best: here as an answer..." ? Andreas [1] - 1.1.1.1 - 8.8.8.8 - 9.9.9.9 - unbound-1.13.1 - Debian Buster's Bind 9.10.3 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] validating zones before distribution to secondaries
Am 04.05.21 um 20:53 schrieb Phil Regnauld: > On the validation side, take a look at: > > https://github.com/tobez/validns validns seem to be unmaintained. Build fail with current openssl :/ ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] validating zones before distribution to secondaries
Am 04.05.21 um 16:30 schrieb Anand Buddhdev: > You might want to look at Tony Finch's nsnotifyd, which is a custom > program that can monitor zones for changes, and run custom commands when > changes are detected. It can also listen for NOTIFY messages and act > immediately on zone changes. You could use it to run your custom checks > before distributing your zones. > https://github.com/fanf2/nsnotifyd Yes, Tony's program it's a little bit tricky to build but works... Andreas ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] contact to jimdo.com
Simon Arlott via dns-operations: Try doing some more queries. It's not based on the case of the query. Looks like a load balancer and different versions of the zone. If you query for the SOA you can get two different serial numbers. Hi Simon, yes, that's an other issue with that nameservers. "doing more queries" is not how a reolver work :-/ Temporary disabling caps for *known* domains is something I could do in my infrastructure. It doesn't solve the root cause ... Andreas ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] contact to jimdo.com
Hello, I've an issue resolving MX-Records for domains hosted at [ns11,ns12].jimdo.com The servers answer same questions in different ways: dig @ns11.jimdo.com. MIRISSIMA.DE. MX +norec -> NOERROR, no ANSWER dig @ns11.jimdo.com. mirissima.de. mx +norec -> NOERROR, answer BUT: question for an A-Record are answered no matter upper- or lowercase is used. So my MTA try to deliver messages to the webserver :-/ Usually, UNBOUND, the resolver I use, can handle capitalization issues. But here, the resolver have no reason to assume a retry with all lowercase will have an other result. Andreas ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] How widely implemented are different DNSSEC algorithms?
Am 11.09.20 um 20:29 schrieb John Levine: > Are there any published numbers estimating how well the various DNSSEC > algorithms are supported in DNS caches and client software? > > Or to put it another way, were I to switch from signing with > algorithm 8 to 13, how much would I regret it? Hi John, I switched from 8 to 13 two or thee years ago and did not notice any issue. Andreas ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] glitch on [ip6|in-addr].arpa?
Arsen STASIC: * Viktor Dukhovni [2019-10-10 20:51 (-0400)]: On Thu, Oct 10, 2019 at 06:25:41PM -0400, Matthew Pounsett wrote: The speculation I've seen is that Cogent refuses to treat HE as a Tier1 network in v6 because they don't try to also be one in v4, but that they should because HE's v6 network is much wider reaching and much longer established than Cogent's. In any case, Cogent's refusal to peer with HE over v6 has been very public and well documented. It makes Cogent unreachable from a significant portion of the v6 network. It has perhaps not been as well known as it deserves to be. Perhaps additional publicity here (and any other relevant fora), might nudge the parties closer to a resolution. The non-reachability of the IPv6 C root from a significant portion of IPv6 space is not a healthy situation. The error is immediately apparent via DNSViz: https://dnsviz.net/d/root/dnssec/ RIPE Atlas DNSMON measurement doesn't indicate this: https://atlas.ripe.net/dnsmon/group/root?dnsmon.session.color_range_pls=0-66-66-99-100=true=server-probes=root=undefined=156816=1570752000=true=both=false=2001:500:2::c that link show "everything is green" because no server is below 66% drop rate change to 3% show issues with C and D root. also visible: F root is much better since 2019-10-10 ~14:00 UTC Andreas ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] glitch on [ip6|in-addr].arpa?
Hello, while debugging a PTR resolution problem I noticed warnings on http://dnsviz.net/d/ip6.arpa/dnssec/ and http://dnsviz.net/d/in-addr.arpa/dnssec/ To me, it looks like some in-addr-servers.arpa servers are unable to handle large responses. $ dig ip6.arpa. dnskey +dnssec ... ;; MSG SIZE rcvd: 1329 $ dig in-addr.arpa. dnskey +dnssec ... ;; MSG SIZE rcvd: 1341 Anybody agree, there is potential for operational improvements? Andreas ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
