Re: [dns-operations] Strange things at C root name server
Stephane Bortzmeyer wrote: > And c.root-servers.ORG has been fixed (the most probable cause is that > they allocated the prefix to Orange Ivory Coast without noticing they > were using it). I can't help but notice the update date on the whois entry: network:Updated:2024-05-10 16:33:20 is after the closing date mentioned in this press release: https://www.cogentco.com/en/about-cogent/press-releases/4443-cogent-announces-ipv4-address-securitization-offering Cogent Announces IPv4 Address Securitization Offering WASHINGTON, D.C. April 25, 2024 — Cogent Communications Holdings, Inc. (NASDAQ: CCOI) (the “Company” or “Cogent”) yesterday announced that a special-purpose, bankruptcy remote, indirect wholly owned subsidiary of the Company has priced $206,000,000 aggregate principal amount of secured Internet Protocol version 4 (“IPv4”) address revenue term notes, Series 2024-1 (collectively, the “Notes”). The Notes will have an anticipated repayment term of five years. The Notes will be secured by certain of Cogent’s IPv4 addresses, customer IPv4 address leases and customer accounts receivables. Cogent intends to use the net proceeds of the offering for general corporate purposes. Cogent expects the Notes transaction to close on or around May 2, 2024, subject to satisfaction of various closing conditions. There can be no assurance regarding the timing of closing or that the issuance and sale of the Notes will be consummated. [...] -- Robert Edmonds ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Mysteries of DNSSEC
John Levine wrote: > The first surprise I found is that once I turned it on, nearly every > query, like 99%, asks for DNSSEC. Is this typical or do I have an odd > set of clients? If you mean the "DNSSEC OK" EDNS header flag, yeah, that's typical. I believe RFC 3225 is the relevant reference. > Another surprise is that I'm getting a lot of repeated DNSKEY queries > even though the TTL is an hour. One repeat customer is Cloudflare, > another is pfsense22.plan-gis.net, at some random company in Germany. > My theories are A) a bunch of different caches behind a load balancer, > B) a too small cache, C) buggy software. Cloudflare specifically may have many DNS resolvers behind a single IP: https://blog.cloudflare.com/cloudflare-servers-dont-own-ips-anymore "With a port slice of say 2,048 ports, we can share one IP among 31 servers." -- Robert Edmonds ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Cache efficiency (was: Re: DNS .com/.net resolution problems in the Asia/Pacific region)
Paul Vixie via dns-operations wrote: > Robert Edmonds wrote on 2023-07-20 14:50: > > a) Delegations within the same organization often reflect internal > > organizational boundaries. One team may want to give control over part > > of the namespace to another team, without handing over write permissions > > for the whole zone, so the typical solution is to carve out a child zone > > for the other team, and host that zone on the same provider as the > > parent zone. If the cloud-based DNS providers that many organizations > > use offered a more granular, less than whole zone permissions model, it > > would cut down on the number of child zones that are created solely to > > reflect intra-organizational boundaries. > > i'd hate to see us adopt a cloud-centric model. whatever we do to improve > NS-chain performance -- and i think your first two suggestions would do this > -- should also benefit the normal delegation, notify, and transfer system. I was primarily thinking of particular cloud-based DNS providers where the permissions granularity is at the zone level, and those providers could unilaterally improve their implementations to make the design pattern described above unnecessary. Now that I look at BIND's documentation [0], I think the kind of granularity that I want already exists, with an "update-policy" rule that matches a "subdomain". So you can think of this section as advice to cloud DNS providers to catch up with state-of-the-art open source DNS implementations :-) Another way of putting it is, try not to ship your org chart into the DNS delegation hierarchy if you can avoid it. Sure, if you have a hard organizational boundary between business units that operate separate infrastructure including DNS servers, by all means go ahead and introduce a zone cut, though. [0] https://bind9.readthedocs.io/en/v9_18_2/reference.html#dynamic-update-policies -- Robert Edmonds ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] Cache efficiency (was: Re: DNS .com/.net resolution problems in the Asia/Pacific region)
2001:db8::1.ipv6-literal.example. IN ;; AUTHORITY SECTION: 2001:db8::1.ipv6-literal.example. 86400 IN 2001:db8::1 Then, zones could be delegated "directly" to a nameserver IP address by embedding the literal nameserver IP addresses into these special domains. Perhaps you could use a mixture of "direct" and "indirect" nameserver address records, e.g.: example.com. NS 198.51.100.1.ipv4-literal.example. example.com. NS 198.51.100.2.ipv4-literal.example. example.com. NS 2001:db8::1.ipv6-literal.example. example.com. NS 2001:db8::2.ipv6-literal.example. example.com. NS ns1.example.net. example.com. NS ns2.example.net. Of course, that's still indirection, but the next step would be to put those zones (ipv4-literal.example and ipv6-literal.example) through the RFC 6761 special-use domain name process and reserve/define them in such a way that resolver implementations could be updated to directly synthesize the IPv4 or IPv6 literal implied by the QNAME *without* needing to actually contact the nameservers for the ipv4-literal.example or ipv6-literal.example zones. (If the SUDN process is used I'm thinking those zones should be called something like ipv4-literal.arpa and ipv6-literal.arpa.) -- Robert Edmonds ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Single label queries on Windows (11)
Petr Menšík wrote: > Even on *x nslookup and dig tools use own resolution code. That is because > they are DNS specific utilities. Not something using getaddrinfo() calls, > which common applications use. > > Is there alternative to "getent ahosts " on Microsoft systems? > Using ping for that helps in a limited way, but is not perfect. Hmm: https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname It's called "Resolve-DnsName" but the name is highly misleading since it supports a bunch of other resolution methods: -LlmnrFallback Allows falling back to the LLMNR protocol when resolving this query with DNS fails. -LlmnrNetbiosOnly Resolves this query using only the LLMNR or NetBIOS protocols. -LlmnrOnly Resolves this query using only the LLMNR protocol. -NetbiosFallback Allows fallback to the NetBIOS protocol when resolving this query with DNS fails. -NoHostsFile Skips the hosts file when resolving this query. -- Robert Edmonds ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Route 53 Unexpected geo location behavior
Dan McCombs via dns-operations wrote: > Hi everyone, > > We've stumbled upon what seems like unexpected behavior with Route 53 > returning > answers based on IP geo location to our resolvers. > > According to their documentation: > > When a browser or other viewer uses a DNS resolver that does not support > edns-client-subnet, Route 53 uses the source IP address of the DNS > resolver > to approximate the location of the user and responds to geolocation > queries > with the DNS record for the resolver's location. Here is the page that text is from, and the description of the other case (when a resolver does send an EDNS Client Subnet payload): https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-edns0.html When a browser or other viewer uses a DNS resolver that does not support edns-client-subnet, Route 53 uses the source IP address of the DNS resolver to approximate the location of the user and responds to geolocation queries with the DNS record for the resolver's location. When a browser or other viewer uses a DNS resolver that does support edns-client-subnet, the DNS resolver sends Route 53 a truncated version of the user's IP address. Route 53 determines the location of the user based on the truncated IP address rather than the source IP address of the DNS resolver; this typically provides a more accurate estimate of the user's location. Route 53 then responds to geolocation queries with the DNS record for the user's location. That text seems to be entirely consistent with nameserver behavior that sends different records to a resolver when it supplies its own IP address (or its own subnet) via the ECS option versus when it does not, because the resolver is asking for two different things. In the former case, the resolver is asking for responses tailored to a precise IP (or a precise subnet). In the latter case, the resolver is asking for responses on behalf of the whole client population that utilizes the resolver. These are not necessarily the same. > If it were using the resolver's source IP address to determine geolocation > when > no edns-client-subnet is sent, I would expect the same answers as when sending > that address as the edns-client-subnet. What's going on here? I don't see anything in these DNS responses that is inconsistent with their documentation, or with the ECS specification. If there is a performance issue with one set of records versus another (you don't really say why the differing responses matter in your email), you might try contacting the nameserver operator directly to discuss the issue. > Our resolvers are co-located with our user's instances in the same > datacenters, > so we don't configure our resolvers to send edns-client-subnet since they're > not geographically different (and in fact in the same IP blocks). This is the > first time we've had a user contact us about this, so I'm not sure if > something > changed with Route 53 recently, if this is being caused by configuration > specific to the atlassian.net zone, or if somehow we just haven't had users > notice that they were being affected by this for years. There are many ways for operators of ECS-enabled nameservers to decide how to tailor DNS responses when receiving an ECS-enabled query. Geolocation, network topology, and actual performance may all be relevant. Even if your resolver instances are receiving queries from customer instances located in the same physical data center, those customer instances may themselves be forwarding traffic from eyeballs located further away (e.g.: https://www.digitalocean.com/solutions/vpn). A data-driven approach on the part of the nameserver operator could plausibly choose to send different kinds of responses to resolvers that are serving eyeballs that are dispersed over a larger catchment area. -- Robert Edmonds ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Name servers returning incorrectly truncated UDP responses
Ondřej Surý wrote: > I am 99% sure the fpdns is wrong and this is not djbdns. The fpdns relies on > subtle differences between various DNS implementations and is often wrong > because there’s either not enough data or just not enough differences. That’s > what I’ve seen when we started with Knot DNS - the quality implementations > just > didn’t had enough differences between than because they adhered to standards > that fpdns just could not tell the difference. If you run fpdns with "-d" it will print out the queries/responses, and fpdns does observe some stereotypical (but maybe not exclusively?) djbdns behavior like dropping queries that aren't for domains the server is configured to be authoritative for. "a.ns", "b.ns" etc. is a nameserver-naming pattern used in the tinydns documentation. For the djbdns suite, tinydns only serves UDP traffic and you have to install an extra daemon called axfrdns to handle TCP queries and AXFR traffic. If you request an AXFR for a zone that axfrdns is authoritative for but your source IP isn't on its allowlist, axfrdns _exit()'s without sending anything, which is consistent with: $ dig +tries=1 +tcp +norec @e.ns.email.sonyentertainmentnetwork.com -t AXFR email.sonyentertainmentnetwork.com ;; communications error to 207.251.96.133#53: end of file Regarding the truncation behavior, the djbdns documentation states: "dnscache ends the packet before all records." It doesn't say how tinydns behaves but it looks like the code is the same. The answer count in the header is not updated, which seems to be what is upsetting the various message parsers. According to the CHANGES file: 2210 internal: response_tc() reduces len, simplifying udprespond(). ui: response_tc() now truncates immediately after query. this should work around the Squid parsing bug reported by Stuart Henderson. So I'm inclined to think they probably actually are using djbdns, or maybe a load balancer in front of djbdns. At least I don't see anything inconsistent with this being a djbdns deployment. You are right about high quality implementations not having enough subtle idiosyncratic differences to reliably distinguish between them, though. -- Robert Edmonds ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] dynect.net outage
Ralf Weber wrote:
> Moin!
>
> On 30 May 2022, at 8:34, Robert Edmonds wrote:
> >> So how do you expect the domain to be resolved if all of your out
> >> of bailiwick name server names no longer point to an IP address?
> >
> > By using the working nameservers with resolvable names specified in the
> > delegation from the parent zone, which never changed in this particular
> > case. This is what Unbound's resolution algorithm does if there are not
> > too many nonexisting nameserver target names in the child's NS RRset,
> > and what other resolver algorithms do.
> So you mean the parent provided additional records (A/) when issuing
> a referral? Otherwise I can not see how from an empty cache you can
> resolve this domain if all of the name server names supplied are NXDOMAIN.
Yes, in fact these particular records:
;; AUTHORITY SECTION:
dynect.net. 172800 IN NS ns1.dynamicnetworkservices.net.
dynect.net. 172800 IN NS ns2.dynamicnetworkservices.net.
dynect.net. 172800 IN NS ns3.dynamicnetworkservices.net.
dynect.net. 172800 IN NS ns4.dynamicnetworkservices.net.
dynect.net. 172800 IN NS ns5.dynamicnetworkservices.net.
dynect.net. 172800 IN NS ns6.dynamicnetworkservices.net.
;; ADDITIONAL SECTION:
ns1.dynamicnetworkservices.net. 172800 IN A 108.59.161.136
ns1.dynamicnetworkservices.net. 172800 IN 2600:2000:2210::136
ns2.dynamicnetworkservices.net. 172800 IN A 108.59.162.136
ns2.dynamicnetworkservices.net. 172800 IN 2600:2000:2220::136
ns3.dynamicnetworkservices.net. 172800 IN 2001:500:94:1::136
ns3.dynamicnetworkservices.net. 172800 IN A 208.78.71.136
ns4.dynamicnetworkservices.net. 172800 IN A 204.13.251.136
ns5.dynamicnetworkservices.net. 172800 IN A 108.59.161.136
ns5.dynamicnetworkservices.net. 172800 IN 2600:2000:2210::136
ns6.dynamicnetworkservices.net. 172800 IN 2001:500:94:1::136
ns6.dynamicnetworkservices.net. 172800 IN A 208.78.71.136
> > There is more than one resolver implementation, and they differ in the
> > results of resolving a zone with this type of misconfiguration, and none
> > of them are the reference implementation of DNS. So just looking at a
> > particular resolver algorithm returning SERVFAIL when encountering a
> > particular data pattern starting from a cold cache cannot tell us
> > whether the algorithm or the data is at fault.
> I agree on this, however the difference in implementation are less
> when it comes to resolving from a cold cache and all the explanations
> given so far for me point to the domain being unresolvable for all
> implementations from an empty cache.
I set up two simulations of this scenario in the zones nxdemo.mycre.ws
and nxdemosmall.mycre.ws (with wildcard TXT records '*.nxdemo.mycre.ws'
and '*.nxdemosmall.mycre.ws') in case anyone wants to test out a
particular implementation.
I get these results with Unbound:
$ for i in `seq 1 10`; do dig ${i}.nxdemosmall.mycre.ws -t TXT | grep status:;
sleep 0.2; done
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 662
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45145
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61167
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39297
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31167
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53187
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2917
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37281
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15433
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63533
$ for i in `seq 1 10`; do dig ${i}.nxdemo.mycre.ws -t TXT | grep status:; sleep
0.2; done
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52593
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5778
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17835
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6077
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33311
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46376
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 22646
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58220
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 22294
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38712
--
Robert Edmonds
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] dynect.net outage
Ralf Weber wrote: > Moin! > > On 30 May 2022, at 1:12, Robert Edmonds wrote: > > Simon Arlott via dns-operations wrote: > >> I currently have this cached list of nameservers for dynect.net: > >> > >> ;; AUTHORITY SECTION: > >> dynect.net.14931 IN NS > >> cgydc01dnsext01.us.oracle.com. > >> dynect.net.14931 IN NS > >> tvp02dnsext02.tvp.oracle.com. > >> dynect.net.14931 IN NS > >> sydc01dns03.au.oracle.com. > >> dynect.net.14931 IN NS > >> trdc01dnsext01.us.oracle.com. > >> dynect.net.14931 IN NS > >> adc08dnsext02.us.oracle.com. > >> dynect.net.14931 IN NS > >> rmdc02dnsext01.us.oracle.com. > >> dynect.net.14931 IN NS > >> llg07dnsext02.llg.oracle.com. > >> dynect.net.14931 IN NS > >> llg07dnsext01.llg.oracle.com. > >> dynect.net.14931 IN NS > >> iad-dns-master.oraclecorp.com. > >> dynect.net.14931 IN NS > >> adc08dnsext01.us.oracle.com. > >> dynect.net.14931 IN NS > >> rmdc02dnsext02.us.oracle.com. > >> ;; WHEN: Fri May 27 17:10:08 BST 2022 > >> > >> All of these hostnames are NXDOMAIN in the oracle.com/oraclecorp.com > >> zones. Looks like someone has reconfigured the nameservers for > >> dynect.net and then immediately pulled the A/ records for the old > >> names without waiting out the TTL on the old NS records. > > > > This was https://www.dynstatus.com/incidents/1xlbp98xr3y2. > So how do you expect the domain to be resolved if all of your out > of bailiwick name server names no longer point to an IP address? By using the working nameservers with resolvable names specified in the delegation from the parent zone, which never changed in this particular case. This is what Unbound's resolution algorithm does if there are not too many nonexisting nameserver target names in the child's NS RRset, and what other resolver algorithms do. > >> Unbound gives up and returns SERVFAIL for anything using dynect.net > >> because it exceeds the maximum number of NXDOMAIN responses for > >> nameserver hostnames. > Maybe this is happening where you still have the A/ record > cached for delegation, but you can’t rely on that. If a domain is > not being able to be resolved from a cold/empty cache it is broken, > and the domain owner has to deal with the consequences. End of story. There is more than one resolver implementation, and they differ in the results of resolving a zone with this type of misconfiguration, and none of them are the reference implementation of DNS. So just looking at a particular resolver algorithm returning SERVFAIL when encountering a particular data pattern starting from a cold cache cannot tell us whether the algorithm or the data is at fault. RFC 1034 (section 5.3.3) recommends that the resolver implementer prioritize the following: 1. Bound the amount of work (packets sent, parallel processes started) so that a request can't get into an infinite loop or start off a chain reaction of requests or queries with other implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED SOME DATA. 2. Get back an answer if at all possible. 3. Avoid unnecessary transmissions. 4. Get the answer as quickly as possible. (This list appears to be in order of most important to least important. Amusingly, "Get the answer as correctly as possible" is not on the list.) This particular case seems to be a straight-forward trade-off between #1, #2 and #3. -- Robert Edmonds ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] dynect.net outage
Simon Arlott via dns-operations wrote: > I currently have this cached list of nameservers for dynect.net: > > ;; AUTHORITY SECTION: > dynect.net. 14931 IN NS cgydc01dnsext01.us.oracle.com. > dynect.net. 14931 IN NS tvp02dnsext02.tvp.oracle.com. > dynect.net. 14931 IN NS sydc01dns03.au.oracle.com. > dynect.net. 14931 IN NS trdc01dnsext01.us.oracle.com. > dynect.net. 14931 IN NS adc08dnsext02.us.oracle.com. > dynect.net. 14931 IN NS rmdc02dnsext01.us.oracle.com. > dynect.net. 14931 IN NS llg07dnsext02.llg.oracle.com. > dynect.net. 14931 IN NS llg07dnsext01.llg.oracle.com. > dynect.net. 14931 IN NS iad-dns-master.oraclecorp.com. > dynect.net. 14931 IN NS adc08dnsext01.us.oracle.com. > dynect.net. 14931 IN NS rmdc02dnsext02.us.oracle.com. > ;; WHEN: Fri May 27 17:10:08 BST 2022 > > All of these hostnames are NXDOMAIN in the oracle.com/oraclecorp.com > zones. Looks like someone has reconfigured the nameservers for > dynect.net and then immediately pulled the A/ records for the old > names without waiting out the TTL on the old NS records. This was https://www.dynstatus.com/incidents/1xlbp98xr3y2. > Unbound gives up and returns SERVFAIL for anything using dynect.net > because it exceeds the maximum number of NXDOMAIN responses for > nameserver hostnames. I opened a bug report against Unbound here: https://github.com/NLnetLabs/unbound/issues/687 This was apparently a mitigation for "NX NS Attack": https://nlnetlabs.nl/downloads/unbound/CVE-2020-12662_2020-12663.txt Well, Petr warned us: https://en.blog.nic.cz/2020/05/19/nxnsattack-upgrade-resolvers-to-stop-new-kind-of-random-subdomain-attack/ Unlike traditional random subdomain attacks, in case of NXNSAttack queries are generated by resolver itself. This difference allows vendors to implement simple mitigation techniques like limiting number names resolved when processing a single delegation etc. Obvious advantage is that it is simple, at least in theory. Disadvantage of mitigation based on counters is that it requires vendors to invent arbitrary limits not based in the DNS protocol specification, basically determining maximum packet amplification factor. At the same time these arbitrary limits might break resolution for some domains because they put additional limits on the resolution process. This is a very practical problem because recently published research estimates that 4 % of second-level domains (example.com.) have a problem in their delegation from top-level (com.), so any change which adds arbitrary limits to retries during resolution process has to be weighted very carefully. In upcoming days we will see how successful vendors were in determining their magic numbers and if they get away without breaking any major domains. -- Robert Edmonds ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
Paul Hoffman wrote: > That all seems correct. However, I brought the issue to this mailing list, > instead of to the UltraDNS folks, because I am using tools that expect host > names instead of domain names (in this case, dig); now I have to write shims > around them. Other signing-on-the-fly mechanisms might cause similar issues > for dig or other tools. While the manpage doesn't use the word, I believe dig processes owner names rather than hostnames. -- Robert Edmonds ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] resolver cache question
obtained from the LRU end of the probationary segment. Put a limit on the size of the probationary segment (e.g. the probationary segment of the cache can only occupy 10% of the total amount of space allocated to the cache) and you're done. This is probably simpler to implement for existing DNS resolver implementations than even a Bloom filter and certainly simpler than any schemes based on detecting which domains are "disposable". -- Robert Edmonds ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] is anybody awake at 5.0.1.0.0.2.ip6.arpa? (comcast and/or arin)
Paul Vixie wrote: > ssh gets hinky when i connect from a server whose PTR is "servfail" (dnssec > "bogus") Unless you're using host-based authentication or the from= option with a hostname pattern in an authorized_keys file, you can set "UseDNS no" in the sshd config file, or upgrade to OpenSSH 6.8p1 or later where "UseDNS no" is the default. -- Robert Edmonds ___ 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?
John Levine wrote: > 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? If I recall correctly, one of the major issues with ECDSA support was the lack of support on some commercial OSes; e.g. it had been intentionally disabled on RHEL. It looks like support for ECDSA with P-256/P-384 in OpenSSL was enabled in RHEL 6.5 [0], which was released in 2013. [0] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/6.5_release_notes/bh-chap-security -- Robert Edmonds ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Nameserver responses from different IP than destination of request
Puneet Sood via dns-operations wrote: > RFC 1035 section 7.3 (https://tools.ietf.org/html/rfc1035) > Some name servers send their responses from different > addresses than the one used to receive the query. That is, a > resolver cannot rely that a response will come from the same > address which it sent the corresponding query to. This name > server bug is typically encountered in UNIX systems. > > RFC 2181 (https://tools.ietf.org/html/rfc2181#section-4) >Most, if not all, DNS clients, expect the address from which a reply >is received to be the same address as that to which the query >eliciting the reply was sent. This is true for servers acting as >clients for the purposes of recursive query resolution, as well as >simple resolver clients. The address, along with the identifier (ID) >in the reply is used for disambiguating replies, and filtering >spurious responses. This may, or may not, have been intended when >the DNS was designed, but is now a fact of life. > >Some multi-homed hosts running DNS servers generate a reply using a >source address that is not the same as the destination address from >the client's request packet. Such replies will be discarded by the >client because the source address of the reply does not match that of >a host to which the client sent the original request. That is, it >appears to be an unsolicited response. See also RFC 5452 section 9.1 (https://tools.ietf.org/html/rfc5452#section-9.1) which puts the clarification in RFC 2181 into mandatory RFC 2119 language. 9.1. Query Matching Rules A resolver implementation MUST match responses to all of the following attributes of the query: o Source address against query destination address o Destination address against query source address o Destination port against query source port o Query ID o Query name o Query class and type before applying DNS trustworthiness rules (see Section 5.4.1 of [RFC2181]). A mismatch and the response MUST be considered invalid. -- Robert Edmonds ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Authoritative name server replies NODATA for a non-existing domain
Stephane Bortzmeyer wrote: Strange behavior: % for ns in $(dig +nodnssec +short NS adult.); do echo $ns dig @$ns NS thisdomaincertainlydoesnotexist.adult | grep status: done d0.nic.adult. ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 13433 c0.nic.adult. ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 23111 a0.nic.adult. ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 3358 a2.nic.adult. ;; -HEADER- opcode: QUERY, status: NOERROR, id: 48334 b2.nic.adult. ;; -HEADER- opcode: QUERY, status: NOERROR, id: 29932 b0.nic.adult. ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 58405 Interestingly, the two servers that return NOERROR are distinguishable from the others using fpdns: fingerprint (a0.nic.adult., 199.115.152.1): No match found fingerprint (a0.nic.adult., 2001:500:a0:0:0:0:0:1): No match found fingerprint (a2.nic.adult., 199.115.156.1): NLnetLabs NSD 3.1.0 -- 3.2.8 [New Rules] fingerprint (a2.nic.adult., 2001:500:a4:0:0:0:0:1): NLnetLabs NSD 3.1.0 -- 3.2.8 [New Rules] fingerprint (b0.nic.adult., 199.115.153.1): No match found fingerprint (b0.nic.adult., 2001:500:a1:0:0:0:0:1): No match found fingerprint (b2.nic.adult., 199.115.157.1): NLnetLabs NSD 3.1.0 -- 3.2.8 [New Rules] fingerprint (b2.nic.adult., 2001:500:a5:0:0:0:0:1): NLnetLabs NSD 3.1.0 -- 3.2.8 [New Rules] fingerprint (c0.nic.adult., 199.115.154.1): No match found fingerprint (c0.nic.adult., 2001:500:a2:0:0:0:0:1): No match found fingerprint (d0.nic.adult., 199.115.155.1): No match found fingerprint (d0.nic.adult., 2001:500:a3:0:0:0:0:1): No match found -- 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
Re: [dns-operations] [dDoS] Good discussion on the Rackspace attack and DNS resiliency
David C Lawrence wrote: For what it's worth, the TTLs are inviolable ship sailed long ago. Both ends of the TTL are already monkeyed with by local policy across the Internet. BIND has had max-cache-ttl for a very long time. Web browsers similarly for a very long time have kept local caches with minimum TTLs that the vast majority of people are not even aware. Capping excessively long TTLs is explicitly contemplated by RFC 1035, though. -- 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
Re: [dns-operations] DNS Security Advisory (infinite recursion)
Mukund Sivaraman wrote: On Tue, Dec 09, 2014 at 01:17:03PM -0500, Robert Edmonds wrote: BTW, there's also RFC 4697 / BCP 123 which appears to have two contradictory recommendations: 2.3. Inability to Follow Multiple Levels of Indirection [...] 2.3.1. Recommendation Clearly constructing a delegation that relies on multiple levels of indirection is not a good administrative practice. However, the practice is widespread enough to require that iterative resolvers be able to cope with it. Iterative resolvers SHOULD be able to handle arbitrary levels of indirection resulting from out-of-zone name servers. Iterative resolvers SHOULD implement a level-of-effort counter to avoid loops or otherwise performing too much work in resolving pathological cases. [...] You can support an unbounded (sorry) amount of indirection, or a bounded amount of indirection, but not both. By arbitrary, I understand that it should be configurable (according to its dictionary definition). It doesn't mean that the number of levels of indirection is not bounded. Hence, the level-of-effort counter too. That is not my impression from reading the whole section in context. Arbitrary levels of indirection resulting from out-of-zone name servers, seems to refer to the levels of arbitrariness selected by the out-of-zone name servers, not an arbitrary limit imposed by the iterative resolver. Anyway, the ANSSI report has now been released: http://www.ssi.gouv.fr/en/the-anssi/events/vulnerabilty-disclosure-the-infinitely-delegating-name-servers-idns-attack.html -- 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
Re: [dns-operations] DNS Security Advisory (infinite recursion)
Tony Finch wrote: I just saw this bit in RFC 1034 page 34/35 Step 2 looks for a name server to ask for the required data. [...] Set up their addresses using local data. It may be the case that the addresses are not available. The resolver has many choices here; the best is to start parallel resolver processes looking for the addresses while continuing onward with the addresses which are available. Obviously, the design choices and options are complicated and a function of the local host's capabilities. The recommended priorities for the resolver designer are: 1. Bound the amount of work (packets sent, parallel processes started) so that a request can't get into an infinite loop or start off a chain reaction of requests or queries with other implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED SOME DATA. ... So I guess Jeeves wasn't vulnerable to this bug? BTW, there's also RFC 4697 / BCP 123 which appears to have two contradictory recommendations: 2.3. Inability to Follow Multiple Levels of Indirection [...] 2.3.1. Recommendation Clearly constructing a delegation that relies on multiple levels of indirection is not a good administrative practice. However, the practice is widespread enough to require that iterative resolvers be able to cope with it. Iterative resolvers SHOULD be able to handle arbitrary levels of indirection resulting from out-of-zone name servers. Iterative resolvers SHOULD implement a level-of-effort counter to avoid loops or otherwise performing too much work in resolving pathological cases. [...] You can support an unbounded (sorry) amount of indirection, or a bounded amount of indirection, but not both. -- 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
Re: [dns-operations] Looking for a public blackhole/sinkhole IP address
Mark Andrews wrote: I would say CNAME/DNAME with a week long ttl to one of the non RFC 1918 or ULA default local zones but IANA has been tardy about getting the insecure delegations in place to break the DNSSEC chains of trust. That way default local zone aware recursive servers would answer negatively to the querier and you have a long lived cached record to slow the rate of queries from the recursive servers. e.g. 0.in-addr.arpa. Not all default local zone aware recursive servers behave this way. Unbound in particular does not search its local zones when looking up CNAME/DNAME targets. -- 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
Re: [dns-operations] Looking for a public blackhole/sinkhole IP address
Stephane Bortzmeyer wrote: 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. There is some precedent for using TEST-NET addresses to shed DNS queries. RFC 6471 §3.4 suggests such a procedure when shutting down DNSBLs, and there is at least one DNSBL that uses it (list.dsbl.org). -- 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
Re: [dns-operations] Looking for a public blackhole/sinkhole IP address
Joe Abley wrote: On 26 Nov 2014, at 14:06, Warren Kumari war...@kumari.net wrote: What's wrong with 127.0.0.1? It makes it clear what the intent is, and you don't get a much more distributed sinkhole than that... I'm always wary of using 127.0.0.1 for anything that doesn't really mean you should talk to yourself. Without a comprehensive knowledge of the impact, you don't know what you're blowing up. Indeed, some recursive DNS servers won't even attempt to send queries to 127.0.0.1 by default. (Unbound's do-not-query-localhost: yes default.) If there really is a use case, let's try and get a block allocated, and encourage folk to anycast - null0 for this. https://github.com/ableyjoe/draft-jabley-well-known-sinkhole Needs text. Not submitted. Co-authors welcome. A common method for dealing with unwanted traffic is to direct that traffic at nominated addresses within a network that are null-routed; that is, packets with such destination addresses are discarded silently by routers with a null route for that destination configured. These addresses are colloquially known as sinkholes, by analogy with the same term used in Physical Geography to describe a hole in the ground formed by some form of collapse of the surface layer, into which objects may fall and be lost forever. My colloquial understanding is that a blackhole discards traffic while a sinkhole is a routed network address which gathers information from the inbound packets. Some even use the term sinkhole to mean a network address that returns application-specific responses. E.g., the Conficker Working Group deployed HTTP sinkholes which listen on 80/tcp and capture HTTP requests from infected hosts. So, I would consider s/sinkhole/blackhole/g, at least. -- 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
Re: [dns-operations] Looking for a public blackhole/sinkhole IP address
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
Re: [dns-operations] Looking for a public blackhole/sinkhole IP address
Stephane Bortzmeyer wrote: 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). What about specifying *no* nameservers? That is, delegating the domain name to a nonexistent nameserver name within an intentionally empty sacrificial zone with a lengthy negative TTL. -- 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
Re: [dns-operations] resolvers considered harmful
Paul Vixie wrote: [...] we can move the stubs to an HTTPS transport if we can agree on a RESTful query API and either JSON or XML schema for responses, but it is not in our power to make UDP, especially fragmented UDP as in EDNS, work in the last mile. [...] Why does moving to a new transport require re-designing the encoding scheme? Register a new IANA media type, e.g., application/dnsmessage, defined as a binary DNS message, encoded per RFC 1035 §4.1. See RFC 4027, 2540 for a related precedent, the extant application/dns media type: http://tools.ietf.org/html/rfc4027 http://tools.ietf.org/html/rfc2540 http://www.iana.org/assignments/media-types/application/dns The HTTP client POSTs to a static entry point for this hypothetical DNS-over-HTTP proxy, setting request headers: Accept: application/dnsmessage Content-Type: application/dnsmessage [...] and attaching the RFC 1035 §4.1 encoded DNS query message as the request body. The HTTP server responds with status code 200 and sends the RFC 1035 §4.1 encoded DNS response message as the response body. -- 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
Re: [dns-operations] different dns servers for different domains.
Edward Peschko wrote: hmm. that seems a bit more involved to me than what I'm looking for. I don't control the remote name servers in question. When you type, e.g. ping www.yahoo.com, it isn't too many steps away from doing a lookup based off resolv.conf. Hell, in fact it is *one* step AFAICT, after hostname lookup via /etc/hosts. I mean, really, how complicated is control-flow logic? I can stuff all the hosts in question that I need into /etc/hosts for lookup, but that seems pretty barbaric, and it would be nice to have a solution that could be done locally rather than requiring network support. You didn't specify what OS you're using. (Since you mention /etc/, it's probably not Windows.) OS X with its multi-client resolver is the only stub resolver I know of that has this functionality built-in. If you want this functionality on other systems you have to install a local DNS server like Unbound and configure a forward zone. -- 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
Re: [dns-operations] 'dnstap' (Re: Prevalence of query/response logging?)
a giant cache of NS and A/ records (bootstrapped from the root zone), and work downwards from there based on the responses logged by our capture component. There are obvious scaling problems with this approach. This latter problem is unwieldy enough to do with passive packet capture, especially when you are aggregating the responses from many recursive servers (as we are), that it'd be highly desireable to be able to obviate it somehow. And there is: if we can modify the recursive DNS implementation (and this is a big if), we can have the DNS server log the cache-miss response and annotate it with the bailiwick domain for the transaction. This is enough information that we can elide the large, stateful bailiwick reconstruction cache of the passive packet capture approach. We have a working patchset for Unbound implementing this idea and I know that it's possible with BIND. There are other use cases where it'd nice to be able to avoid resorting to packet capture. For instance, virtually all of the DNS looking glass implementations I've seen do some sort of munging of the DNS message content into text/JSON/HTML/etc. Ideally it'd be possible to have the option of passing along the original verbatim DNS response message content. (I think the RIPE Atlas DNS probe currently comes closest to this ideal. IIRC, there is a way to extract the original DNS message byte sequence, but I believe it's a base64-encoded payload inside a JSON document, or something like that.) Another closely related use case is actually being able to save a trace of the DNS message(s) sent/received by debugging tools like dig, kdig, drill, delv, etc. IMO, it's inconvenient enough setting up a packet capture tool running alongside the query tool (needs root, needs to include DNS packet traffic initiated by the query tool but exclude any other incidental DNS traffic that may be captured, may need to scrub IP header addresses from your local network if you want to share the capture, etc. etc.) in order to save a proper archival quality copy of the message data that people rarely do this; what you get instead is usually a copy-paste of the dig-style output generated by these tools in most cases. And you end up with more-or-less pointless differences between the output formats of these tools, like, to pick an example at random, the trailing metadata that these tools generate, which might look like ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Jul 07 14:35:57 EDT 2014 ;; MSG SIZE rcvd: 239 or ;; Received 239 B ;; Time 2014-07-07 14:35:54 EDT ;; From 127.0.0.1@53(UDP) in 0.2 ms depending on the whims of the vendor who produced the tool you're using. CZ.NIC's kdig has working support for being able to export the query/response messages in dnstap format and to generate display output from the messages saved to a dnstap file, and I hope to be able to extend the debugging tools from other vendors to be able to similarly handle dnstap files. Plain old query logging at scale will probably best be done by packet capture for the forseeable future, unless you'd like to be able to export information that doesn't appear on the wire (e.g., whether a query was served from cache or not), in which case something like dnstap might be a good fit. Certainly I'd like to have the DNS resolver on my home network be able to generate good logs for free out of the box much like your typical HTTP server (apache/nginx/etc.) comes properly configured to log accesses. However, what I don't think the future involves is hanging some more %s's off of a big printf() style format string like: ns_client_log(client, NS_LOGCATEGORY_QUERIES, NS_LOGMODULE_QUERY, level, query: %s %s %s %s%s%s%s%s%s (%s), namebuf, classname, typename, WANTRECURSION(client) ? + : -, (client-signer != NULL) ? S: , (client-opt != NULL) ? E : , ((client-attributes NS_CLIENTATTR_TCP) != 0) ? T : , ((extflags DNS_MESSAGEEXTFLAG_DO) != 0) ? D : , ((flags DNS_MESSAGEFLAG_CD) != 0) ? C : , onbuf); (Not to pick on BIND/ISC specifically here, but I had the function handy.) It so happens that we now have the infrastructure to plug in arbitrary modules at packet entry exit, we could perhaps do a dnstap implementation there. Will keep you posted. This is great news; in general I think a lot of people would like to see more hook-ability like this from DNS software. (Unbound's module stacks are quite interesting and I originally wanted to implement dnstap in Unbound as an Unbound module, but I wasn't able to get it to work out, unfortunately.) -- Robert Edmonds ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net
Re: [dns-operations] 'dnstap' (Re: Prevalence of query/response logging?)
or protobufs paired with ZeroMQ is a fairly reasonable solution for a wide variety of use cases. So, sorry we didn't pick IPFIX. It just doesn't look like a good fit for what we want to make possible, and there are a lot of general purpose technologies out there that I would consider first before considering IPFIX for a particular application. -- 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
Re: [dns-operations] 'dnstap' (Re: Prevalence of query/response logging?)
Roland Dobbins wrote: On Jul 5, 2014, at 5:04 AM, Paul Vixie p...@redbarn.org wrote: dnstap is completely open source, with a BSD-style license (Apache 2.0). it is sponsored by farsight because we need a uniform DNS telemetry format for our business purposes. I read the dnstap preso with great interest when it was posted, and this appears to be the way to go, moving forward - one hopes we can get the option for dnstap telemetry natively exported over IPFIX, as this would make it easier to perform combinatorial analytics with flow telemetry generated via network infrastructure, as well as speed up the implementation of operationally useful collection/analytical systems. dnstap payloads are protobufs; they can be embedded in any binary clean transport. For instance, our fstrm I/O library [0] was designed with dnstap/protobuf payloads in mind, but this does not prevent dnstap payloads from being carried over other transports, such as HTTP, or even pcap. (However, for pcap one would need to have a new linktype value assigned, and very large DNS messages (~64K) would not be representable due to pcap's 64K frame size limit.) We have no plans to replace the current protobuf encoding used in dnstap with any other serialization format. Of course, this not prevent re-encoding dnstap payloads into other formats, or implementing dnstap input plugins in existing systems, etc. See [1] for the protobuf definition file used in dnstap. [0] https://github.com/farsightsec/fstrm [1] https://github.com/dnstap/dnstap.pb -- 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
Re: [dns-operations] Need contacts
Chuck Aurora wrote: I saw the formal statement from no-ip about this, but it didn't list which zones were hijacked nor what the court order said. Dan, perhaps no-IP/Vitalwerks can provide some real information? The court order is here: http://noticeoflawsuit.com/docs/Second%20Amended%20Order%20-%20flattened.pdf The list of affected domains is in Appendix B to the court order: http://noticeoflawsuit.com/docs/Appendix%20B%20to%20Second%20Amended%20Order.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
Re: [dns-operations] bluehost weirdness
.si hostmaster wrote: Hello, it seems bluehost.com does some weird things with several TLDs. Their nameservers return authoritative answer for SOA queries for some TLDs: [...] Does anyone know what is the purpouse for doing this? This is a common DNS anti-pattern used by low-end web hosters that also do DNS hosting that exploits the fact that the DNS protocol (pre-DNSSEC) allows certain serious misconfigurations, such as parent and child zones disagreeing on the location of a zone cut. Basically, they have a single zone with wildcards like: ;; ANSWER SECTION: *.com. 60 IN A 74.220.199.6 and ;; ANSWER SECTION: *.uk. 60 IN A 74.220.199.6 etc. (I'm not sure why they don't just wildcard all of *. and be done with it.) This lets them turn up tons of web hosting customers without having to configure thousands of individual zones on their nameservers. They just tell the prospective customer to point their NS records at their nameservers, and the web hoster doesn't have to provision anything in order to make the customer's domain resolve. -- 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
Re: [dns-operations] FYI: Georgia Tech Paper on Disposable Domain Names
Livingood, Jason wrote: May be of interest. Full disclosure: Uses data from Comcast’s recursive servers and our Tech RD Fund provided some partial funding of the work. See http://www.nctatechnicalpapers.com/Paper/2014/2014-disposable-domains By Yizheng Chen, Manos Antonakakis, Wenke Lee In recent years DNS has been increasingly leveraged to build and scale highly reliable network infrastructures. In this paper, we will introduce and analyze a new class of domains, which we refer to as disposable domains. Disposable domains appear to be heavily employed by common Internet services (i.e., Search Engines, Social Networks, Online Trackers etc.), and they seem to be automatically generated. They are characterized by a “one-time use” pattern, and appear to be used as a way of “signaling” via DNS. While this is yet another “creative” use of the DNS to enable new Internet applications and efficient scaling of services, little do we know about the size and DNS caching properties of this family of domains. To shed light on the pervasiveness and growth of disposable domains, we present a study of their characteristics based on live DNS traffic observed at Comcast, in a city that serves millions of end users. We found that disposable domains increased from 23.1% to 27.6% in all queried domain names, and from 27.6% to 37.2 % among all resolved domain names daily, and more than 60% of all distinct resource records observed daily in modern DNS traffic are related to disposable domains. We discuss the possible negative implications that disposable domains may have on the DNS caching infrastructure, resolvers validating DNSSEC transactions, and passive DNS data collection systems. According to the paper, Usually, over 90% of cache hit rates from disposable domains are zero. (I think this means that 90% of these disposable domains are only used once, but the wording is not entirely clear.) It might be worthwhile investigating whether this warrants implementing Segmented LRU in DNS caching implementations. From Wikipedia, An SLRU cache is divided into two segments, a probationary segment and a protected segment. Lines in each segment are ordered from the most to the least recently accessed. Data from misses is added to the cache at the most recently accessed end of the probationary segment. Hits are removed from wherever they currently reside and added to the most recently accessed end of the protected segment. Lines in the protected segment have thus been accessed at least twice. -- 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
Re: [dns-operations] BIND performance difference between RHEL 6.4 and FreeBSD 7
Shawn Zhou wrote: Looks like BIND 9.9.4b1 has support for SO_REUSEPORT as test results I get from RHEL 6.5 look better than what I have from RHEL 6.4: No, it doesn't. SO_REUSEPORT must be explicitly enabled on the listening socket, and the string SO_REUSEPORT does not appear anywhere in the BIND codebase. (I'm also fairly certain SO_REUSEPORT hasn't been backported to RHEL 6's kernel, but I haven't checked that. In mainline Linux, it is only present in versions = 3.9.) It would be relatively easy to add support for SO_REUSEPORT to BIND, though. I recently added it to Unbound and the changes were fairly simple: http://thread.gmane.org/gmane.network.dns.unbound.user/2915 It resulted in decreased CPU utilization on Linux 3.9+, but I did not measure the drop rate. -- 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
Re: [dns-operations] BIND performance difference between RHEL 6.4 and FreeBSD 7
Chris Adams wrote: Once upon a time, Robert Edmonds edmo...@mycre.ws said: No, it doesn't. SO_REUSEPORT must be explicitly enabled on the listening socket, and the string SO_REUSEPORT does not appear anywhere in the BIND codebase. (I'm also fairly certain SO_REUSEPORT hasn't been backported to RHEL 6's kernel, but I haven't checked that. In mainline Linux, it is only present in versions = 3.9.) I didn't try actually using it, but the current RHEL 6 kernel-headers do define SO_REUSEPORT. It looks like they have the constant defined, but don't actually implement it. -- 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
Re: [dns-operations] Best practices for Linux/UNIX stub resolver failover
Jonathan Stewart wrote: Robert Edmonds edmo...@mycre.ws wrote: Chuck Anderson wrote: 2. Use a local DNS daemon on every server with forwarders configured to the network's nameservers, and fix resolv.conf to 127.0.0.1. I'll shamelessly admit that I do this on all my Debian systems, where apt-get install unbound resolvconf results in exactly that configuration. Does this result in a DNSSEC-validating resolver, as well? Yes, it does. We ship a default config for Unbound that uses the auto-trust-anchor-file mode for the root trust anchor. You have to specifically remove that from the config in order to disable DNSSEC validation. If so, then Chuck's problem is actually a solved one, and his request (as mine would be) is that the Linux distributions make this default, so long as the setting of one or more recursive resolvers was easy. Er, not really. This config is just plain old DNSSEC validation, so you (rightly) get no DNS resolution at all on networks where it is not possible to perform DNSSEC validation (e.g., random wifi hotspots). We could not realistically enable this by default for all Debian installations, not without additional components (e.g., dnssec-trigger) to fix the hotspot problem. Of course, in an environment where DNS queries have not been restricted, this setup should run standalone, resolving DNS queries from the root. No, by default resolvconf configures Unbound to forward lookups to the DNS servers that the system has been configured to use. (Either statically assigned or learned via DHCP.) If the sysadmin configures the system to not use any upstream DNS servers then forwarding mode is turned off and Unbound does full recursion. -- 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
Re: [dns-operations] BIND performance difference between RHEL 6.4 and FreeBSD 7
Doug Barton wrote: What's your goal? If your research shows that FreeBSD is a better platform for BIND, why is the answer not Then use that? Except the graph doesn't show that FreeBSD is a clearly better platform for BIND. According to the graph, RHEL doesn't drop any queries at all up until 180 Kq/s, at which point FreeBSD is dropping ~5000 q/s. -- 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
Re: [dns-operations] Best practices for Linux/UNIX stub resolver failover
Chuck Anderson wrote: 2. Use a local DNS daemon on every server with forwarders configured to the network's nameservers, and fix resolv.conf to 127.0.0.1. I'll shamelessly admit that I do this on all my Debian systems, where apt-get install unbound resolvconf results in exactly that configuration. -- 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] google public dns (was: Re: bind-9.9.4-P1 crash)
Dnsbed Ops wrote: In fact our nameservers have blocked a lot of IPs from google: DROP all -- 173.194.99.0/24 0.0.0.0/0 DROP all -- 74.125.16.2100.0.0.0/0 DROP all -- 74.125.41.17 0.0.0.0/0 [...etc...] DROP all -- 74.125.42.19 0.0.0.0/0 DROP all -- 74.125.42.17 0.0.0.0/0 DROP all -- 74.125.177.170.0.0.0/0 those IPs are used by google public DNS. https://developers.google.com/speed/public-dns/faq#locations All the queries from those IPs are going with this style: 74.125.191.84#63255: query: qalljrwww.byw.so 74.125.41.20#53581: query: womciswww.byw.so dnsbed's nameservers appear to be authoritative for byw.so... And the count is huge. So I dropped them. it is estimated that some 7% of the entire Internet user base uses google public DNS. it is probably a bad idea for an authoritative DNS service to block google public DNS. http://www.circleid.com/posts/20132216_who_uses_googles_public_dns/ -- 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
Re: [dns-operations] chrome's 10 character QNAMEs to detect NXDOMAIN rewriting
Mark Andrews wrote:
In message 20131128000148.ga20...@mycre.ws, Robert Edmonds writes:
i'm curious as to exactly what this root zone slaved resolver
configuration looks like and how it would behave. i don't believe i've
ever set up a resolver like that before.
zone . IN {
type slave;
file slave/root;
masters { 192.5.5.241; };
notify no;
};
if i understand things right, this config could only be achieved with
particular resolver implementations that combine authoritative and
recursive service into the same server, and the only implementation i
know of that does that is BIND 9. i believe unbound, powerdns, BIND 10,
djbdns, etc. are all either recursive only, or split recursive and
authoritative service into separate daemons, afaik. but i'm not
familiar with any of the closed source implementations.
if such a config is possible, how is it supposed to work with DNSSEC?
if the DNS server loads a bad copy of the root zone somehow during an
AXFR, does it use its configured root trust anchor to determine that its
copy of the zone doesn't validate, or does the act of configuring the
root zone as an authoritative zone make it more trustworthy, thus
overriding the need to do DNSSEC validation at the root level?
You can do stuff like this (cut-and-pasted from a live config).
managed-keys {
. initial-key 257 3 8
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=;
};
view secure {
match-clients { localnets; };
match-recursive-only yes;
zone . {
type static-stub;
server-addresses { 127.0.0.1; };
};
};
view external {
match-clients { localnets; };
recursion no;
allow-recursion { none; };
zone . IN {
type slave;
file slave/root;
masters { 192.5.5.241; };
notify no;
};
};
The same trick can be used to validate data from other zones that
are locally served.
so, just to be clear, this config snippet alone:
zone . IN {
type slave;
file slave/root;
masters { 192.5.5.241; };
notify no;
};
is not sufficient if one wants to both slave and validate the root zone?
this snippet will bypass DNSSEC validation if configured into a
recursive server?
--
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
Re: [dns-operations] DNS Attack over UDP fragmentation
Aaron Campbell wrote: Here is a thought, but I will defer to the protocol experts on plausibility. The resolver knows the size of each DNS message it parses. What if it didn't trust glue records contained within large (i.e., 1400 bytes or so) responses? In these cases, the resolver sends a separate query to resolve the dangling authority NS records. This introduces overhead, but only for large replies. It also makes a few assumptions, namely that the fragmentation point is something around 1500 bytes (and not something lower), and that the attack is only practical against the glue records, not the authority section. May be able to play games with name compression there though… perhaps it is as least worth discussing as an additional barrier. this sounds vaguely similar to unbound's harden-referral-path option, though it applies to all lookups. -- 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
Re: [dns-operations] Odd resolver/cache behavor or normal operation?
Joe Abley wrote: I don't imagine that anybody is going to be able to give you a root cause based on just that information. It could be a bug in your resolver, it could be a transient problem at google, it could be a sign of successful cache poisoning attack, or it could be something else. my favorite though only half-serious explanation is inclement space weather. it sounds like the poster's problem coincides nicely with the most recent Earth-directed coronal mass ejection detected by NASA last week: http://www.nasa.gov/content/goddard/20130821-another-earth-directed-cme/ -- 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
Re: [dns-operations] Multiple A/AAAA RRs associated with an NS RR
John Kristoff wrote: I'm curious if anyone is aware of, or can envision, any actual problems or real benefits with this A/ overloading, for a lack of a better term since I'm not sure what to call it. i'd call it normal behavior explicitly described by the RFC: The resolver always starts with a list of server names to query (SLIST). This list will be all NS RRs which correspond to the nearest ancestor zone that the resolver knows about. To avoid startup problems, the resolver should have a set of default servers which it will ask should it have no current NS RRs which are appropriate. The resolver then adds to SLIST all of the known addresses for the name servers, and may start parallel requests to acquire the addresses of the servers when the resolver has the name, but no addresses, for the name servers. this probably only matters for zones with a large number of nameservers. look at, e.g., zen.spamhaus.org. that zone has 66 IPv4 nameservers, but 22 NS records. doing it that way probably reduces the probability of truncation, and reduces the overall size of responses. -- Robert Edmonds edmo...@isc.org ___ 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] N-Root
. . 518400 IN NS e. . 518400 IN NS f. . 518400 IN NS g. . 518400 IN NS h. . 518400 IN NS i. . 518400 IN NS j. . 518400 IN NS k. . 518400 IN NS l. . 518400 IN NS m. . 518400 IN NS n. ;; ADDITIONAL SECTION: a. 518400 IN A 198.41.0.4 b. 518400 IN A 192.228.79.201 c. 518400 IN A 192.33.4.12 d. 518400 IN A 199.7.91.13 e. 518400 IN A 192.203.230.10 f. 518400 IN A 192.5.5.241 g. 518400 IN A 192.112.36.4 h. 518400 IN A 128.63.2.53 i. 518400 IN A 192.36.148.17 j. 518400 IN A 192.58.128.30 k. 518400 IN A 193.0.14.129 l. 518400 IN A 199.7.83.42 m. 518400 IN A 202.12.27.33 n. 518400 IN A 198.51.100.41 a. 518400 IN 2001:503:ba3e::2:30 d. 518400 IN 2001:500:2d::d ;; WHEN: Mon Apr 1 16:04:17 2013 ;; MSG SIZE rcvd: 493 (compare to the original response which shows MSG SIZE rcvd: 492.) so that just leaves the decision of who gets to operate the new N-root DNS server. -- Robert Edmonds edmo...@isc.org ___ 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] FYI: SAC057 - SSAC Advisory on Internal Name Certificates
Livingood, Jason wrote: Posted today on the SSAC site @ http://www.icann.org/en/groups/ssac/documents/sac-057-en.pdf. Worth reading, especially if you have internal namespace (and associated internally generated SSL certificates) that overlaps with a new gTLD name. From the exec summary intro: there is an interesting quote in this document from a CA: According QuoVadis Group, a certificate authority, one use case for internal name certificate is for convenience: As a convenience for users, many servers in corporate networks are reachable by local names such as “mail”, “wiki” or “hr”. Most publicly trusted certificates for non‐unique names are deployed in the context of local networks to enable trust in these local names without the additional cost of provisioning a new trust root to clients. This may be especially desirable for networks lacking centralized policy deployment and management tools, such as “Bring Your Own Device” environments.[5] 5. See QuoVadis Group. 2012. Internal Server Names and IP Address Requirements for SSL at: https://support.quovadisglobal.com/AvatarHandler.ashx?radfile=%2fCommon%2fSSL+General+Topics+%28KB%29%2fQV_DeprecatedCertsGuidance_v2.pdf. i certainly hope the reference to hr being a local or internal or non-unique name is a mistake and that CAs would absolutely refuse to issue certs for names that are the same as a really existing TLD: http://www.iana.org/domains/root/db/hr.html -- Robert Edmonds edmo...@isc.org ___ 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] Capturing 8.8.8.8 Traffic
Lyle Giese wrote: I would check to see what happens to domains that don't exist. Esp asking for the MX records for a domain that doesn't exist. I had heard stories that some public resolvers will resolve when they should not. For surfing, minor issue. For a mail server, major issue. apparently google heard those stories too. https://developers.google.com/speed/public-dns/faq#nxdomains How is Google Public DNS different from my ISP's DNS service or other open DNS resolvers? How can I tell if it is better? [...] Unlike Google Public DNS, some ISPs and open resolvers block, filter, or redirect DNS responses. How does Google Public DNS handle non-existent domains? If you issue a query for a domain name that does not exist, Google Public DNS always returns an NXDOMAIN record, as per the DNS protocol standards. The browser should show this response as a DNS error. [...] -- Robert Edmonds edmo...@isc.org ___ 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] Capturing 8.8.8.8 Traffic
Noel Butler wrote: and putting tin foil hat on now :) it would log those requests, and who knows what google does with that data, it sure as hell doesnt do it for the goodness of the planet, there is a commercial reason behind every decision and service they provide. yes, who knows what google is doing with all that data. they would never tell us that. https://developers.google.com/speed/public-dns/privacy [...] Google Public DNS stores two sets of logs: temporary and permanent. The temporary logs store the full IP address of the machine you're using. We have to do this so that we can spot potentially bad things like DDoS attacks and so we can fix problems, such as particular domains not showing up for specific users. We delete these temporary logs within 24 to 48 hours. In the permanent logs, we don't keep personally identifiable information or IP information. We do keep some location information (at the city/metro level) so that we can conduct debugging, analyze abuse phenomena. After keeping this data for two weeks, we randomly sample a small subset for permanent storage. We don't correlate or combine information from our temporary or permanent logs with any personal information that you have provided Google for other services. Finally, if you're interested in knowing what else we log when you use Google Public DNS, here is the full list of items that are included in our permanent logs: * Request domain name, e.g. www.google.com * Request type, e.g. A (which stands for IPv4 record), (IPv6 record), NS, MX, TXT, etc. * Transport protocol on which the request arrived, i.e. TCP or UDP * Client's AS (autonomous system or ISP), e.g. AS15169 * User's geolocation information: i.e. geocode, region ID, city ID, and metro code * Response code sent, e.g. SUCCESS, SERVFAIL, NXDOMAIN, etc. * Whether the request hit our frontend cache * Whether the request hit a cache elsewhere in the system (but not in the frontend) * Absolute arrival time in seconds * Total time taken to process the request end-to-end, in seconds * Name of the Google machine that processed this request, e.g. machine101 * Google target IP to which this request was addressed, e.g. one of our anycast IP addresses (no relation to the user's IP) -- Robert Edmonds edmo...@isc.org ___ 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] Capturing 8.8.8.8 Traffic
Warren Kumari wrote: So, yes, there is a commercial reason -- Google makes basically all its money from folk using the Internet. While things have been improving, a large number of ISPs were providing very poor recursive DNS services for their users -- DNS is seen simply as a cost and not as a revenue stream, and so they were often oversubscribed and / or not reliable (and / or would lie). Poor DNS performance leads to a substantially degraded user experience (sometime have a look to see how many DNS resolutions something like the CNN main page requires) -- poor user performance leads to users using the Internet less, which leads to Google not making as much money. Now I realize that lots of folk would prefer to believe that there is something more nefarious happening (and there is nothing really that I can say to change that) but I figured I should at least try explain why Google provides this... by the way, speaking of 8.8.8.8, it'd be more convenient if this page: https://developers.google.com/speed/public-dns/faq#locations showed the locations on a map, or at least expanded the IATA airport codes. cf., http://www.opendns.com/technology/network-map (or even: http://www.google.com/about/datacenters/inside/locations/index.html) and speaking of anycast DNS and IATA air codes, why no SFO or LAX? is a single data center good enough for the entire U.S. west coast? :) -- Robert Edmonds edmo...@isc.org ___ 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] CloudShield advices against dDoS
Stephane Bortzmeyer wrote: http://www.cloudshield.com/applications/dns-control-traffic-load.asp My first reaction was These solutions are incredibly stupid and my second one But let's check among the experts at the dns-operations ML before trolling. hmm, s/before/while/, maybe. also, i think you're in the clear, since their anti-trolling policy only applies to patents and not blog posts: Referential Use Only. Third parties may reference CloudShield patents. Referential use is prohibited is such use would defame or disparage CloudShield, its products, or any other person or entity. (http://www.cloudshield.com/company/patents.asp) and hey, doesn't this behavior make kaminsky poisoning even easier? If this is true, why should you allow DNS queries with other resource records like , HIP, or SIG to reach your servers? [...] This only consumes processing time because they have no answer. The best way to handle them is to block it upfront. -- Robert Edmonds edmo...@isc.org ___ 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] Defending against DNS reflection amplification attacks
Jan-Piet Mens wrote: FYI, a paper (Feb 2013) titled Defending against DNS reflection amplification attacks at [1]. -JP [1] http://www.nlnetlabs.nl/downloads/publications/report-rrl-dekoning-rozekrans.pdf i had a brief look. actually, i skipped straight to appendix E :) i think measuring performance with process accounting (top, htop...) is not such a great idea. something like cyclesoak would probably be better: `cyclesoak' calculates CPU load by a subtractive method: a background cycle-soaking task is executed on all CPUs and `cyclesoak' measures how much the throughput of the background tasks is degraded by running the traffic. This means that ALL effects of networking (or other userspace + kernel activity) are measured - interrupt load, softirq handling, memory bandwidth usage, etc. This is much more accurate than using Linux process accounting. (http://www.tux.org/pub/sites/www.zip.com.au/%257Eakpm/linux/README.zc) and perf is a great profiling tool for linux, too. (https://perf.wiki.kernel.org/) -- Robert Edmonds edmo...@isc.org ___ 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] zone format bind9
Randy Bush wrote: rip.psg.com:/usr/home/dns/secondary# named-compilezone -f raw -F text -i none -o - cctld cctld dns_master_load: unsupported file format version zone cctld/IN: loading from master file cctld failed: not implemented i am not in love with this binary format bleep i am not a BIND developer, but have you tried using named-compilezone built from the same version of BIND as the named that generated the raw zonefile? i believe the file format was revised in 9.9.x. 3242. [func] Extended the header of raw-format master files to include the serial number of the zone from which they were generated, if different (as in the case of inline-signing zones). This is to be used in inline-signing zones, to track changes between the unsigned and signed versions of the zone, which may have different serial numbers. (Note: raw zonefiles generated by this version of BIND are no longer compatible with prior versions. To generate a backward-compatible raw zonefile using dnssec-signzone or named-compilezone, specify output format raw=0 instead of simply raw.) [RT #26587] -- Robert Edmonds edmo...@isc.org ___ 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] google DNS doing validation?
Joe Abley wrote: Hi all, I haven't seen anybody else mention this out loud, but since early last week (doing a DNSSEC workshop with NSRC at NZNOG 2013) we saw 8.8.8.8 giving secure answers when queried with EDNS0/DO=1. The responding node of 8.8.8.8 we saw in Wellington was in Sydney, I think (routing out through REANZ) but I see the same thing from my desk at home so perhaps this is a widespread change. 8.8.8.8 doesn't seem to support NSID, ID.SERVER/CH/TXT or HOSTNAME.BIND/CH/TXT but I included a traceroute in case anybody is interested. The FAQ still says that responses are not validated, but perhaps there is a documentation gap. https://developers.google.com/speed/public-dns/faq#dnssec can 8.8.8.8 be used behind a validating forwarder now? the last time i tried that it didn't work (i think there was some difficulty with locating DS records), but that was a while ago. -- Robert Edmonds edmo...@isc.org ___ 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] google DNS doing validation?
Paul Wouters wrote: On Mon, 28 Jan 2013, Robert Edmonds wrote: can 8.8.8.8 be used behind a validating forwarder now? the last time i tried that it didn't work (i think there was some difficulty with locating DS records), but that was a while ago. That was fixed about a year ago about a year ago was when i last tested it, and there were problems locating DS records (specifically, DS records in TLDs, iirc). ; DiG 9.9.0b2 @8.8.8.8 -t ds com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 59537 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;com. IN DS ;; Query time: 112 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Feb 8 11:42:55 2012 ;; MSG SIZE rcvd: 32 which works now: ; DiG 9.8.4-P1 @8.8.8.8 -t ds com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 34500 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;com. IN DS ;; ANSWER SECTION: com.19085 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 ;; Query time: 12 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Mon Jan 28 13:04:17 2013 ;; MSG SIZE rcvd: 69 -- Robert Edmonds edmo...@isc.org ___ 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] ATT DNS Cache Poisoning?
David Conrad wrote: Yep, assuming it is cache poisoning. I'm trying to think of alternative explanations, but given reports (e.g., from Frank) that the issue is affecting other resolvers, it's hard to see other answers. A bit odd, given ben.edu isn't very high up on the Alexa (et al) list... i don't think it's cache poisoning. note that there are two out-of-zone nameservers for ben.edu: Domain Name: BEN.EDU [...] Name Servers: NS1.BOBBROADBAND.COM NS2.BOBBROADBAND.COM and that bobbroadband.com was updated recently, in the past two days: Domain Name: BOBBROADBAND.COM Registrar: NETWORK SOLUTIONS, LLC. Whois Server: whois.networksolutions.com Referral URL: http://www.networksolutions.com/en_US/ Name Server: NS1.BOBBROADBAND.COM Name Server: NS2.BOBBROADBAND.COM Status: clientTransferProhibited Updated Date: 25-oct-2012 Creation Date: 22-oct-2005 Expiration Date: 22-oct-2017 here's what was seen in DNSDB on the same day that bobbroadband.com was updated in whois: ;; bailiwick: com. ;; count: 114 ;; first seen: 2012-10-25 11:53:51 - ;; last seen: 2012-10-25 12:58:03 - bobbroadband.com. IN NS ns1.pendingrenewaldeletion.com. bobbroadband.com. IN NS ns2.pendingrenewaldeletion.com. ;; bailiwick: bobbroadband.com. ;; count: 2 ;; first seen: 2012-10-25 15:08:04 - ;; last seen: 2012-10-25 15:49:29 - bobbroadband.com. IN NS ns1432.ztomy.com. bobbroadband.com. IN NS ns2432.ztomy.com. taking over the nameservers for bobbroadband.com would thus allow taking over ben.edu: ;; bailiwick: ben.edu. ;; count: 2 ;; first seen: 2012-10-25 15:09:49 - ;; last seen: 2012-10-25 15:58:11 - ben.edu. IN NS ns1432.ztomy.com. ben.edu. IN NS ns2432.ztomy.com. i see the exact same pattern with cooperhealth.edu, and its nameservers, back in april: Domain Name: COOPERHEALTH.EDU [...] Name Servers: DNS01.CAVTEL.NET DNS02.CAVTEL.NET Domain Name: CAVTEL.NET Registrar: NETWORK SOLUTIONS, LLC. Whois Server: whois.networksolutions.com Referral URL: http://www.networksolutions.com/en_US/ Name Server: DNS01.CAVTEL.NET Name Server: DNS02.CAVTEL.NET Status: clientTransferProhibited Updated Date: 10-apr-2012 Creation Date: 08-apr-1999 Expiration Date: 08-apr-2013 ;; bailiwick: net. ;; count: 168 ;; first seen: 2012-04-10 08:30:35 - ;; last seen: 2012-04-10 12:34:40 - cavtel.net. IN NS ns1.pendingrenewaldeletion.com. cavtel.net. IN NS ns2.pendingrenewaldeletion.com. ;; bailiwick: cavtel.net. ;; count: 6 ;; first seen: 2012-04-10 14:23:47 - ;; last seen: 2012-04-12 08:16:30 - cavtel.net. IN NS ns1432.ztomy.com. cavtel.net. IN NS ns2432.ztomy.com. ;; bailiwick: cooperhealth.edu. ;; count: 2 ;; first seen: 2012-04-11 06:52:37 - ;; last seen: 2012-04-11 20:07:14 - cooperhealth.edu. IN NS ns1432.ztomy.com. cooperhealth.edu. IN NS ns2432.ztomy.com. -- Robert Edmonds edmo...@isc.org ___ 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] eliminating stub resolvers
Jim Reid wrote: Yeah. It should even be possible to have a validating resolver using automatic rollover for the One True Trust Anchor without any config file at all. IIRC, that's pretty much what the almost ignored lwresd does. Though please don't assume I want to exhume lwresd. :-) a while back i experimented with interfacing the libunbound validating resolver library with the glibc name service switch (similar to nss-lwres): https://github.com/edmonds/nss-ubdns it loads trust anchors at startup, so trust anchor rollover works as long as some external process updates the TA file. there are some problems with this approach (not the least of which are that the results get returned to the caller through an API that doesn't indicate the validation status, or loading openssl into every process that calls the C resolver), but the surprising thing is that it even works at all. -- Robert Edmonds edmo...@isc.org ___ 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] PIR's (.org) Web site looks… default...
Peter Losher wrote: 6 be38.trmc0215-01.ars.mgmt.phx3.gdg (184.168.0.69) 76.690 ms 75.533 ms 75.069 ms 7 be38.trmc0215-01.ars.mgmt.phx3.gdg (184.168.0.69) 76.191 ms 76.421 ms 76.567 ms 8 be100.125.trmd0215-01.ars.mgmt.phx3.gdg (216.69.188.30) 76.566 ms 75.923 ms 76.694 ms 9 ip-208-109-112-125.ip.secureserver.net (208.109.112.125) 76.316 ms 76.547 ms 77.193 ms 10 ip-50-63-189-22.ip.secureserver.net (50.63.189.22) 76.068 ms 76.594 ms 75.694 ms well, this is godaddy. -- Robert Edmonds edmo...@isc.org ___ 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] Name server turning off RD bit in response - just curious
Peter Koch wrote: On Tue, Aug 07, 2012 at 01:39:32PM -0400, Robert Edmonds wrote: indeed, and for an example of the opposite behavior, see ns[1-4].google.com, which set the RD bit in responses regardless of the RD bit in the query. Well, at least my version of dig breaks insofar as it emits a warning that is only based on the response: ;; WARNING: recursion requested but not available, even with +norec. right, dig is comparing the response-RD bit against the response-RA bit, with the assumption that response-RD == query-RD. i believe that warning was introduced in this change: 1908. [func] dig now warns if 'RA' is not set in the answer when 'RD' was set in the query. host/nslookup skip servers that fail to set 'RA' when 'RD' is set unless a server is explicitly set. [RT #15005] -- Robert Edmonds edmo...@isc.org ___ 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
