Re: [dns-operations] Prevalence of nameserver software Was: Re: DNS Operations
> On Mar 3, 2024, at 12:26 PM, Fred Morris wrote: > > Speaking to the message not the (ChetGPT) "massage"... > > On Sun, 3 Mar 2024, Turritopsis Dohrnii Teo En Ming wrote: >> [...] >> I define most popular as the largest number of DNS server installed >> throughout the whole world. > > I think this is a valid point. DNS is not synonymous with the Internet; > neither is operations. > > Internal DNS servers exist, and with guidance concerning the need for network > segmentation there should be a lot more of them. I have had several requests > and inquiries over the past few years specifically concerning a desire to log > the addresses of clients making requests. > > These requests persistently refuse to accept that DNS is an application level > protocol, and that a request (or response) is recast by every nameserver it > passes through even if it is merely "forwarding": "there must be a way!" > People go to great lengths, there's a lot of language lawyering and playing > with EDNS involved in these attempts. > > Invariably my answer (for all but the most technical questions) is install a > real DNS server with visibility inside of the NAT horizon (if there is one; > there usually is), and that the general-purpose "logging" solution is Dnstap. > > My admittedly cynical response to the question posed here is that the most > common server software is probably a lightweight forwarder (e.g. dnsmasq) or > something which only coincidentally does DNS (e.g. Active Directory). I think based on the surveys that I had done before, there’s quite a number of not only forwarders, eg: dnsmasq but also iptables rules that perform forwarding as a service, eg: take all udp/53 hitting the host and forward the packets (only sometimes with source address rewritten) to the configured DNS server(s). It’s likely much harder to determine this as you could practically put something behind DoH w/ HTTP basic auth preventing any queries from occurring without authorization. If there were a stable standards based way to deliver the credentials, I could see this being done as part of a captive portal or pay-as-you-go service even. - Jared ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNS .com/.net resolution problems in the Asia/Pacific region
More of a routing thing than DNS - but this type of view from the outside in is really helpful to detect by providers feeding RIPE RIS or route views so there are better external views into networks. This is an area where I want to expand and improve coverage after things like the silent and hidden hijacking's (see ripe invisible hijacks talk) - as we are more distributed it makes it more diverse and resilient but also more places for interesting local failures. Sent via RFC1925 compliant device > On Jul 11, 2023, at 7:38 PM, Viktor Dukhovni wrote: > >> Unfortunately, a peering router remained >> active, which was not immediately obvious to our teams due to the lack >> of connectivity there. > > Thanks for the PM details, much appreciated. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] "off label" use of PTR records for fanout
Often folks will use TXT with a low TTL and use a specific label path to perform this function. Sent via RFC1925 compliant device > On Jun 15, 2023, at 4:22 PM, Fred Morris wrote: > > Hello, > > I'm using DNS to retrieve some distributed telemetry data from multiple > servers. To facilitate this I have an FQDN which resolves to a set of > PTR records. If there's a generally accepted better option, let me know. > > If you just want to bike shed this fine, I invite you to email me > directly as I think this is already tangential to the purpose of this list. > > Thank you for understanding... > > -- > > Fred Morris > > -- > > (Are you still reading?) > > I'm basically using PTR records like CNAME, but with the semantics "try > all of these". The normal semantics of DNS resolution have the objective > of finding "the one (best) answer from the (best) server" > notwithstanding that the answer may consist of multiple answers, > presuming in a panglossian fashion that the first answer we get is the > best one for us at this point in time. Can't use CNAME because the DNS > builds semantics around it which would interfere the semantics here. I > presume the same accrues to e.g. SRV records. It just isn't expecting us > to try them all as a matter of course. > > > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] c.root-servers.net over IPv6
from what source IP? > On Feb 3, 2020, at 3:02 PM, SM wrote: > > Hello, > > c.root-servers.net (2001:500:2::c) is not responding to queries over IPv6 [1]. > > Regards, > -sm > > 1. The error from DNSViz is "arpa zone: The server(s) were not responsive to > queries over UDP. (2001:500:2::c)" > > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] IPv6 only for nameservers
While I would not recommend this generally there are a few of us that operate free secondary services that are dual stacked. Make sure one NS is dual stacked and you are likely fine. Sent from my iCar > On Dec 31, 2019, at 4:47 AM, Shane Kerr wrote: > > Stephane and all, > >> On 30/12/2019 16.01, Stephane Bortzmeyer wrote: >> On Mon, Dec 30, 2019 at 05:18:01PM +0300, >> Anand Buddhdev wrote >> a message of 17 lines which said: >>> If your domain's authoritative name servers have only IPv6 >>> addresses, then your domain will not be resolvable by many resolvers >>> on the Internet, because many of them only have IPv4 connectivity. >> This was in 2014 but I'm not sure it changed a lot since: >> https://labs.ripe.net/Members/stephane_bortzmeyer/how-many-ripe-atlas-probes-can-resolve-ipv6-only-domain-names > > I just re-ran a similar test and got about a 71% success rate: > > https://atlas.ripe.net/measurements/23732712/ > > While technically slightly better than 67% success rate measured 5 years ago, > to me this means that running an IPv6-only name server it is basically not > possible. > > I also ran a version using IPv6-enabled probes, and got an 89% success rate: > > https://atlas.ripe.net/measurements/23734035 > > I think that even 90% is still not good enough to allow you to run an > IPv6-only name server, at least for general Internet usage. > > Cheers, > > -- > Shane > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] root? we don't need no stinkin' root!
> On Nov 27, 2019, at 5:26 PM, Florian Weimer wrote: > > What's the change rate for the root zone? If there is a full > transition of the name server addresses for a zone, how long does it > typically take from the first change to the completion of the sequence > of changes? There are regular changes. Resolvers regularly have old data. Survey for old root hints to see how bad they are. ___ 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?
> On Oct 16, 2019, at 7:41 AM, Paul Vixie wrote: > > hurricane and cogent are also businesses, each having employees and investors > and customers. they are each doing what makes sense to them. this is not a > "peering war" by any stretch of the vocabulary. cogent does not have a > completely open peering policy, and while hurricane has transit for its ipv4 > network, it lacks transit for its ipv6 network. I'm unaware of any network that discriminates based on AFI for transit so this fails to pass the laugh test. > their networks, their rules. I get this mantra, it applies in many cases but as per the above, it's poor behavior that harms us all. ___ 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?
On Thu, Oct 10, 2019 at 01:56:11PM -0700, Randy Bush wrote:
> >> Neither Cogent or HE buy transit from anybody else
>
> i believe this statement to be false
i know of at least 2 transit providers..
- jared
--
Jared Mauch | pgp key available via finger from ja...@puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only mine.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Verifying that a recursor is performing DNSSec validation
I have plans for a browser based test suite similar to test-ipv6.com for this. I have a host, domains, IPs but am missing time to complete the testing. If you are interested in collaboration please contact me off-list. - Jared On Tue, Jul 21, 2015 at 08:21:16AM -0500, Frank Bulk wrote: Thanks. I found three on the Internet that are set up that way: sigfail.verteiltesysteme.net www.dnssec-failed.org rhybar.cz I'm using those in my script (randomly) for checking for that failure case. Frank -Original Message- From: Livingood, Jason [mailto:jason_living...@cable.comcast.com] Sent: Tuesday, July 21, 2015 3:33 AM To: Frank Bulk frnk...@iname.com; dns-operati...@dns-oarc.net Subject: Re: [dns-operations] Verifying that a recursor is performing DNSSec validation And for one that is always deliberately broken, for testing: www.dnssec-failed.org On 7/20/15, 10:13 PM, Frank Bulk frnk...@iname.com wrote: Does anyone have an zone that will always remain unsigned? verteiltesysteme.net is going to make one, but if there was a second organization that could provide a zone that will never be signed, that would be great as a control. Frank -Original Message- From: dns-operations [mailto:dns-operations-boun...@dns-oarc.net] On Behalf Of Frank Bulk Sent: Friday, July 17, 2015 12:51 AM To: dns-operati...@dns-oarc.net Subject: Re: [dns-operations] Verifying that a recursor is performing DNSSec validation I've completed writing the first iteration of a NAGIOS-oriented Perl script that does the checks I've described. It was actually more painful to get the Net:DNS:DNSsec Perl module installed than anything else. We'll see how this works out in our environment. Frank -Original Message- From: dns-operations [mailto:dns-operations-boun...@dns-oarc.net] On Behalf Of Frank Bulk Sent: Tuesday, July 14, 2015 12:08 AM To: dns-operati...@dns-oarc.net Subject: [dns-operations] Verifying that a recursor is performing DNSSec validation Is there an existing tool, ideally a NAGIOS-friendly one, that performs a check against a resolver that it gets an AD back on DNSSec query for a zone that is properly signed, failure for one that is not properly signed, and nothing for one that isn't signed? http://docs.menandmice.com/display/MM/How+to+test+DNSSEC+validation I'd rather not re-invent the wheel if it already exists. Regards, Frank Bulk ___ 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 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 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 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 -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. ___ 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] AWS footnote: DNS firewall rules are UDP only
Sadly, there are devices such as the most recent Netgear routers and firmware that block TCP queries as well in the most horrific way, e.g.: https://www.cloudshark.org/captures/273da18d3057 - Jared On Jan 28, 2015, at 3:45 PM, Warren Kumari war...@kumari.net wrote: On Wed, Jan 28, 2015 at 2:28 PM, Fred Morris m3...@m3047.net wrote: I just noticed that when configuring firewall rules for an AWS instance, if DNS is chosen then the (only) protocol automagically filled in is UDP. To get TCP, you have to create a custom TCP rule. When you save, the UDP one gets saved as DNS, the TCP one stays custom TCP rule. Well, of course. What did you expect? DNS only uses UDP... Warren runs away, giggling manically W -- Fred Morris ___ 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 -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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 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] Bind v6 TCP listen?
On Nov 27, 2014, at 9:27 AM, bert hubert bert.hub...@netherlabs.nl wrote: On Wed, Nov 26, 2014 at 12:37:57PM -0500, Jared Mauch wrote: Is there some specific configuration magic that I’m missing to make bind listen to TCPv6 sockets? I do realize that in many places DNS and BIND are nearly the same thing, but perhaps we should keep this list for generic DNS things? While the question was about a specific piece of software, it’s one that many likely operate (hence asking on dns-operations). I could have asked on bind-users or other lists, but I’m subscribed to this one and know many that are smarter than I are here. As I mentioned yesterday, this seems like a bug and one that others may experience as well. I’ll troubleshoot and share more information later. (back to family time here in the US). - Jared ___ 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] Looking for a public blackhole/sinkhole IP address
We have such an IP address in our backbone but don't publish it. I suppose someone could ask for an allocation for this purpose from a local RIR and this could be done for that whole range. Jared Mauch On Nov 26, 2014, at 9:25 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: I'm trying to find out if it exists a public IP address which is a black hole, swallowing every packet sent to it. I can do that on my network but I'm wondering if it already exists somewhere, may be as an anycasted service (AS112-style). The idea is to delegate some domain names to unresponsive name servers (deleting the domain name is less efficient, since the negative TTL is smaller than the delegation TTL). It must work from everywhere on the Internet. 127/8 does not (the packets are not dropped but delivered to the resolver itself when it will try to follow the delegation). Same thing for RFC 1918 (there are often such addresses in the local network). I was thinking of non-routed addresses like 198.18.0.0/15 or 203.0.113.0/24 but it's not their normal use. AFAIK, there are no public sinkholes IPv4 addresses. For IPv6, there is 100::/64 but it is only internal, there is no public 100::/64 service. ___ 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 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] Bind v6 TCP listen?
Is there some specific configuration magic that I’m missing to make bind listen
to TCPv6 sockets?
Looking at what it’s doing via lsof it seems to not be listening to v6/tcp:
named 909 named 20u IPv4 24571 0t0 TCP
204.42.254.5:domain (LISTEN)
named 909 named 21u IPv4 28306 0t0 TCP
127.0.0.1:rndc (LISTEN)
named 909 named 512u IPv4 24570 0t0 UDP
204.42.254.5:domain
named 909 named 513u IPv4 24570 0t0 UDP
204.42.254.5:domain
named 909 named 514u IPv6 28319 0t0 UDP
[2001:418:3f4::5]:domain
named 909 named 515u IPv6 28319 0t0 UDP
[2001:418:3f4::5]:domain
My configuration is fairly straightforward, including manual listen-on
segments, e.g.:
listen-on { 204.42.254.5; };
listen-on-v6 { 2001:418:3f4::5; };
- Jared
___
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] Looking for a public blackhole/sinkhole IP address
On Nov 26, 2014, at 10:13 AM, Paul Wouters p...@nohats.ca wrote: http://tools.ietf.org/html/rfc6598 defines 100.64.0.0/10 Packets with Shared Address Space source or destination addresses MUST NOT be forwarded across Service Provider boundaries. Service Providers MUST filter such packets on ingress links. One exception to this paragraph's proscription is in the case of business relationships, such as hosted CGN services. When running a single DNS infrastructure, Service Providers MUST NOT include Shared Address Space in zone files. When running a split DNS infrastructure, Service Providers MUST NOT include Shared Address Space in external-facing zone files. So you should be fine to use it :) That’s certainly not the intent/purpose of the block of space any more than hard-coding 10.0.0.1 or some other answer like 1.1.1.1 or 1.2.3.4. - Jared ___ 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] Bind v6 TCP listen?
On Nov 26, 2014, at 3:48 PM, Niall O'Reilly niall.orei...@ucd.ie wrote:
At Wed, 26 Nov 2014 12:37:57 -0500,
Jared Mauch wrote:
Is there some specific configuration magic that I’m missing to make
bind listen to TCPv6 sockets?
[...]
My configuration is fairly straightforward, including manual
listen-on segments, e.g.:
listen-on { 204.42.254.5; };
listen-on-v6 { 2001:418:3f4::5; };
I realize I'm at risk of teaching my grandmother to suck eggs, but
reckon you must be dealing with something which is either really
obscure or hidden in plain sight, so here goes ...
I'ld expect that to be enough, unless there's a typo in the address.
I have for some reason
listen-on-v6 { all; };
It might be worth checking whether this makes a difference.
Thanks everyone. Looks like this is actually a bug in bind, or the one
packaged with FC21 (at least).
With any it seems to do the right thing:
named 909 named 20u IPv4 24571 0t0 TCP
204.42.254.5:domain (LISTEN)
named 909 named 21u IPv4 28306 0t0 TCP
127.0.0.1:rndc (LISTEN)
named 909 named 22u IPv4 18812144 0t0 TCP
204.42.254.5:domain-217.21.61.8:21683 (ESTABLISHED)
named 909 named 23u IPv6 18810485 0t0 TCP *:domain
(LISTEN)
named 909 named 512u IPv4 24570 0t0 UDP
204.42.254.5:domain
named 909 named 513u IPv4 24570 0t0 UDP
204.42.254.5:domain
named 909 named 514u IPv4 18809462 0t0 UDP *:13642
named 909 named 516u IPv6 18810484 0t0 UDP *:domain
named 909 named 518u IPv6 18810484 0t0 UDP *:domain
I’ll have to do some more testing later, back to family time.
- Jared
___
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] Looking for a public blackhole/sinkhole IP address
If someone wanted to dispose of that volume of requests they could get assistance if they asked the right people. Jared Mauch On Nov 26, 2014, at 7:12 PM, Robert Edmonds edmo...@mycre.ws wrote: Warren Kumari wrote: This thingie has many aspects that look a bunch like AS112 -- I'm wondering if it makes sense to also request an AS number for this. It's not strictly needed, but having fewer inconsistent origin routes is always nice. It also seems that (also like AS112), networks could do this in one of (at least) 3 ways: 1: They can spin up this route purely within their own network -- basically have one or more places where the route points at null0 / discard and *not announce it to peers / customers* or 2: announce to customers only or 3: be good citizens and announce it to everyone. 1 and 2 already exist, for RTBH (like you mention in the doc), they are just not anycasted. I wonder if we ask the IANA nicely if they'd assign 666.666.666.0/24 to.. oh, bugger The more people who do this, the more benefit there is - unfortunately this argument often doesn't work on the Internets, but still worth trying... If one is trying to dispose of 250 million DNS requests per second [0] or 1Mr/s (mega-requests per second) [1], then you probably *don't* want the traffic to be routed to whoever happens to have announced it, or anywhere, really. That seems to be a much different use case (drop the traffic as quickly and universally as possible, minimizing collateral damage) from routing the traffic to something like a community sinkhole. [0] http://www.forbes.com/sites/parmyolson/2014/11/20/the-largest-cyber-attack-in-history-has-been-hitting-hong-kong-sites/ [1] https://la51.icann.org/en/schedule/mon-tech/presentation-dafa888-dos-attack-13oct14-en.pdf -- Robert Edmonds ___ 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 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] Bind v6 TCP listen?
On Nov 26, 2014, at 8:25 PM, Mark Andrews ma...@isc.org wrote: There are some OS where named can't enumerate the IPv6 interfaces usually due to stupid OS hacks which means the listen-on-v6 ACL above has nothing to match against. What was wrong with providing this information via the socket interface? Why put it in the filesystem which then has to be duplicated when you are running chroot’d? my use case is not chroot()’ed and it sounds like others have hit this as well. I’ve solved my immediate issue. Happy to troubleshoot more with another host elsewhere that doesn’t have 8.5k zones seeing queries so it’s easier to tell what occurred. (aside: really wish bind would launch faster when loading these zones, or background the loading of the zones and answer those it can). That said this isn't the issue here as the process was bound on the IPv6 UDP port. I suspect a accept() failure caused named to close the socket or something else was listening on the TCP port when named was started or ... This is possible, I will dig through logs looking for any relevant messages.. once I changed to any; things immediately resolved with a rndc reload. - Jared ___ 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] Comments welcome : draft-song-dnsop-ipv6only-dns-00
On Oct 11, 2014, at 5:00 PM, Davey Song songlinj...@gmail.com wrote: IPv6 MTU is specified larger than IPv4. But the implementation like firewall or other mid-box may not follow the specification. It needs test in large-scaled network. I am completely in favor of breaking people who are not standards compatible with 1280 MTU. - Jared ___ 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] Is this valid edns0 query?
On Oct 10, 2014, at 2:54 PM, Hugo Salgado hsalg...@nic.cl wrote: On 10/10/2014 03:24 PM, Roland Dobbins wrote: On Oct 11, 2014, at 1:07 AM, Mohamed Lrhazi mohamed.lrh...@georgetown.edu wrote: The appliance vendor, Google, tells me that edns0 opt code 20732 must be the service name, whatever that means I don't know what that means in the context of a non-SRV query . . . can you turn off the F5's 'malformed DNS query' scrubbing and see what happens? Well... F5 is known of misbehavior with its aggressive filtering, even with records some time ago: http://hugo.salga.do/post/50030273426/quad-a-blocking-in-dns I’ve never had success with F5 and DNS packet handling properly going all the way back to Nov 1998 timeframe. One of their engineers was troubleshooting it in our offices of my employer at the time and ended up upset and saying “why doesn’t this work” when it was broken vs being able to properly triage it. I’m expecting someone from F5 to email me because at the time when I posted about the issue on NANOG they were aggressive in trying to defend a public view of their product and legitimate technical problems. - Jared ___ 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] First new gTLD using ICANN's Name Collision Occurrence Management Framework
On Thu, Aug 28, 2014 at 05:36:29PM -0400, Warren Kumari wrote: On Thu, Aug 28, 2014 at 4:12 PM, Warren Kumari war...@kumari.net wrote: On Thu, Aug 28, 2014 at 12:50 PM, SM s...@resistor.net wrote: Hi Chris, At 05:38 28-08-2014, Chris Thompson wrote: The gTLD otsuka, created sometime in the last 24 hours, appears to be the first to use the wildcards described at [snip] What do people think about this business? Is anyone taking specific precautions to detect attempts to connect to 127.0.53.53? I presume that the people who invented this stuff know what they are doing. Mwahahahahahhah hahhhahaha teehee... Thanks, I needed that. So, I just realized that this sounded like a jab specifically at JAS (the folk who proposed the 127.0.53.53 answer) -- this was actually instead supposed to be a jab at everyone :-) I had long discussions with the JAS folk, and have huge respect for them - they did, IMO, a good job. The really fun part (for me) is that depending on the OS you can ping 127.0.53.53. (eg: Linux, Yes, MacOS, No). Linux will also give you Connection refused for TCP connections. - Jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. ___ 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] Does anybody have a good list of capture filters for DNS traffic - details in email
On Jul 2, 2014, at 9:56 AM, Stefan netfort...@gmail.com wrote: Hello, DNS gurus, Does anybody have a good set of tcpdump/tshark capture filters, associated with DNS, already prep-ed for specific fields in the payload (so beyond just the simplistic udp 53 or tcp 53)? I've used the perl Net::DNS module for this type of stuff. It can easily be used to do that type of stuff. - Jared Why am I asking? - I need to set up traffic captures in various tiers of servers-hosting-applications whose owners cannot tell where the inter-tiers reachability depends (and maybe fails) on FWD or REVERSE lookups. This cannot be done by asking the server or apps folks to use the DNS traditional tools (dig, nslookup, host, etc.) simply because they cannot tell which hostnames or IPs make up the functionality of very complex apps, and have dependency on name resolution (direct or reverse) in order to work - I would be mostly interested (of course) in DNS packets with no responses - I would like to avoid re-inventing the wheel by trying to figure out at which byte offset I would have to start reading a string (is it even possible to identify that, knowing that certain strings are variable in length??), and identify no response, if someone has already figured out such things ;-) Thanks in advance for directions or no way - forget about it ***Stefan ___ 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 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] Current thinking on internal corporate/campus domain names
On Jun 24, 2014, at 9:01 AM, Kelly Setzer kelly.set...@wnco.com wrote: * Most respondents agreed that a registered domain for internal DNS was the way to go. Beware the mistakes of others as well, check out 'corp.verio.net' as an example of a poorly operated sub-domain. - Jared ___ 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] Current thinking on internal corporate/campus domain names
On Jun 24, 2014, at 12:53 PM, Phil Regnauld regna...@nsrc.org wrote: Jared Mauch (jared) writes: On Jun 24, 2014, at 9:01 AM, Kelly Setzer kelly.set...@wnco.com wrote: * Most respondents agreed that a registered domain for internal DNS was the way to go. Beware the mistakes of others as well, check out 'corp.verio.net' as an example of a poorly operated sub-domain. corp.verio.net is indeed a subdomain, and not a registered domain: Sorry, you seem to need more data to observe what i was trying to point out.. ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;corp.verio.net.IN NS ;; ANSWER SECTION: corp.verio.net. 0 IN NS 10.254.241.250. corp.verio.net. 0 IN NS stngva1-dc05.wpm.corp.verio.net. corp.verio.net. 0 IN NS frnkde1-dc03.corp.verio.net. corp.verio.net. 0 IN NS ns1.secure.net. corp.verio.net. 0 IN NS stngva1-dc03.corp.verio.net. corp.verio.net. 0 IN NS w3scva02.win.smewh.net. corp.verio.net. 0 IN NS w3scva00.win.smewh.net. corp.verio.net. 0 IN NS neutde1-dc00.corp.verio.net. corp.verio.net. 0 IN NS stngva1-dc06.wpm.corp.verio.net. corp.verio.net. 0 IN NS w3scca01.win.smewh.net. corp.verio.net. 0 IN NS oremut1-dc03.corp.verio.net. corp.verio.net. 0 IN NS w3dwin01.win.smewh.net. corp.verio.net. 0 IN NS iad-wprd-cordc1.corp.verio.net. corp.verio.net. 0 IN NS w3scva03.win.smewh.net. corp.verio.net. 0 IN NS s.ns.verio.net. corp.verio.net. 0 IN NS a.ns.verio.net. corp.verio.net. 0 IN NS stngva1-dc01.corp.verio.net. corp.verio.net. 0 IN NS bcrtfl1-fdc00.corp.verio.net. corp.verio.net. 0 IN NS ns2.secure.net. corp.verio.net. 0 IN NS 198.104.179.227. corp.verio.net. 0 IN NS neutde1-dc03. corp.verio.net. 0 IN NS iad-wprd-cordc2.corp.verio.net. corp.verio.net. 0 IN NS frnkde1-dc00.corp.verio.net. corp.verio.net. 0 IN NS w3scca00.win.smewh.net. corp.verio.net. 0 IN NS stngva1-dc04.corp.verio.net. corp.verio.net. 0 IN NS w3scsp01.win.smewh.net. corp.verio.net. 0 IN NS bcrtfl3-pdevdc1.pdev.verio.net. corp.verio.net. 0 IN NS w3scde01.win.smewh.net. corp.verio.net. 0 IN NS w3dwin00.win.smewh.net. corp.verio.net. 0 IN NS w3scca02.win.smewh.net. corp.verio.net. 0 IN NS oremut1-dc00.corp.verio.net. corp.verio.net. 0 IN NS neutde1-dc03.corp.verio.net. corp.verio.net. 0 IN NS w3scga01.win.smewh.net. corp.verio.net. 0 IN NS stngva1-dc02.corp.verio.net. corp.verio.net. 0 IN NS bcrtfl1-fdc01.corp.verio.net. corp.verio.net. 0 IN NS bcrtfl3-pdevdc2.pdev.verio.net. corp.verio.net. 0 IN NS bcrtfl1-dc04.corp.verio.net. corp.verio.net. 0 IN NS neutde1-dc00. Please point out the trouble with this in one sentence or less. - jared ___ 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] Current thinking on internal corporate/campus domain names
On Jun 24, 2014, at 4:29 PM, Matthew Ghali mgh...@snark.net wrote: Hi PHB- I'm curious when this scheme would be simpler to implement or less expensive to operate as opposed to using a delegated internal subdomain of an existing parent domain registration (see corp.verio.net modulo the psychopathic NS rrset). I'm certainly no authority but everyone seems to have a much more complicated solution to what I've always found to be a simple problem. Is it the old never expose 1918 addresses in public DNS fetish, or the related must not expose secret internal names via DNS paranoia? It's possible to have an 'internally' visible zone, but the 'corp.verio.net' example I provided is somewhat like the worst of both worlds. You detail a lot about your zone and internal server IPs without any security benefit at all. One should (ideally) not respond with ULA or 1918 addresses in your or A responses as the behavior can be undefined. What you don't want is to be delegating everything so far that you may have a host querying for an internal resource sending everyone talking to their own local 10.x DNS server because of the way you established NS records. Your VPN and internal resolvers can be an authority on corp.example.com without exposing that to the broader internet. - jared ___ 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] 172.in-addr.arpa DNSSEC broken
On May 20, 2014, at 7:13 AM, cgielen+dnso...@gielen.name wrote: DNSSEC-validation fails for 172.in-addr.arpa . This causes reverse DNS lookups to fail for all IPv4-address starting with 172. http://dnsviz.net/d/16.172.in-addr.arpa Is this perhaps related to AS112 project as well or 172.16 zones being built-in to some resolvers? - Jared https://www.as112.net/ ___ 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] The Decline and Fall of BIND 10
On May 15, 2014, at 3:55 AM, João Damas j...@bondis.org wrote: If it is 9.11, it might be good number to make attack resilience the focus of that version (a good code audit, more robust error-condition response, evolution of RRL and related features, logging that doesn't kill you, etc) I heard they are skipping number 11, the next release would be 9.12. - Jared ___ 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] The Decline and Fall of BIND 10
On Thu, May 15, 2014 at 03:12:07PM +, Evan Hunt wrote: On Thu, May 15, 2014 at 07:12:53AM -0400, Jared Mauch wrote: I heard they are skipping number 11, the next release would be 9.12. It's on our roadmap as 9.11. Apparently i misheard. - Jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. ___ 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] Weirdness with glue for old (gone) DNS servers
On May 14, 2014, at 3:22 AM, Jim Reid j...@rfc1035.com wrote: On 13 May 2014, at 22:51, Andrew Sullivan a...@anvilwalrusden.com wrote: Check every name using your nameservers at the parent side for glue before renumbering. If only it was that simple Andrew. :-) A delegation in TLD1 might point at a name in TLD2. So when the reference count for ns.foo.tld2 drops to zero, the registry deletes it from the DNS even though there's an NS record with RDATA for ns.foo.tld2 in TLD1. ISTR this caused some pain when org was separated from the Verisign registry. I think at that time nameserver objects in the SRS were shared across all three TLDs. I recall a great deal of pain when renumbering a nameserver and folks would keep re-registering it, or a name on that IP address that I was trying to move them all away from back in 96-97 timeframe. Now we have something that's perhaps 'equally' bad which is there are many names in the TLDs that point to the same IP address, eg: Aborting search 50 records found . NS7.HANGGORO.COM TITAN.LOSTSERVER.NET NS2.ATOPIA.NET C.NS.OTAHUNA.NET NS2.GREYBEAM.NET NS3.AGYEI.NET NS3.CRYSTALONE.NET C.NS.THORIUMINVESTMENTS.COM C.NS.OSMIUMGLOBAL.COM NS2.KARDINGS.COM NS2.PATEDMA.COM NS3.HIJINKS.COM C.NS.MAILFORWARDED.COM NS2.ETEAMBUILD.COM NS4.SIDEBARDISABLER.NET NS1.PRIORITYLANE.COM DNS2.GRANABIKE.COM NS3.MICRODUAL.COM NS2.TETRO.NET NS3.BACASOFT.COM NS2.XENONCORE.NET NS2.DGSI.COM NSFICKDICH.CSE-SERVER.COM NS7.DNS-DIENST.NET NS2.PCH.NET NS2.QLOGICS.COM NS2.KEITHLAMCPA.COM C.NS.OSMIUM-INVESTMENTS.COM NS2.POPUTKA.COM NS3.QLOGICS.COM NS2.FETTLE.NET NS2.PEDANT.NET NS2.MOTORTRAK.COM NS2.CMUNGERJR.COM NS2.MISSALAINEOUS.COM B.NS.QMUTE.COM B.NS.SUREJOURNEY.COM B.NS.QONTIX.COM NS2.BITLANCER.NET NS2.LYONOPENLAB.NET NS3.SIDOPORT.COM NS02.SPYRO.NET NS3.MZANSIDNS.NET NS4.VITTGAM.NET NS4.CAIZHENGZHU.COM NS3.IDOPORT.COM B.NS.CATAAFFE.COM NS2.PRIMADESIGN.COM NS2.SPRIXA.COM NS6.OFLOO.NET I'm sure there are more as well.. the worst part is some have and some have both and A.. - Jared ___ 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] AAAA record for c.root-servers.net
On Mar 31, 2014, at 5:08 PM, Mark Andrews ma...@isc.org wrote: Yes. I posted the output for networks which cannot reach c.root-servers.net over IPv6. Basically anyone using Hurricane Electric. This is well known that Cogent (nee c.psi.net - c.root-servers) is not connected to Hurricane Electric. It's odd that their IPv4 works between the networks and not IPv6 as the ISPs involved should have congruent policies for each AFI. I suspect there's something strategic being done on the part of one of them in not keeping the policies the same. The good news is the software will work around servers that don't respond. If your software is buggy it can always be upgraded. - Jared ___ 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] bind-9.9.4-P1 crash
FYI: https://kb.isc.org/article/AA-01078 On Dec 17, 2013, at 9:00 PM, Jared Mauch ja...@puck.nether.net wrote: Anyone seen this crash:? I’m hitting it fairly often right now and trying to poke at the code for triage: ___ 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] bind-9.9.4-P1 crash
Anyone seen this crash:? I’m hitting it fairly often right now and trying to poke at the code for triage: 17-Dec-2013 20:56:03.138 general: name.c:1727: INSIST(offset = length) failed, back trace 17-Dec-2013 20:56:03.138 general: #0 0x43140d in ?? 17-Dec-2013 20:56:03.138 general: #1 0x7622517a in ?? 17-Dec-2013 20:56:03.138 general: #2 0x77873536 in ?? 17-Dec-2013 20:56:03.139 general: #3 0x77877b8d in ?? 17-Dec-2013 20:56:03.139 general: #4 0x432590 in ?? 17-Dec-2013 20:56:03.139 general: #5 0x4367a6 in ?? 17-Dec-2013 20:56:03.139 general: #6 0x440c1f in ?? 17-Dec-2013 20:56:03.139 general: #7 0x445c19 in ?? 17-Dec-2013 20:56:03.139 general: #8 0x426bef in ?? 17-Dec-2013 20:56:03.139 general: #9 0x76247836 in ?? 17-Dec-2013 20:56:03.139 general: #10 0x75dfcf33 in ?? 17-Dec-2013 20:56:03.139 general: #11 0x75b2aead in ?? 17-Dec-2013 20:56:03.139 general: exiting (due to assertion failure) Seems to perhaps be with a specific QNAME (gdb) bt #0 0x75a6bc59 in raise () from /usr/lib64/libc.so.6 #1 0x75a6d368 in abort () from /usr/lib64/libc.so.6 #2 0x004315d6 in assertion_failed (file=optimized out, line=optimized out, type=optimized out, cond=optimized out) at ./main.c:218 #3 0x7622517a in isc_assertion_failed () from /usr/lib64/libisc.so.95 #4 0x77873536 in set_offsets () from /usr/lib64/libdns.so.100 #5 0x77877b8d in dns_name_copy () from /usr/lib64/libdns.so.100 #6 0x00432590 in query_findclosestnsec3 (qname=qname@entry=0x726b6810, db=db@entry=0x7fffe73d82b0, version=version@entry=0x0, client=client@entry=0x7fffe8132e10, rdataset=0x7fffed088b00, sigrdataset=0x7fffed0880f0, fname=0x7fffed0850b0, exact=exact@entry=isc_boolean_true, found=found@entry=0x726b6810) at query.c:5337 #7 0x004367a6 in query_addwildcardproof (client=optimized out, db=0x7fffe73d82b0, version=0x7fffe73d0590, name=optimized out, ispositive=ispositive@entry=isc_boolean_false, nodata=nodata@entry=isc_boolean_false) at query.c:3482 #8 0x00440c1f in query_find (client=0x7fffe8132e10, event=event@entry=0x0, qtype=optimized out, qtype@entry=12) at query.c:6686 #9 0x00445c19 in ns_query_start (client=client@entry=0x7fffe8132e10) at query.c:7794 #10 0x00426bef in client_request (task=optimized out, event=optimized out) at client.c:1939 #11 0x76247836 in run () from /usr/lib64/libisc.so.95 #12 0x75dfcf33 in start_thread () from /usr/lib64/libpthread.so.0 #13 0x75b2aead in clone () from /usr/lib64/libc.so.6 QNAME available in private for those that I trust. - Jared ___ 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] summary of recent vulnerabilities in DNS security.
On Oct 22, 2013, at 7:42 AM, Daniel Kalchev dan...@digsys.bg wrote: I for one, do not believe DNSSEC is any difficult. I have turned DNSSEC wherever I can. It has become easier and easier in the past few years to the point I would call deploying DNSSEC today trivial. I have therefore changed my stance with people considering DNSSEC deployment from careful, this stuff needs special attention to good, encourage those guys. See, I can answer such questions. Why can't others? It's difficult because there is not universal support amongst registrars. Once again the wheel gets stuck when the technical side meets the business side. Before someone says switch registrar, it's usually not that easy and then becomes something resembling a full time project vs just throwing a switch. Edit a zone file vs edit, run a script, upload some keys, roll some keys, do some other magic is harder than edit a zone file. This runs into the same friction issue that using PGP and other tools encounter. It seems simple enough to most folks, but when you add in someone less-technical, it goes off the rails quickly. I can't count the number of times someone emailed me their full keyring or private key when they meant public. It's not as easy as you think it is. - Jared ___ 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] Should medium-sized companies run their own recursive resolver?
On Oct 17, 2013, at 4:09 AM, Daniel Kalchev dan...@digsys.bg wrote: On 17.10.13 00:12, Jared Mauch wrote: Even small networks (I have a friend with a ~100 user wisp) shouldn't run their own caches. The economics of it don't support this. Care to elaborate on this economic problem? Just an reference point: Most of today's smartphones already have more resources than the DNS resolvers many small ISPs already use and those ISPs don't suffer from any kind of trouble because of that. And, these smartphones are considered disposable tech. He's power/space constrained in some locations. It's also not cheap to get equipment that will run in a shed at the base of a tower that's not climate controlled. There is some hardware that could be used for this, but the cost of pointing at his upstream or someone else is much lower and reduces any possible OPEX on his side for it. There's also the need for monitoring, care and feeding, etc.. 100 subscribers and not a lot of profit means lack of capital to invest. easier to just outsource to upstream/3rd party. Also, customer CPE equipment is poor and doesn't scale well for the current rate of DNS queries needed to load a webpage and the volume of devices now in the home. Many pages will require 100+ elements or DNS queries to transact the basics. This means tech support calls for network is down or intermittent that require hard-coding to work around the busted CPE gear. (e.g.: use these resolvers instead of those i just got from DHCP). He's small so ends up making house calls to fix things for those that are unable to do it themselves. - Jared ___ 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] Should medium-sized companies run their own recursive resolver?
Comcast doesn't give me broken name servers to use, there is no cognitive dissonance here :-) You are a DNS expert. Most end users when DNS fails think everything has failed, including the network. I type URLs into my browser. Do you know how many people type google into the google search box? Or the yahoo box? You seem disconnected from the average user and average user tech support. Even small networks (I have a friend with a ~100 user wisp) shouldn't run their own caches. The economics of it don't support this. - Jared On Oct 16, 2013, at 10:37 AM, Vernon Schryver v...@rhyolite.com wrote: Folks like Comcast have large validating resolvers. Their customers ] should use them. despite https://www.google.com/search?q=COMCAST+dns+hijacking If you check the pages found by that URL, you'll see - older reports that Comcast was phasing out DNS hijacking - more recent reports of redirection or hijacking of 58/UDP packets--not just falsified results from those big Comcast DNS servers but packet hijacking - far more complication, confusion, and mystification than is realistic to expect a two person IT department to resolve. ___ 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] Should medium-sized companies run their own recursive resolver?
On Oct 15, 2013, at 2:12 AM, Peter Koch p...@denic.de wrote: sure. Yet another instance of the DNS people have said Come on. This is akin to asking the founding member of the local mercedes car club what sort of car you should get. :) sarcasmIs there something wrong with this?/sarcasm - Jared ___ 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] Should medium-sized companies run their own recursive resolver?
On Oct 15, 2013, at 4:58 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: On Oct 15, 2013, at 1:36 PM, Jared Mauch ja...@puck.nether.net wrote: On Oct 15, 2013, at 2:12 AM, Peter Koch p...@denic.de wrote: sure. Yet another instance of the DNS people have said Come on. This is akin to asking the founding member of the local mercedes car club what sort of car you should get. :) sarcasmIs there something wrong with this?/sarcasm It could have been, but the responses were a few on one pole, a few on the other, and a lot of it depends. Some of the it depends responses leaned in one direction, but some leaned in the the other. And I don't think anyone said Mercedes... Have you ever driven one? They are mighty nice :) Back in the 90's I would agree everyone should run a DNS server as the network wasn't as robust as it is today. Some folks may need local elements (e.g.: MS DNS/AD, but these should not be exposed to the internet. They lack the ability to scope responses based on the query source to prevent them being global open resolvers. They are just fine for behind a firewall/NAT to take stub queries and meet the internal IT needs. Everyone else should just use either their ISP (with NXDOMAIN rewriting turned off) or someone like OpenDNS that can help enforce some security policies and practices with a few knobs being turned at most. Folks like Comcast have large validating resolvers. Their customers should use them. Folks here are surely going to do the right thing the majority of the time. The vast majority of others are going to set things up once and it *will* be left to rot. This isn't intentional, but it naturally happens. - Jared ___ 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] Should medium-sized companies run their own recursive resolver?
I'll say no. They don't have resources to deal with 98 angry users when DNS fails. Using OpenDNS or the ISP is likely the best choice. Most large ISP dns servers are good. Jared Mauch On Oct 14, 2013, at 7:08 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: A fictitious 100-person company has an IT staff of 2 who have average IT talents. They run some local servers, and they have adequate connectivity for the company's offices through an average large ISP. Should that company run its own recursive resolver for its employees, or should it continue to rely on its ISP? --Paul Hoffman ___ 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 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] OpenResolver Statistics Updated
I've reprocessed some data on the OpenResovlerProject and wanted to share some results. 1) I stopped filtering on if the #answers was 0 on the query to determine the alternate ip in the data. This filter was originally in-place because I thought DNS implementations were sane/good. They are not ;) OLD RESULTS: data_date | alternate +--- 2013-03-24 |654122 2013-03-31 |655030 2013-04-07 |731040 2013-04-14 |914175 2013-04-21 |812921 2013-04-28 |795565 2013-05-05 | 1188210 2013-05-12 |811517 2013-05-19 |781274 2013-05-26 |778730 2013-06-02 |797657 2013-06-09 |890517 2013-06-16 |776594 2013-06-23 |804478 2013-06-30 |798410 2013-07-07 |808724 2013-07-14 |819078 2013-07-21 |919887 2013-07-28 |908050 2013-08-04 |988527 2013-08-11 |835917 2013-08-18 |823313 2013-08-25 |785411 2013-09-01 |920041 2013-09-08 |833074 2013-09-15 | 1026649 (26 rows) New Results: data_date | alternate +--- 2013-03-24 |787771 2013-03-31 |792139 2013-04-07 |862110 2013-04-14 | 1055201 2013-04-21 |960058 2013-04-28 |967275 2013-05-05 | 1345394 2013-05-12 |996038 2013-05-19 |959157 2013-05-26 |970176 2013-06-02 | 1000718 2013-06-09 | 776 2013-06-16 |980098 2013-06-23 | 1006528 2013-06-30 | 1012998 2013-07-07 | 1020873 2013-07-14 | 1044292 2013-07-21 | 1161634 2013-07-28 | 1136955 2013-08-04 | 1224921 2013-08-11 | 1085401 2013-08-18 | 1094469 2013-08-25 | 1035215 2013-09-01 | 1159322 2013-09-08 | 1116035 2013-09-15 | 1026649 (26 rows) 2) I also reprocessed looking for TC=1 in responses and found interesting clusters of IP ranges that always respond with TC=1 but never provide UDP. Some others just force TCP for everything. 3) I started collecting the TTL responses to packets this past week. Not sure who else is collecting this type of data, but any ideas of graphs, etc.. you want related to this, let me know. I could create a weekly graph showing the distriubtion of all responses. - Jared ___ 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] Implementation of negative trust anchors?
On Aug 22, 2013, at 3:59 PM, wbr...@e1b.org wrote: Running the DNS for 100+ school districts and 400,000+ devices, I really, REALLY don't want to be the one saying Sorry, you can't use the site called for in your lesson plan today because they messed up the DNSSEC records. Management's response would be Just make it work! Without a per domain NTA, the only option would be to turn off DNSSEC, returning to square one. I wanted to point out this is a semi-false premise. If you were dependent on the resources, you would be pulling circuits or hosting those sites in-house. I see this argument made about availability in an absolute sense and one can't control the entire ecosystem. OpenDNS didn't just start charging enterprises because they could, they did it as a result of people realizing they were dependent on resources where they had no contractual relationship or SLA. - Jared ___ 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] Geoff Huston on DNS-over-TCP-only study.
BTW, The goal of OpenResolverProject was to have an inventory so folks could measure against attacks and determine what % of attacks utilized them. The list is available in weekly format to security teams to download in bulk so they can use tools like GrepCidr to perform this cross-reference. The unexpected results of the data were knowing that ~46% are just a broken CPE device that does something weird with DNS packets. BCP-38 isn't going to resolve the DDoS threat, but does close some of the attack surface. A number of folks are doing derivative research with the data as well. You can use the broken CPE devices to measure BCP-38 compliance, and I've been working with at least two different university research teams to help them understand the data. I'd love for more people to dive into it, and any help I can provide in collecting better data (some folks want the UDP reply TTLs captured for example) I'm interested to know about. I've also thought about doing an actual TCP/53 scan as well and send the query over TCP to measure how many reply there. (I have some TC=1 responses in my weekly scan results). The name and shame side-effect is helpful to drive interest, as well as presentations at various meetings. Personally, I see some of the larger threats being the lack of rigorous CPE testing, the fact that many want to be your DNS proxy, and unmanaged VPS/VM solutions that exist out there. - Jared On Aug 21, 2013, at 6:00 AM, Geoff Huston g...@apnic.net wrote: Yes, our goal was to test out the asserting in RFC5966 that: The majority of DNS server operators already support TCP and we wanted to see if we could quantify what that majority actually was. What we found out was that of the DNS resolvers that were visible to the authoritative name server, some 83% of them did use TCP following the reception of a truncated UDP response, and the failing 17% of these visible resolvers were used by 6% of the end clients. Of these affected clients, 2/3 of them then used alternate resolvers that did perform TCP, while the remaining 2% were stranded and were unable to complete the name resolution process. But that is just one part of the total story, and a TCP-based resolver is more vulnerable to various forms of SYN flooding attacks as Paul points out. Of course you could always turn to stateless TCP (http://www.potaroo.net/ispcol/2009-11/stateless.html) but while that effort was a more light hearted response to the issue, the issue of TCP server scaling and vulnerability to SYN attack is nevertheless a serious one. On the other hand its no more serious than any other form of small TCP transaction based services that are subjected to massive volumes, such as, say, a search engine front end. We've seen a variant of this scaling discussion in a number of domains, and there is a common theme running along here: as the internet grows the servers that support its function need to grow as well. While part of the answer may well be selective TCP session rate limiting and other TCP smarts that reduce the per-TCP-session resource footprint in the server, another part of the answer may simply be that being a DNS authoritative server today simply needs more grunt than yesterday. (Its not just the population of clients and the query loads that can be imposed on servers - its also related to our efforts to increase the information load in the DNS. As an illustration of this in the context of DNSSEC I did some measurements on the amount of additional queries and additional traffic we see from a DNSSEC-signed name as compared to a unsigned name earlier this year when using the client - our results and estimates of the increase in traffic and query loads are at http://www.iepg.org/2013-07-ietf87/2013-07-28-dnssec.pdf) Geoff On 21/08/2013, at 4:27 PM, George Michaelson g...@apnic.net wrote: I believe our goal was to find out how many clients, measured by resolver, failed to complete a TCP forced DNS query. Other people will be looking at the server side, that wasn't what we were primarily exploring. People who want to consider TCP based DNS need both sides of the questionspace filled, so choosing to analyse client failure isn't the whole picture, but it is part of the picture. ___ 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 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] bind + client-subnet
On Aug 13, 2013, at 1:43 AM, Evan Hunt e...@isc.org wrote: Do you mean the BIND views? It has been there for many years. http://www.zytrax.com/books/dns/ch7/view.html I believe Jared meant this: http://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-02 Correct. I'm not sure how accurate this really is, but: http://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/ Basically, it helps pass the client IP upstream so the CDN can make a better guess to which cluster to direct you to, instead of the query-source IP of the recursive they are talking to. We've seen poor CDN performance as a result of them only being granular to a /24 scope, as well as folks using the 'wrong' dns servers and being sent to CDN nodes a few networks or continents away. - Jared ___ 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] bind + client-subnet
On Aug 13, 2013, at 6:47 AM, Ken Peng p...@att.net wrote: On 2013-8-13 18:30, Jared Mauch wrote: I'm not sure how accurate this really is, but: http://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/ Basically, it helps pass the client IP upstream so the CDN can make a better guess to which cluster to direct you to, instead of the query-source IP of the recursive they are talking to. but how to implement that? since local DNS server always has caching. The CDNs typically do this through chained CNAMES, with one of them having a low TTL. ;; ANSWER SECTION: swcdn.apple.com.3242IN CNAME swcdn.apple.com.akadns.net. swcdn.apple.com.akadns.net. 38 IN CNAME swcdn.apple.com.c.footprint.net. - Jared ___ 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] bind + client-subnet
Does anyone know if BIND supports the client-subnet option, or do I need to seek another recursive resolver for this? it does seem there are some patches, but I'm not sure if this is something others have experimented with, e.g.: http://wilmer.gaa.st/edns-client-subnet/ We operate a large recursive resolver infrastructure and I'm thinking the users will be best served with this option set to be directed to local CDN caches. Wanted to ask about what others were doing before I went to our dns group. - Jared ___ 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] 20130625 survey version.bind
The openresolver project surveyed version.bind from those resolvers that respond from port 53 based on the 20130616 dataset. I know this will be of value to some people in understanding what resolvers may be reaching their systems. Here are the results: http://openresolverproject.org/version.bind.20130616.20130625.parsed.txt Enjoy! - Jared ___ 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] That’ll never work–we don’t allow port 53 out | Strategic Cyber LLC
On Jun 21, 2013, at 7:24 AM, Mike Jones m...@mikejones.in wrote: http://code.kryo.se/iodine/ allows you to set up a full IP(v4) VPN over DNS. Obviously a VPN type setup with IP packet headers and TCP retransmits etc doesn't help performance compared to a program implementing its own data channel over DNS, but it does mean it works with unmodified software. SSH over DNS is usable when there's literally no other option, but you're probably not going to have much luck with youtube. You're not going to tunnel over ssh over dns to get to your SQUID proxy? :) These things always interest/amuse me when folks try to find a way around airgapped means airgapped between networks that need to be secured. That includes removable media. - Jared ___ 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] That?ll never work?we don?t allow port 53 out | Strategic Cyber LLC
On Jun 21, 2013, at 2:57 PM, Lawrence K. Chen, P.Eng. lkc...@ksu.edu wrote: Wonder about all the other people that run their own DNS (and such) on campusOne time the physics department was all angry that we (central IT) had changed the size of a DNS packet to be larger than 512-bytes on them. Forget if I ever mentioned that DNS isn't just udp Just start replying to them with TC=1 on all packets for a day. They will figure it out. - jared ___ 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] Querying version.bind illegal?
On May 23, 2013, at 9:53 AM, Jim Reid j...@rfc1035.com wrote: On 23 May 2013, at 14:39, Vitalie Cherpec vita...@penguin.ro wrote: I would like to know if querying version.bind is illegal (in some countries)? Ask a lawyer or policeman in those countries. It's hard to see how such largely useless queries could be illegal or result in a successful prosecution. Or get you extradited. Then again, some countries have very strange laws and extradition treaties. IANAL, http://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act The CFAA defines a “protected computer” under 18 U.S.C. § 1030(e)(2) to mean a computer: • which is used in or affecting interstate or foreign commerce or communication, including a computer located outside the United States that is used in a manner that affects interstate or foreign commerce or communication of the United States... (Seems a DNS server would possibly fall into this category) Looking at a.2.C, it could apply to anything a DNS server replies with. Then again, it's a server so meant to be a public item, so I wouldn't be concerned. - Jared ___ 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] [ratelimits] bind force qtype=ANY to TCP
On May 15, 2013, at 8:40 PM, Jared Mauch ja...@puck.nether.net wrote: I fixed the patch by moving where it does this check to before query_find as opposed to inside it. Thanks for the insight and input. It looks like some people deployed this patch (or at least downloaded it based on user-agents with CURL and Wget). I thought I'd share statistics seen on my DNS server: http://puck.nether.net/~jared/bind-tcp-any-stats.txt I have a feeling that it's not counting the stats properly when it sends a truncate on an ANY query, I should perhaps look at that later. If you're also running this patch, I'm interested in hearing of your experiences. - Jared ___ 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] bind-9.9.3rc2 ANY+TCP patch
On May 15, 2013, at 5:09 PM, Matthäus Wander matthaeus.wan...@uni-due.de
wrote:
* Vernon Schryver [2013-05-15 21:40]:
From: Jared Mauch ja...@puck.nether.net
This is a crude but effective hack. It doesn't stop the system from
recursing to find the response.
I can understand simplistic DNS reflection mitigation in firewalls,
especially when response rate limiting is not available in the DNS
server implementation or when local policies forbid the use of patches.
I don't understand why would one use a patch like that with its
limitations and drawbacks (e.g. usable only on recent versions of
BIND9, affects only ANY, affects all ANY, doesn't limit the flood of
reflected truncated responses during attacks, no whitelisting for local
clients, not view-specific) instead of the full blown RRL patch for
9.9.3rc2, 9.9.2, 9.9.2-P1, 9.9.2-P2, 9.8.4-P2, 9.8.4-P1, or 9.8.5rc2.
By the way, why use qtype == 255 instead of qtype == dns_rdatatype_any ?
Why #define TCP_CLIENT() and use the macro exactly once instead
something like
if (qtype == dns_rdatatype_any
(client-attributes NS_CLIENTATTR_TCP) != 0) {
If TCP_CLIENT() is used in query.c, then its definition should be moved
from client.c to bin/named/include/named/client.h and the several uses
of client-attributes NS_CLIENTATTR_TCP in query.c replaced with
TCP_CLIENT(). It's bad form to define macros (or much of anything)
more than once, because you can be sure that eventually the definitions
will differ.
I think the keyword here is hack. I wouldn't invest too much time in
an analysis.
Thanks :)
Yes, the idea here is that most of this attack traffic is of type=ANY.
If I invested more than 30 minutes, I could put in configuration directives
around this as well making it an option to set.
What I have noticed in the past is someone better than myself has usually
reimplemented these patches to make things better. (e.g.: FreeBSD raw socket in
jail patch)
(for Vernons knowledge, I thought TCP_CLIENT wasn't limited to just that one .c
file, so when it failed to compile I lazily stole that line of code and put it
immediately before it, hence it's poor location as well).
I've cleaned up the patch (it should be == 0 now btw, the above code correction
is wrong).
If others want, I can look at putting in a config directive. It would be
possible to add other RRtypes easily enough that should get TCP only that are
not commonly used.
- Jared
___
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] bind-9.9.3rc2 ANY+TCP patch
One more comment: This patch only impacts recursive servers, not authorities. They won't set TC=1 for an ANY query. - Jared On May 15, 2013, at 6:03 PM, Jared Mauch ja...@puck.nether.net wrote: On May 15, 2013, at 5:58 PM, John Kristoff j...@cymru.com wrote: On Wed, 15 May 2013 17:52:11 -0400 Jared Mauch ja...@puck.nether.net wrote: If others want, I can look at putting in a config directive. It would be possible to add other RRtypes easily enough that should get TCP only that are not commonly used. I can speak for others, but I would prefer to use the RRL code already pretty well tested and being implemented in various name server implementations already. I would recommend others do so as well. http://www.redbarn.org/dns/ratelimits Why would someone choose to use your patch over RRL? Because of the FP ratio presented at the DNS-OARC meeting this past week. It's suitable on a recursive resolver, where RRL is most effective on an authority. See https://indico.dns-oarc.net/indico/getFile.py/access?contribId=4resId=0materialId=slidesconfId=0 Page #12 This effectively does slip=1 and does away with any amplification and just makes it a pure reflection attack. Still not ideal, but doesn't amplify. - jared ___ 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] bind-9.9.3rc2 ANY+TCP patch
On May 15, 2013, at 6:52 PM, Vernon Schryver v...@rhyolite.com wrote: This effectively does slip=1 and does away with any amplification and just makes it a pure reflection attack. Still not ideal, but doesn't amplify. On the contrary, as I just now wrote in the ratelimits mailing list http://lists.redbarn.org/mailman/listinfo/ratelimits your patch does not affect amplification by authorities. For example, if applied to an authority for isc.org, `dig +dnssec isc.org any @ams.sns-pb.isc.org' would still reflect almost 4 KBytes for each 60 byte ANY request. The folks that are most concerned with RRL are those expecting queries from stub resolvers, I think this would mitigate this risk. - Jared ___ 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] [ratelimits] bind force qtype=ANY to TCP
On May 15, 2013, at 8:03 PM, Vernon Schryver v...@rhyolite.com wrote: I think the patch has a false negative rate of approximately 100%. To check whether I am wrong again, I set up a test server and tried two `dig +ignore isc.org any` commands. The first got a TC=1 error response as expected. The second command got 3500 bytes of RRs via UDP. I expect (but haven't tested) that all subsequent queries get normal responses until all of the TTLs expire. Heh, you're right. I'll have to tweak where that code happens… puck:~$ dig any nothing.cnn.com. @204.42.254.5 ;; Truncated, retrying in TCP mode. ; DiG 9.9.3-rl.131.14rc2 any nothing.cnn.com. @204.42.254.5 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 33076 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;nothing.cnn.com. IN ANY ;; AUTHORITY SECTION: cnn.com.3600IN SOA ns1.timewarner.net. hostmaster.turner.com. 2013051301 28800 7200 604800 3600 ;; Query time: 1 msec ;; SERVER: 204.42.254.5#53(204.42.254.5) ;; WHEN: Wed May 15 20:16:00 EDT 2013 ;; MSG SIZE rcvd: 116 puck:~$ dig any nothing.cnn.com. @204.42.254.5 ; DiG 9.9.3-rl.131.14rc2 any nothing.cnn.com. @204.42.254.5 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 34337 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;nothing.cnn.com. IN ANY ;; AUTHORITY SECTION: cnn.com.3593IN SOA ns1.timewarner.net. hostmaster.turner.com. 2013051301 28800 7200 604800 3600 ;; Query time: 1 msec ;; SERVER: 204.42.254.5#53(204.42.254.5) ;; WHEN: Wed May 15 20:16:07 EDT 2013 ;; MSG SIZE rcvd: 116 ___ 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] Multiple A/AAAA RRs associated with an NS RR
I think many of the problems we saw back in the win95/98 days with stickiness of DNS records have mostly been resolved. Most software does the right thing these days. Jared Mauch On May 3, 2013, at 6:45 PM, Simon. Munton simon.mun...@communitydns.net wrote: We were curious about this. As a quick test we set up a zone with two name servers with two ipv4 addresses each. All four addresses received roughly the same query load and we saw no resolution issues, but made no real attempt to search them out, this was just based on polling various (open) resolvers. ___ 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 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] open resolver version.bind responses
On Apr 16, 2013, at 8:52 AM, Jared Mauch ja...@puck.nether.net wrote: On Apr 16, 2013, at 8:21 AM, Jared Mauch ja...@puck.nether.net wrote: Greetings, I took the latest 'Open Resolver' list and queried the hosts another time with a version.bind query. You can view the results here: Ok, I didn't expect everyone to post this to twitter/facebook so fast :) FYI: The data in the OpenResolverProject is available for derivative works. I don't want to directly share where to find the lists of data, but some notes about it. 1) We run a weekly query for a unique name per IP 2) We match the response w/ query and note mismatches 3) I have per-ASN (ask your network people what it is) reports available if you email me from a corporate email address for your domain. Same if you are a national CERT. 4) The queries take ~6.5 hours to run ; Don't try to bulk scrape the data, it's easier to just ask/trick me or run your own scan. 5) I log the full response packet for the weekly scan. There are interesting sets of data encoded in there. 6) Many IPs repeat SERVFAIL for days/weeks after the query 7) Many hosts respond from a port other than 53 (!) meaning while they are a resolver, they are 'broken'. Some basic weekly summary data is available here: http://www.openresolverproject.org/breakdown.html If there's something specific you want parsed out of the responses, let me know and I can automate it. Here's an updated list based on the 20130421 results: http://openresolverproject.org/version.bind.20130421.final.txt - Jared ___ 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] [Off-topic] DNS dataset for academic research
The openresolverproject has weekly results from its survey of the ipv4 space, including response. It's available for ongoing research and derivative work. Jared Mauch On Apr 18, 2013, at 11:28 AM, Joe Abley jab...@hopcount.ca wrote: On 2013-04-18, at 11:24, Kaio Rafael kaioraf...@dcc.ufam.edu.br wrote: I am looking for a DNS dataset for academic research. I have been studying .BR DNS dataset (DITL 2008 on DNS-OARC servers), however, I would like to investigate more recent traffic. What are you looking for? Data from authority-only servers (which ones?), recursive servers, something else? Packet captures, something else? What sample period do you need? Do you need a continuous/complete set of data within that window, or samples? How recent? Joe ___ 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 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] open resolver versio.bind responses
I'm going to automate some graphs 'soon'. As I mentioned here and elsewhere, the methodology has been tweaked slightly in the past few weeks and has exposed a few more than the last week. The last change is happening on 4-21. I'm going to start showing more data, but my time has been limited due to $dayjob and $family. I don't expect that to get any better in the next month, so anyone interested in helping with the data, I'm looking for people to come up with ideas of what to present/show. - jared On Apr 17, 2013, at 11:15 AM, L. Aaron Kaplan kap...@cert.at wrote: Jared, I did a very similar tracking of number of open recursive DNS Servers for my pet wireless ISP. We reduced the # of ORNs from ~ 260 to 7 in half a year. So, these things are possible! http://ormon.funkfeuer.at/ http://ormon.funkfeuer.at/stats.png I have a feature request for openresolverproject.org: please make such a graph as above and put it on the front page. This way, people (network operators etc) get some visual feedback on the global efforts. This visual feedback is very helpful when you ask people to clean up. The source code for my scripts is here: https://github.com/aaronkaplan/open-recursor-check (might want to copy paste adapt the scripts for generating the graphs) --- // L. Aaron Kaplan kap...@cert.at - T: +43 1 5056416 78 // CERT Austria - http://www.cert.at/ // Eine Initiative der nic.at GmbH - http://www.nic.at/ // Firmenbuchnummer 172568b, LG Salzburg ___ 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] open resolver versio.bind responses
Greetings, I took the latest 'Open Resolver' list and queried the hosts another time with a version.bind query. You can view the results here: http://openresolverproject.org/version.bind.report.txt - jared ___ 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] open resolver version.bind responses
On Apr 16, 2013, at 8:21 AM, Jared Mauch ja...@puck.nether.net wrote: Greetings, I took the latest 'Open Resolver' list and queried the hosts another time with a version.bind query. You can view the results here: http://openresolverproject.org/version.bind.report.txt Ok, I didn't expect everyone to post this to twitter/facebook so fast :) FYI: The data in the OpenResolverProject is available for derivative works. I don't want to directly share where to find the lists of data, but some notes about it. 1) We run a weekly query for a unique name per IP 2) We match the response w/ query and note mismatches 3) I have per-ASN (ask your network people what it is) reports available if you email me from a corporate email address for your domain. Same if you are a national CERT. 4) The queries take ~6.5 hours to run ; Don't try to bulk scrape the data, it's easier to just ask/trick me or run your own scan. 5) I log the full response packet for the weekly scan. There are interesting sets of data encoded in there. 6) Many IPs repeat SERVFAIL for days/weeks after the query 7) Many hosts respond from a port other than 53 (!) meaning while they are a resolver, they are 'broken'. Some basic weekly summary data is available here: http://www.openresolverproject.org/breakdown.html If there's something specific you want parsed out of the responses, let me know and I can automate it. - Jared ___ 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] open resolver versio.bind responses
On Apr 16, 2013, at 10:39 AM, Roy Arends r...@dnss.ec wrote: On Apr 16, 2013, at 1:21 PM, Jared Mauch ja...@puck.nether.net wrote: Greetings, I took the latest 'Open Resolver' list and queried the hosts another time with a version.bind query. You can view the results here: http://openresolverproject.org/version.bind.report.txt Interesting list. I assume that some resolvers are actually happy to try and resolve version.bind chaos txt on your behalf, and so you might see the version.bind response from either the IANA roots or some alternative servers. This could be the case. I went ahead and tweaked the code I was using to send a fixed packet to all the IPs in the list. Either way, this gives folks an idea of the challenges. The 'skbroadband' devices all need to be patched it seems. Check out the breakdown.html page for some minor details about the resolver behaviors. - Jared ___ 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] open resolver versio.bind responses
Vernon, On Apr 16, 2013, at 11:58 AM, Vernon Schryver v...@rhyolite.com wrote: From: Jared Mauch ja...@puck.nether.net Check out the breakdown.html page ... 2013-04-14 results 34030764 servers responded to our udp/53 probe 914175 servers responded from a different IP than probed 27773382 gave the 'correct' answer to my A? for the DNS name queried. 13721271 responded from a source port other than udp/53 29571967 responses had recursion-available bit set. 2827206 returned REFUSED What was heard from the 3.4 million servers that responded with neither the A RR nor REFUSED? The 2.8 million that REFUSED are significantly fewer than those mysterious 3.4 million, not to mention the 27 million functional open resolvers or the 29.5 million ostensibly open resolvers. I can point you at that file if you'd like :) In other words https://www.google.com/search?q=sisyphus seems relevant. I don't mean to suggest that the effort is not worthwhile. The work is valuable, but realism forces us to acknowledge some implications. One is that there is no hope in outreach. There is plenty of hope. I've seen the following actions taken: a) Hosting providers emailed customer base, said close your open resolver or we shut your host b) ISPs have implemented spoofing filters. NTT is one of them that has cranked the filters up as a result (at least on static routed customers). c) National CERTs have contacted the project and obtained lists of hosts/machines in their control. d) LARGE ISPs have contacted for lists of resolvers, including at least one major provider in the US. e) At least one ISP today emailed me about their former customers freaking out when they were notified of upcoming DNS server changes which might impact them (people restricting or closing open resolvers). I certainly understand the concerns here regarding mitigation and outreach, but things are happening. My changes in measurement technique aren't helping accurately measure this, but there should be some good data in the next few weeks as I've made the last tweak. The good news is the # of folks returning REFUSED keeps going up. - Jared ___ 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
