Re: [dns-operations] Best practice for securing DNS record
Viktor Dukhovni wrote: > > In corporate networks with DNS managed at arm's length by a separate > team, it is not uncommon for users to request addition of DNS records, > but neglect to request their deletion or to fail to keep them up to > date. Right. Ideally your service provisioning stuff would be hooked up to the DNS so that when a service is decommissioned the DNS is automatically cleaned up as well. For off-site services, the key phrase for your threat model is "subdomain takeover attacks". There's some basic automation that can help spot problems: looking for dangling CNAMEs; checking whether the target of an A record still responds; checking whether a web server is still hosting the site you expect. It's also important to know what the subdomain authorization policies are for each of your off-site providers. Are the authorization records temporary (if so, clean them away promptly) or do they need to remain in place? How well does each provider protect you against subdomain takeovers? (i.e. how closely do you need to monitor them yourself?) Tony. -- f.anthony.n.finchhttps://dotat.at/ Great Orme Head to the Mull of Galloway: Southerly or southwesterly 3 to 5, increasing 6 to gale 8, occasionally severe gale 9 later in north and west. Smooth or slight becoming moderate or rough, occasionally very rough later in west. Showers, then occasional rain. Good, occasionally poor later. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS
Paul Vixie wrote: > On Wed, Aug 18, 2021 at 12:15:39PM +0100, Tony Finch wrote: > > > ... > > > > I rather like the adns API http://www.chiark.greenend.org.uk/~ian/adns/ > > "I'm afraid there is no manual yet. However, competent C programmers should be > able to use the library based on the commented adns.h header file, and the > usage messages for the programs should be sufficient." Yes, I'm not fond of its docs, they could be a lot more approachable :-) Tony. -- f.anthony.n.finchhttps://dotat.at/ individual and social justice ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS
Viktor Dukhovni wrote: > > On 17 Aug 2021, at 8:18 pm, Andrew Sullivan wrote: > > > > Hence https://getdnsapi.net/ > > Sadly, while getdnsapi looks somewhat natural to a Python programmer, it > is a rather poor C API with so much ceremony and boilerplate as to be > essentially unusable IMHO. If we want to see something adopted widely, > I don't think getdnsapi will be it. I rather like the adns API http://www.chiark.greenend.org.uk/~ian/adns/ Tony. -- f.anthony.n.finchhttps://dotat.at/ Rattray Head to Berwick upon Tweed: Variable 3 at first in central areas, otherwise west or northwest 4 to 6, becoming cyclonic 3 to 5, then variable 3 or less later. Slight or moderate near Rattray Head, but elsewhere smooth or slight. Fair, then drizzle or showers. Good, occasionally moderate. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS
Viktor Dukhovni wrote: > > If applications make unwarranted assumptions about the syntax of > DNS replies, that's surely an application bug, rather than an issue > in DNS. I particularly liked this paper because it's a really good example of a common cause of security problems: when it isn't clear whose responsibility it is to enforce an important restriction, in this case, hostname syntax vs. DNS name (lack of) syntax. And different implementers have made different choices, for instance whether the libc stub resolver enforces hostname syntax or not. And another classic vulnerability generator: standard APIs that make it easy for non-specialists to step on every rake in the grass. In this case, if an application needs something more fancy than getaddrinfo(), it has to contend with the low-level resolver API which is just about better than nothing for parsing DNS packets, but certainly won't help you handle names that ought to have restricted syntax (service names, mail domains, etc...) So I don't think the problems can be dismissed as simply application bugs: the problems come from mismatches in expectations at the boundary between the DNS and the applications. And the DNS is notorious (the subject of memes!) for being far too difficult to use correctly. Tony. -- f.anthony.n.finchhttps://dotat.at/ Selsey Bill to Lyme Regis: West or northwest 3 to 5. Smooth or slight, occasionally moderate in east. Showers later. Mainly good. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS
David Malone pointed out to me on Twitter a paper from this year's USENIX security symposium. It has an impressive collection of attacks on applications that use the DNS. https://www.usenix.org/conference/usenixsecurity21/presentation/jeitner Tony. -- f.anthony.n.finchhttps://dotat.at/ Fair Isle: Southeast, becoming cyclonic, then northwest later, 3 to 5,. Rough at first in west, otherwise slight or moderate. Showers. Good occasionally moderate. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Checking for signatures of a certain DNSKEY within a zone
Klaus Darilion wrote:
>
> dig ... axfr | grep RRSIG | grep $KEYID
>
> This worked fine for long time but when having keys with the same keyid this
> obviously does not work anymore.
If it is one of your zones then your key management software should ensure
that all the key IDs are different, i.e. if there is an ID collision when
generating a key, throw it away and regenerate it. This is important for
verification performance (and, I would guess, less risk of encountering
bugs).
> So I want to change my code to additionally check if the signature can
> be verified with the respective public key. Are there any tools (bash,
> php ...) which accepts single RRSIG RR and single DNSKEY RR and does
> the validation?
Each signature covers the entire RRset, so you need all the DNSKEY
records.
Dunno if there's an easier tool, but it's not too bad with Net::DNS.
I tried this out with ac.uk which is signed with both zsk and ksk, and
cam.ac.uk which is signed with just ksk.
#!/usr/bin/perl
use 5.10.0;
use warnings;
use strict;
use Net::DNS;
use Net::DNS::SEC;
use Net::DNS::SEC::Keyset;
my (@key,@sig);
my $resolver = Net::DNS::Resolver->new();
$resolver->dnssec(1);
my $reply = $resolver->send(@ARGV, 'DNSKEY')
or die $resolver->errorstring;
for my $rr ($reply->answer) {
push @sig, $rr if $rr->type eq 'RRSIG';
push @key, $rr if $rr->type eq 'DNSKEY';
}
for my $rr (@key, @sig) {
$rr->print;
}
die "no DNSKEY RRset found" unless @key;
die "no RRSIG(DNSKEY) found" unless @sig;
my $keyset = Net::DNS::SEC::Keyset->new(\@key, \@sig)
or die Net::DNS::SEC::Keyset->keyset_err;
for my $key (@key) {
my $id = $key->keytag;
my $ok = $keyset->verify($id);
my $err = Net::DNS::SEC::Keyset->keyset_err;
printf "key %d %s verify %s %s\n",
$id, $key->sep ? "ksk" : "zsk",
$ok ? "ok" : "fail", $err;
}
Tony.
--
f.anthony.n.finchhttps://dotat.at/
the quest for freedom and justice can never end
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] why does that domain resolve?
Warren Kumari wrote: > > At the moment the main site that I'm recommending for this is IIS.SEs > Zonemaster - https://zonemaster.iis.se/ and DNSViz. > > Zonemaster is really close, but I'd like a few other options as well. > DNSViz is, of course, excellent for DNSSEC debugging, but it can be fairly > confusing to less experienced people trying to debug non-DNSSEC issues. There's also https://dnssec-analyzer.verisignlabs.com/ but it is also mainly about DNSSEC. (Worth noting that when you update a domain object in the RIPE database, it uses Zonemaster to check that the new setup is cromulent.) > So, what are people's favorite tools, especially those that you can just > point a user at? I wouldn't point a user at any of these unless I think they have a good amount of DNS expertise :-) In my work many of the difficult or time-consuming support issues are related to domain registration rather than DNS, so I have Mixed Feelings about the state of whois etc. Tony. -- f.anthony.n.finchhttps://dotat.at/ Bailey: Southwest becoming cyclonic, 5 to 7. Rough or very rough. Showers. Good. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] validating zones before distribution to secondaries
A. Schulze wrote: > > > https://github.com/fanf2/nsnotifyd > > Yes, Tony's program it's a little bit tricky to build but works... I am really pleased to hear that you have found nsnotifyd helpful! It's hard to tell if silence is due to happy users or no users :-) I regret that I am pathologically ignorant about autoconf. I hate using it to build other people's software so I don't use it in my build systems. Sorry if my basic Makefile has caused trouble for you. nsnotifyd is somewhat problematic because it is relatively oldskool C and relies on the ancient BIND resolver library. (Or the libc resolver if that works.) I tried to be careful when I wrote it, but its foundations are not very firm... [ our house is on the site of an old brickworks, and a map from 1888 shows there was a water-filled pit somewhere nearby; when they were demolishing the warehouse at the back of our garden to build flats, our house shook in sympathy - yeah, the foundations are not very firm! ] Tony. -- f.anthony.n.finchhttps://dotat.at/ protect and enlarge the conditions of liberty and social justice ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Dan Kaminsky has passed away
James Stevens wrote: > I see Sarah (his niece) has made an appeal for a copy of a video, maybe > somebody in this group might have a copy? "Sarah on DNS" is in the replies: https://twitter.com/balaziks/status/1386413832457703424 Tony. -- f.anthony.n.finchhttps://dotat.at/ Biscay: Northeasterly 5 or 6, but cyclonic 2 to 4 in south, becoming north or northwest 3 to 5. Slight or moderate. Showers in south. Moderate or good. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] nsec vs nsec3 use
Grant Taylor via dns-operations wrote: > On 4/12/21 7:51 PM, Viktor Dukhovni wrote: > > my advice is to use NSEC unless you have an absolutely compelling > > case to attempt to deter zone enumeration > > Would you please elaborate on why that is your opinion / advice? > > It seems contrary to the litmus test of which is more secure vs > difficult to implement. Well, NSEC3 is definitely complicated, difficult to understand and debug, and it has parameters that need some expertise to configure. At least Wes and Viktor have a draft in progress to provide advice to those who choose NSEC3. https://tools.ietf.org/html/draft-hardaker-dnsop-nsec3-guidance NSEC3 gives you two things that NSEC does not: 1. opt-out, useful for zones that have a very large number of unsigned delegations; 2. an obfuscated list of names in the zone. Static NSEC3 can't provide any serious protection against zone enumeration, because DNS names are friendly to people and therefore an ideal candidate for password crackers. (If anyone populates their zones with the output from `pwgen` I will be both very entertained and eager to speak to their users.) And NSEC3 can't use the kind of work-hardening that password hashes use to protect against cracking, because high iteration counts are absolute murder to both authoritative servers and validators. Hence Wes and Viktor's draft recommends an iteration count of 0 (i.e. hash once). Maybe use NSEC3 if you have a stunt DNS server like Cloudflare's that is able to generate narrow NSEC3 denials, or if you are a large TLD without DNSSEC incentives, but otherwise NSEC3 gives you a lot of pain for no real benefit. Tony. -- f.anthony.n.finchhttps://dotat.at/ North Bailey: Southwesterly 3 to 5. Moderate. Showers. Good. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] cheap traffic measure for a small set of zones
Randy Bush wrote: > is there a simple tool to run on a server to measure query and data > rates for a small set of zones? i just want to run it for a day. > > it is a a bind9 server which serves a few hundred zones. i would like > to know the query rate and byte count for six of them. I usually use BIND's built-in statistics server for this kind of thing, but it looks like it can count queries per zone but not bytes per zone. (my servers are configured with `zone-statistics full;`) e.g. $ curl -sf http://auth0:8053/json/v1 | jq -r '.views.main.zones[] | "\(.name) \((.rcodes.QryUDP) + (.rcodes.QryTCP))"' | grep ^cam.ac.uk cam.ac.uk 1294381958 That's queries since the server started. [ jq is a bit of a puzzle language; I often prefer gron | grep ] https://stedolan.github.io/jq/ https://github.com/TomNomNom/gron Tony. -- f.anthony.n.finchhttps://dotat.at/ Fair Isle: Westerly, backing southerly later, 5 to 7, perhaps gale 8 later in west. Rough or very rough, occasionally moderate in southeast. Wintry showers. Good, occasionally poor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Verisign won't delete obsolete glue records?
Andrew Sullivan wrote: > > The disadvantage of a nameserver-attribute arrangement is that, if the > domain in question gets deleted, there isn't really a way within EPP > to refuse that, because there's no necessary relationship between the > nameserver attributes (they're just attributes, after all) and the > domain object that is being removed. So there's a greater opportunity > to create lame delegations. But that check doesn't work for delegations that span mutiple registries. If gratisdns.dk disappears there's nothing nic.at can do about the now-lame nameserver attributes on dotat.at. And there were earlier discussions in this thread about how registrars can force delegations to go lame so that they can cancel a deadbeat customer's domain. (Yeah, I'm kind of grumpy about EPP host objects. I can't just write an API client that says, make my domain's delegation look like this. The combination of inter-object dependencies and asynchronous updates makes for a ridiculously complicated state machine that has to poll waiting for changes to take effect. Yuck.) Tony. -- f.anthony.n.finchhttps://dotat.at/ Fair Isle: Northerly or northeasterly backing northwesterly 3 to 5, occasionally 6 in north and east. Moderate, occasionally rough in north and east. Wintry showers. Good, occasionally poor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Verisign won't delete obsolete glue records?
Andrew Sullivan wrote: > > [1] There is a mode of EPP in which nameservers are properties of domain > objects instead of first-class objects that are associated, but AFAIK anyone > who thought that was a good idea gave it up. If you renumber a host in such a > case you have to update every associated domain, and there isn't really a way > to look it up. As far as I know, registries that don't have separate host objects require glue in fewer situations than Verisign-style registries. For example, if I change the delegation for dotat.at to include ns.example.at, I don't provide an IP address for ns.example.at because it doesn't belong to me, and the owner of example.at would not be able to keep my copy of the address of ns.example.at correct. If the address of ns.example.at changes, only the example.at domain object needs to change, and only if it uses ns.example.at as a nameserver. There's no need (and no possibility) to update every other domain that uses ns.example.at. Domain-only registries in effect only require glue addresses that the DNS needs to work, whereas domain+host registries demand more glue addresses than they need. From my perspective as a registrant domain-only registries seem to be a lot less troublesome, since my delegation management tools can work purely one domain at a time, without having to be concerned with cross-domain host object dependencies. Tony. -- f.anthony.n.finchhttps://dotat.at/ Northeast Fitzroy, Sole: Easterly or southeasterly 3 to 5. Moderate, occasionally slight at first in east, becoming rough at times in far south and far west. Occasional rain or showers. Moderate or good, occasionally poor at first in Sole. f...@mile.dotat.at:~ (master) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Possibly-incorrect NSEC responses from many RSOs
Viktor Dukhovni wrote: > > The RFC 4035 language is sound for NSEC and DNSKEY, but (and this is a > related side topic), I rather think that the specification should have > said that queries for "RRSIG" for an extant name should return a single > RRSIG of their choice, rather than treat RRSIG records as a normal > RRSet. There's some relatively feeble verbiage about this in RFC 8482 (minimal responses to ANY) - https://tools.ietf.org/html/rfc8482#page-8 BIND does what you suggest if you turn on the minimal-any option. Tony. -- f.anthony.n.finchhttps://dotat.at/ Humber, Thames, Dover: East or northeast 3 or 4, occasionally 5 at first. Slight, occasionally moderate at first in Dover, becoming smooth or slight later. Fog patches in Dover, fog banks elsewhere. Moderate to very poor, occasionally good in Dover. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Support for ED25519/ED448 DS records by OpenSRS
Viktor Dukhovni wrote: > > Nitpick: the block size of SHA-1 is 512 bits or 64 bytes. Thanks for the correction - I misread my own draft, oops :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ Whitby to Gibraltar Point: Southwesterly 3 or 4, backing southerly 5 to 7, occasionally gale 8 later in far north. Smooth or slight, becoming slight or moderate later. Fog patches and occasional drizzle, becoming fair later. Moderate or good, occasionally very poor until later. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Support for ED25519/ED448 DS records by OpenSRS
Florian Weimer wrote: > > The registry signs the DS RRset with its own key. It's good practice > to apply as many checks as possible when signing data supplied by > untrusted parties. Having to show the DNSKEY record for a DS record > makes sure the embedded hash in the DS record is genuine, which > prevents all known evil twin attacks on cryptographic signature > schemes. Very few TLDs receive DNSKEY records from their registrants, so they aren't in a position to make this check. (TLDs shouldn't restrict DS keys to published DNSKEY records because that prevents double-DS KSK rollovers. CDNSKEY records avoid this problem but they are not published as routinely as they ideally would be.) > SHA-256 is not publicly known to be broken as of today, of course, but > if that changes, such evil twin attacks are likely the first ones to > arrive (see MD5 and SHA-1). DS data checking looks like a reasonable > way to increase the safety margin. Yes, but there are simpler ways for a TLD to protect itself than by regenerating the DS hash: just check that the DS digest type is known and the digest is the correct length for the digest type. There's no need to check the DNSKEY algorithm or the contents of the digest. Hash collision attacks need at least a couple of input blocks to work. (For instance, the SHA-1 input block size is 128 bytes and a SHAMBLES collision needs 588 bytes.) This is generally bigger than the hash output size (20 bytes for SHA-1, 32 bytes for SHA-256) so a correctly-sized DS record is too small to use for a signature collision attack. https://tools.ietf.org/html/draft-fanf-dnsop-sha-ll-not-00#section-5.5 Tony. -- f.anthony.n.finchhttp://dotat.at/ individual and social justice ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] dnstap tool
Hoan Vu wrote: > > We are learning to get query log by dnstap tool. For DNSTAP Tool we cannot > get log query continuosly and directly to the current syslog server, since > raw log need to capture and then read after stop capture. Earlier today I saw a tweet from JP Mens about this which might help you (I have not tried it myself) https://github.com/dmachard/dnstap-receiver https://twitter.com/jpmens/status/1325724102078963712 Tony. -- f.anthony.n.finchhttp://dotat.at/ Southeast Iceland: Southerly, becoming cyclonic later, 4 to 6, occasionally 7 later. Moderate or rough. Occasional rain. Moderate occasionally poor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Google (formerly also CF) public DNS sometimes forwards incomplete subset of NSEC RRs
Brian Somers wrote: > This is an interesting behaviour from google. It’s not wrong… It is wrong :-) But Viktor's description is slightly mangled. The NSEC records that need to be present in the answer are munin01.runbox.com. IN NSEC ipmi.mysql01.runbox.com. A RRSIG NSEC which proves _25._tcp.mx.runbox.com does not exist (i.e. Mark's note about the no qname proof also doing duty as closest encloser proof), and *.runbox.com. IN NSEC _acme-challenge.runbox.com. A MX RRSIG NSEC which says there is a wildcard that matches the qname but it doesn't have a TLSA RRset. The zone apex isn't involved at all apart from the SOA being part of an RFC 2308 no data type 2 response. The wildcard's NSEC doesn't cover the qname so it isn't enough by itself. (I prefer to call it a top-of-zone wildcard and reserve the term "apex" for the records at the zone name below the cut.) Tony. -- f.anthony.n.finchhttp://dotat.at/ the widest possible distribution of wealth___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] systemd resolved ignores specified root
Dave Lawrence wrote: > > On this point, it just has no idea whether the original input that > started off the lookup had the trailing dot. I don't think that's true: the interface between glibc and systemd-resolved uses a special NSS module and a D-Bus interface, not the DNS protocol. If I understand the docs correctly, the name sent over D-Bus is what the user typed without even IDNA conversion. https://www.freedesktop.org/software/systemd/man/nss-resolve.html https://www.freedesktop.org/wiki/Software/systemd/resolved/ (reminds me of lwresd...) Tony. -- f.anthony.n.finchhttp://dotat.at/ North Fitzroy: Northeast becoming cyclonic later, 5 to 7. Moderate or rough. Thundery showers. Mainly good. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] DNS Flag Day 2020 will become effective on 2020-10-01
Paul Vixie wrote: > > happily, that's not known about PLPMTUD (RFC 8899 & 8900). so right now > there's new hope, yet undashed. I'm trying to understand how PLPMTUD can help the DNS. The DNS doesn't have a paketization layer as such - any time the DNS needs to get a big message over a pipe that's too narrow, we get TC and fallback to TCP which does the packetization for us. My very superficial understanding is that PLPMTUD is based on application-level probe / timeout / retry instead of ICMP errors. DNS resolver implementations have machinery to probe the largest working EDNS buffer size, so we already have something in the same ballpark as PLPMTUD. For me the questions are: * what's the hard ceiling on a resolver's EDNS buffer size? * what's a resolver's starting probe buffer size? * how complicated is the resolver's probe algorithm? * what's the ceiling on an auth server's UDP response size? Tony. -- f.anthony.n.finchhttp://dotat.at/ Dover, Wight: Northeast 5 to 7. Moderate. Fair. Good. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] FlagDay 2020 UDP Size
jack tavares wrote: > > I have gone through the archives, is there consensus on this at this time? > For both the date of Flag Day (Which appears to be 1st October 2020, > pending confirmation from google) > and for the suggested default? There are some interesting measurements in https://rp.delaat.net/2019-2020/p78/report.pdf Tony. -- f.anthony.n.finchhttp://dotat.at/ Rattray Head to Berwick upon Tweed: Variable at first in north, otherwise southwesterly, 3 or 4, occasionally 5 at first in south, backing southerly 5 to 7 later. Smooth or slight, becoming slight or moderate later, occasionally rough later in north. Showers at first, rain later. Good, occasionally moderate later. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Wormable RCE in MS Windows DNS Server CVE-2020-1350
Brian Somers wrote: > RFC 3597 section 4 backtracks on this a little and suggests that resolvers > SHOULD decompress SIG (and others) because it was a mistake to allow > it to be compressed in the first place. Oh! thanks for pointing that out, I had it in my head that compression was simply not allowed for records newer than RFC 1035, but of course this is the DNS so "simply" is always a snare and a delusion. Tony. -- f.anthony.n.finchhttp://dotat.at/ Shannon, Rockall: Variable 3 or 4 backing south or southeast, veering southwest later, 5 or 6. Slight or moderate. Occasional rain, fog patches. Moderate or good, occasionally very poor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Wormable RCE in MS Windows DNS Server CVE-2020-1350
Alexander Bochmann wrote: > > Would other nameservers drop a reply where this scheme with pointer > compression resulting in a very large Signer's Name field is > being used? It doesn't look invalid as such. Name compression isn't allowed in SIG / RRSIG / NSEC, which are the records that can be used to trigger this bug. A server would be justified to drop responses with compressed names in the wrong place, but I don't know how strict other implementations are in practice. Tony. -- f.anthony.n.finchhttp://dotat.at/ promote human rights and open government ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] prefetching and thundering herds
Mark Delany wrote: > > But in terms of thundering herds, it's still seem no worse than if none of > the stub > resolvers cached. > > However, I can see how if the choice is between stub caches which "smear" TTL > (regardless > of mechanism) and stubs which don't "smear", the smearers are probably a > little nicer to > recursive resolvers which incur high costs queuing duplicate queries. Right. > But then I have to wonder, is there a fundamental reason why recursive > resolvers perform non-linearly as the arrival rate of identical queries > increases? It's the bimodal behaviour between cache hits and misses, and the higher the query rate the more queries arrive while the cache is being refilled. I think it only gets nonlinear if the recursive server's query deduplication is nonlinear. I was probably wrong to worry about thundering herds - I was thinking about them because I started wondering about synchronized cache expiry in a somewhat different context. Then I noticed that stub caches might stymie prefetching... Tony. -- f.anthony.n.finchhttp://dotat.at/ Viking, North Utsire: Variable 3 or less, becoming southerly 4 or 5, occasionally 6 later in north. Slight, occasionally moderate later. Showers. Good. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] prefetching and thundering herds
Mark Delany wrote: > On 15Jul20, Philip Homburg allegedly wrote: > > From the point of view of latency hiding, it may make sense to always > > reduce the ttl so that a recursive resolver can reply to the stub > > resolver immediately and simultaniously trigger a refresh Yes, I was wondering if "always" will work well enough, or (if there is in fact enough of a herd to be worth trying to spread it out) whether something jittery might be a bit better. Bert's post suggested that the load is spread across enough domain names that TTL expiry herds are more like a whisper than a thunder, so as he said, if there is any prefetch logic it should err on the side of simplicity... > That's a clever idea, tho it does presuppose that most of the stubs > are caching. In the worst case where no stubs are caching, all that's > been achieved is to increase the query rate to the recursive resolver. If they aren't cacheing the stubs will be ignoring the TTL from the recursive server so it doesn't matter how the TTL is adjusted :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ Rockall, Malin, Hebrides: West 4 or 5, backing southwest 5 to 7. Moderate becoming rough. Drizzle, fog patches. Moderate or good, occasionally very poor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] prefetching and thundering herds
Mark Delany wrote: > > I'm not sure how a stub cache could make things worse. I'm wondering if the stub caches catch the queries that would otherwise cause a prefetch, so instead of a newly hot cache in the recursive server, the stubs encounter a high latency refill. But as you say, the unlucky slow queries are probably not any more likely than they are without stub caches. Tony. -- f.anthony.n.finchhttp://dotat.at/ Berwick upon Tweed to Whitby: Variable 3 or less, becoming west 3 or 4 for a time. Smooth or slight. Occasional rain at first. Moderate becoming good. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] prefetching and thundering herds
I've been wondering about the effects of stub resolvers with caches as clients of recursive servers. To what extent do they cause a thundering herd effect where all the cache entries expire with the same deadline? The herd will arrive when the RRset expires so most of those clients will hit maximum latency and stress the server's query deduplication mechanism. (I don't think I have enough traffic to get a useful answer from my servers right now.) If thundering herds happen, do they thunder enough to help explain the lack of benefit from prefetching observed by PowerDNS? Or maybe is the herd is too small to thunder? Instead there's a more gentle swell of queries after the TTL expires? https://lists.dns-oarc.net/pipermail/dns-operations/2019-April/018605.html If there is much of a herd, would it make sense to give some proportion of the clients a slightly reduced TTL so that they will trigger prefetch before the rest of them requery? Tony. -- f.anthony.n.finchhttp://dotat.at/ Bailey: Southwest 4 or 5, increasing 6 or 7 later. Moderate or rough, occasionally very rough later in far northwest. Drizzle, fog patches. Moderate or poor, occasionally very poor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] RFC 6975 (was: Re: Algorithm 5 and 7 trends (please move to 8 or 13))
My rule of thumb is that the initiator's service provider bears the cost of any interop problems whether they want to or not, regardless of whether they deserve to. So for the DNS that's the recursive server. For email, outgoing MTAs have to deal with the interop fallout from anti-spam checks. For the web, browsers ditched xhtml because it made interop harder. Tony. -- f.anthony.n.finchhttp://dotat.at/ Shannon: Southwest veering northwest, 4 or 5, occasionally 6 later. Slight or moderate, becoming moderate or rough later. Occasional drizzle. Good, occasionally poor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Cloudflare Rose and Rick in .com authoritative Nameserver
Raffaele Sommese wrote: > > Rose and Rick are not in-bailiwick records required for the resolution > of cloudflare.com (that use ns3-ns7.cloudflare.com as authoritative > NS). > > So, why these records are in the .com authoritative server? Different registries have different rules about glue records. Some require glue addresses for any nameserver that is a subdomain of the registry (.com in this case), not just for in-bailiwick delegations. I call this "sibling glue". There was a fairly informative discussion when I asked about it a few years ago: see the thread starting at https://lists.dns-oarc.net/pipermail/dns-operations/2015-June/013402.html Tony. -- f.anthony.n.finchhttp://dotat.at/ Biscay, East Fitzroy: Cyclonic 4 or 5, occasionally 6 in north, becoming variable 3 at times. Slight or moderate becoming moderate or rough. Showers. Good, occasionally moderate. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] solutions for DDoS mitigation of DNS
Tessa Plum wrote: > > Does RRL work based on IP addr? but the requesting IP seems spoofed. RRL is based on the contents of the DNS response as well as the IP address. Usually for a DDoS attack the IP address is spoofed as the address of the victim, so rate limiting reduces the amount of response traffic sent to the victim. Tony. -- f.anthony.n.finchhttp://dotat.at/ Cromarty, Forth: Northwest 6 to gale 8, occasionally severe gale 9 at first in Cromarty, backing west 4 to 6. Very rough at first in northeast Cromarty, otherwise moderate or rough. Squally wintry showers. Good, occasionally poor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] solutions for DDoS mitigation of DNS
Stephane Bortzmeyer wrote: > On Thu, Apr 02, 2020 at 03:06:49AM +, > Paul Vixie wrote > a message of 29 lines which said: > > > to keep your own recursive servers from amplifying spoofed-source > > attacks, you need ACL's that make it unreachable outside your > > specific client base. > > ACLs in the server are not enough, you also need ingress filtering on > the borders of your network, to prevent packets claiming to be from > your network to get inside. That kind of ingress filtering protects you against DDoSing yourself, which maybe the rest of the Internet isn't too bothered about :-) You ALSO need ACLs on all the crappy consumer routers to stop their DNS forwarders from being used in an attack. And BCP38. Both of these are not as common as they should be :-( You can configure your authoritative servers to be less attrative for use in DDoS attacks: as well as RRL, configure minimal responses, minimal ANY, roll to DNSSEC algorithm 13 instead of RSA (all help to keep response sizes small), and set your UDP size limit to less than one MTU (to reduce packet count amplification). Tony. -- f.anthony.n.finchhttp://dotat.at/ no one shall be enslaved by poverty, ignorance, or conformity ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Any DNAME usage experience?
Meir Kraushar via dns-operations wrote: > > I looking for insights, usage experience regarding DNAME record > implementation. If any compatibility issues, client side problems, > resolvers etc?.. Highly apperciate If anyone could share their > knowledge. At Cambridge University we're using DNAMEs for classless reverse DNS delegation for shorter prefixes, originally to minimize the number of zones when 128.232.128.0/17 was delegated, and more recently to handle the way we split 10.0.0.0/9 for departments and 10.128.0.0/9 for the University as a whole. https://tools.ietf.org/html/draft-ietf-dnsop-rfc2317bis https://www.dns.cam.ac.uk/domains/reverse/ It works OK except that we had problems with a mail server: some recipient sites had buggy mailers that could not understand DNAMEs in the reverse DNS so rejected mail. The problem was fixed by changing the mail server's /24 to use a forest of CNAMEs instead of a DNAME. I had wondered if DNAME support had improved enough in the last 10 years to make this workaround unnecessary, but sadly it sounds like there are still too many buggy resolvers :-( There was also some annoyance with the glibc resolver: it would chatter into syslog about unexpected records (i.e. DNAMEs) when parsing DNS responses. This was fixed years ago. Tony. -- f.anthony.n.finchhttp://dotat.at/ Ardnamurchan Point to Cape Wrath: North or northwest, backing west or northwest, 4 or 5. Moderate occasionally rough in north. Showers. Good. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] creeping poorness of judgement
Viktor Dukhovni wrote: > > While it does present a case that lines up with Paul's preferred > semantics, I don't find the Net::DNS txtdata() behaviour in scalar > contexts either normative or particularly compelling. :-( Indeed, it's just one of the many things that turn out to be quite annoying when trying to deal with SPF. Tony. -- f.anthony.n.finchhttp://dotat.at/ South Rockall, Malin: Southwesterly 5 to 7. Very rough or high. Rain or showers. Good, occasionally poor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] creeping poorness of judgement
Viktor Dukhovni wrote: > > I know of no specifications that concatenate TXT RR strings with spaces. Not a spec, but Net::DNS does https://www.net-dns.org/docs/Net/DNS/RR/TXT.html Tony. -- f.anthony.n.finchhttp://dotat.at/ Isle of Man: Southwest 6 or 7 decreasing 4 or 5, then increasing 6 to gale 8 later. Moderate or rough. Rain at times. Good, occasionally moderate. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Re: Is this DNS Flag Day 2020 including 'in-addr.arpa.' and 'ip6.arpa.' clean-up?
Pirawat WATANAPONGSE wrote: > > 1. There are old DS keys from .arpa to in-addr.arpa still dangling around. This might be part of a rollover plan (I don't track changes to .arpa so I can't tell how old the DS records are) > 2. 158.in-addr.arpa is still using ‘Algorithm 5’ Yes, this needs fixing. > 3. Even though my 158.108.0.0/16 netblock was ROAed, APNIC did not link me > to the ‘reverse’ DNSsec chain: > 3.1. Why? Because it’s a ‘Historical’ netblock, transferred from ARIN to > APNIC epochs ago. So, my ‘domain’ is with NIR (thank god), my ‘netblock’ > Whois is now with APNIC, but my ‘reverse’ is still with ARIN. > 3.2. If I want to hook into the ‘reverse’ DNSsec chain, who do I send my DS > key to? APNIC? ARIN? > 3.2.1. APNIC is not the SOA of 158.in-addr.arpa. > 3.2.2. I am no longer a ‘client’ of ARIN, the SOA of 158.in-addr.arpa. Yes, it is complicated, especially for legacy allocations, but I don't think it is particularly broken. I have a similar situation with the reverse DNS for 131.111.0.0/16. The registration for the address block is with RIPE, but the reverse DNS delegation is via ARIN. The way this works is that I do all administration via RIPE (configuring NS and DS records, etc.), and RIPE send zone file fragments to ARIN, which incorporate them into the DNS. I think I found out about this from an outage report a few years ago: https://labs.ripe.net/Members/anandb/reverse-dns-outage-for-out-of-region-address-space The situation for whois is somewhat worse than the reverse DNS. I've done some work on the FreeBSD whois client, which tries to work by following referrals instead of having built-in knowledge about which whois servers to ask. This mostly works OK, except that APNIC and RIPE don't put any kind of referral in their whois responses even though they know which other RIR is responsible for the adress block. When that happens my whois client tries ARIN (which usually works) or falls back to trying each RIR in turn... Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Northeasterly 5 to 7, occasionally gale 8 later in southeast, becoming variable 4 in northwest. Moderate or rough. Showers. Moderate or good.___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Re: Is this DNS Flag Day 2020 including 'in-addr.arpa.' and 'ip6.arpa.' clean-up?
Edward Lewis wrote: > > I'm looking at the delegation information in the two zones and the > information at the zones they delegate. As far as delegations from > those zones to RIR run zones, I'd say they are perfect. Except that ARIN and LACNIC use RSASHA1 :-( Tony. -- f.anthony.n.finchhttp://dotat.at/ Mull of Kintyre to Ardnamurchan Point: South 6 to gale 8 veering southwest 4 or 5, then west 6 to gale 8 later. Moderate in shelter, otherwise rough or very rough, but occasionally high later near Tiree. Rain then showers. Moderate or good, occasionally poor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] SHA-1 and DNSSEC validation
I've posted a follow-up to my article last month about SHA-1 chosen prefix collisions and DNSSEC. This discusses DNSSEC validation: https://www.dns.cam.ac.uk/news/2020-02-14-sha-mbles.html Summary: DNSSEC validators should continue to treat SHA-1 signatures as secure until DNSSEC signers have had enough time to perform algorithm rollovers and eliminate SHA-1 from the vast majority of signed zones. Tony. -- f.anthony.n.finchhttp://dotat.at/ Viking, North Utsire, South Utsire, Forties, Cromarty: Southerly 6 to gale 8, occasionally severe gale 9 except in South Utsire, veering southwesterly 4 to 6 for a time. Rough or very rough, occasionally moderate. Rain or showers. Good, occasionally poor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNS Flag Day 2020
Viktor Dukhovni wrote: > > Unfortunately, I don't see a way to separately configure the *upstream* > and *downstream* EDNS buffer sizes. I believe that the edns-buffer-size option determines what is put in the OPT record for outgoing queries from Unbound to the world, and the max-udp-size option determines the size of responses that Unbound will send to its clients. Tony. -- f.anthony.n.finchhttp://dotat.at/ Lough Foyle to Carlingford Lough: West 7 to severe gale 9, occasionally storm 10 for a time. Rough or very rough, becoming high or very high in northwest. Thundery wintry showers. Moderate or poor, occasionally good in east. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] SHA-1 (algs 5 and 7), planning to switch to something non-deprecated?
Looking for algorithm rollovers in the root zone, the most recent is .buy which also has the distinction of taking a remarkably long time: 2017051000 buy. 86400 IN DS 18204 7 1 ... buy. 86400 IN DS 18204 7 2 ... +buy. 86400 IN DS 37087 8 1 ... +buy. 86400 IN DS 37087 8 2 ... 2019052202 buy. 86400 IN DS 16411 8 2 ... -buy. 86400 IN DS 18204 7 1 ... -buy. 86400 IN DS 18204 7 2 ... -buy. 86400 IN DS 37087 8 1 ... -buy. 86400 IN DS 37087 8 2 ... Next most recent were: 2018110601 .ad 7 -> 8 2018103002 .nu 7 -> 13 2018082002 .br 5 -> 13 2018011800 .ke 5 -> 8 I did some sketchy counting of top-level reverse DNS delegations. Columns are number of delegations (x) digest types, algorithm number, registry. (All our PI v4 address space is under ARIN's reverse DNS.) IPv4 1 x 12 8 dns.jp. 6 x 12 8 AFRINIC 10 x 12 5 ARIN 10 x 12 5 LACNIC 15 x unsigned 16 x 12 8 IANA 41 x 2 8 RIPE 50 x 2 13 APNIC 81 x 1 5 ARIN IPv6 3 x 12 5 LACNIC 3 x 12 8 AFRINIC 8 x unsigned 11 x 1 5 ARIN 12 x 2 13 APNIC 22 x 2 8 RIPE Tony. -- f.anthony.n.finchhttp://dotat.at/ Forth, Tyne, Dogger, Fisher, German Bight, Humber: West or southwest 5 to 7, occasionally gale 8, except in Fisher. Moderate or rough. Occasional rain or showers. Good, occasionally moderate. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] any registries require DNSKEY not DS?
Thanks for all the interesting replies! The reason for the question is to do with child-side tools for updating delegations. RFC 7344 CDS/CDNSKEY records are brilliant for this because they provide a standard interface between key management / signing software and registr* API client software: the registr* client can just [*] look at a zone file to work out what the delegation should be. And clearly a generic "gimme the secure delegation" function needs to have both DS and DNSKEY modes. [*] modulo caveats about glue records Tony. -- f.anthony.n.finchhttp://dotat.at/ the quest for freedom and justice can never end ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] any registries require DNSKEY not DS?
Viktor Dukhovni wrote: > > Which is not to say that one should continue to use SHA-1 in DS RRs, > there but there is little risk in doing for the foreseable future. Right. Getting rid of SHA-1 in DS and CDS might not be cryptographically necessary [*], but it's required for protocol conformance, and it's important to actually make visible progress to deprecating SHA-1 even if we start with the easy but less important steps. [*] Registries that don't check DS parameters, like the examples you gave, are vulnerable so chosen prefix collisions if they are relaxed enough to allow 800-ish bytes of digest... Tony. -- f.anthony.n.finchhttp://dotat.at/ Shannon: Variable 4 or less, becoming south or southwest 4 to 6. Moderate, becoming rough in northwest. Mainly fair. Good. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] any registries require DNSKEY not DS?
Warren Kumari wrote: > > I believe that at least SIDN used to (and perhaps still does) - this > was one of the reasons that the CDS record is actually CDS/CDNSKEY. > > When I first heard this I was confused as to why they'd do this -- but > then Antoin Verschuren / Cristian explained that they'd like to make > sure that a good hash is being used, and suddenly I started wondering > why this isn't the default...:-) In fact I have made use of this! In more than one way! I did some work on BIND last year to implement RFC 8624 section 3.3 - death to SHA-1 DS records! But I left out the dnssec-cds utility (parent-side implementation of RFC 7344) which already defaulted to SHA-256. However during my cam.ac.uk algorithm rollover project (remember, folks, RSASHA1 is shafted) I found a lacuna: By default dnssec-cds copies CDS records to make DS records, and the question of SHA-256 or something else only arose when it was asked to turn CDNSKEY records into DS records. But if the CDS records are generated by some ancient code from before the dawn of time, such as BIND 9.14 on my production servers, there will be SHA-1 CDS records which will be copied to the DS records. Sadface, RFC 8624 protocol violation. So I fixed dnssec-cds to filter out SHA-1 CDS records. And, if the child turns out to have been so foolish as to use only SHA-1, dnssec-cds will now fall back to using the CDNSKEY records to make SHA-256 DS records instead. In production for my child zones I've faked this by telling dnssec-cds (9.14 sans patch) to only look at CDNSKEY records. All in all this is a practical example of daddy knows best wrt choice of DS digest types. Tony. -- f.anthony.n.finchhttp://dotat.at/ Faeroes: Southwest 6 to gale 8, veering west 7 to severe gale 9. Very rough or high. Rain then wintry showers. Good, occasionally poor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] any registries require DNSKEY not DS?
Are there any registries that configure secure delegations from DNSKEY records (and do their own conversion to DS records) rather than accepting DS records from the registrant? I think I have heard that .de is one. Looking at OpenSRS as an example of a registrar that supports lots of TLDs, I see that they don't support DNSSEC for .de http://opensrs.help/chart and their API only supports DS records https://domains.opensrs.guide/docs/set_dnssec_info Also, I am uncomfortable with the endianness of their support domain names... Tony. -- f.anthony.n.finchhttp://dotat.at/ responsible stewardship of the earth and its resources ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] SHA-1 chosen-prefix collisions
Viktor Dukhovni wrote: > > The longer suffix could for now rule out misuse of TXT records since > each chunk of a TXT record is at most 255 bytes. I've updated my article to account for this. An attacker can add a fixed trailer of 255 zero bytes after the collision blocks to deal with substring lengths. The first part of the trailer uses up any remaining space in the last substring of the collision blocks, and the rest of the trailer is interpreted as zero-length substrings up to the end of the TXT record. Length bytes inside the collision blocks can be any old mush. https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html Tony. -- f.anthony.n.finchhttp://dotat.at/ Gibraltar Point to North Foreland: Northwesterly 4 or 5, backing southerly or southwesterly 5 to 7, perhaps gale 8 later. Slight or moderate, smooth in Thames estuary. Mainly fair. Good. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Re: help with a resolution
Matthew Pounsett wrote: > > What are the implications for NSEC3, given that both (current) algorithm > numbers rely on SHA-1? In NSEC3, SHA-1 is used for hashing domain names, which do not have enough space to fit a collision attack. Even so, RFC 5155 has a lot of contingency options for dealing with collisions; for instance, if a zone update adds a name that collides, the NSEC3 chain can be re-generated using a different salt. Tony. -- f.anthony.n.finchhttp://dotat.at/ oppose all forms of entrenched privilege and inequality ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] SHA-1 chosen-prefix collisions
Viktor Dukhovni wrote: > > A chosen-prefix attack is a powerful tool, a message with metadata P and > payload S can now have the same digest as a message with completely > different, chosen by the attacker metadata P' and payload S' (though > ultimately the combined message lengths need to be the same). There are some really nice diagrams of the overall shape of these attacks on the page about the MD5 rogue CA chosen prefix collision https://www.win.tue.nl/hashclash/rogue-ca/ especially the second diagram in section 3.5 https://www.win.tue.nl/hashclash/rogue-ca/images/diffIV.png > So the present attack requires a suffix of ~640 rather than ~200 bytes. Oh, that might make it a bit harder. This is shown in figure 7 in the SHAmbles paper? > Perhaps it is possible to split the suffix over multiple RRs, Very tricky. I get the impression from table 1 in the SHAttered paper http://shattered.io/static/shattered.pdf and figure 6 in the SHAmbles paper https://eprint.iacr.org/2020/014.pdf that the constraints on the collision blocks are too dense to overlay on parts of a message with significant syntax. (Unless maybe you are Ange Albertini.) > or at least over multiple (sub)strings in a single TXT RR. More plausible, if the length bytes in the TXT RDATA of the two colliding messages can be made to add up to the same total. (They don't have to coincide...) Tony. -- f.anthony.n.finchhttp://dotat.at/ Irish Sea: Northwest 4 to 6, backing south 6 to gale 8, perhaps severe gale 9 later. Slight or moderate, becoming rough or very rough. Occasional rain later. Good, occasionally moderate. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Re: help with a resolution
Warren Kumari wrote: > Ok, I see the concern now, and *do* feel foolish for not getting it sooner... I have learned a lot this week :-) I have been using DNSSEC for about 10 years and only this week have I had to care about the details of how an RRSIG is constructed. I saw the MD5 chosen-prefix collision certificate in 2008 and I thought, wow that's cool, but I didn't sweat the details. I saw the commentary from X.509 and TLS people about how shaky SHA-1 was in 2015, and I didn't examine the implications for DNSSEC. Same again after the SHA-1 collision in 2017. I saw the Eurocrypt SHA-1 chosen-prefix attack last year but I didn't think about the consequences. As soon as I saw the SHAmbles announcement I realised what it actually meant and that DNSSEC was in serious trouble. It took me a couple of afternoons to write the blog article. The second half and the more tricky cases owe a lot to discussions with Viktor. I, too, feel foolish for not getting it sooner - I can't complain there weren't enough clues! https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html Tony. -- f.anthony.n.finchhttp://dotat.at/ Mull of Galloway to Mull of Kintyre including the Firth of Clyde and North Channel: Mainly northwesterly 3 to 5, backing southerly 4 to 6, increasing 7 to severe gale 9 later. Smooth or slight at first in Firth of Clyde, otherwise moderate or rough. Showers, rain later. Good, occasionally poor later. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Google DNS Admin
Daniel Corbe wrote: > > Every well-known recursor is returning valid results for as57335.net > except for 8.8.8.8 and 8.8.4.4 and I'd like some assistance getting > down to the root of the issue. Maybe connectivity problems? I can't get to any of the nameservers from 131.111.0.0/16 or 2a05:b400::/32. DNSviz can see the domain OK but zonemaster cannot. https://dnsviz.net/d/as57335.net/dnssec/ https://zonemaster.net/result/0e70c5e9893a0ce8 Tony. -- f.anthony.n.finchhttp://dotat.at/ people involved in running their communities ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Surprising behaviour by certain authoritative name servers
Niall O'Reilly wrote: > > What's surprising is that an authoritative name server > shows both a decremented TTL value (as if it were answering > from cache) and the AA flag. > > I'm not sure which of the following labels is the best fit > for this behaviour: > > - normal and expected (but so far outside my experience), > - strange but harmless, > - downright wrong. I would argue somewhere between the last two :-) During the IETF dnsop ANAME work I did some thinking about the TTL implications, and I realised that decrementing the TTL on an authoritative server would cause a thundering herd effect due to caches timing out at the same time. But I don't have any measurements that would indicate how much of a problem this is in practice... https://tools.ietf.org/html/draft-ietf-dnsop-aname-04#appendix-C Tony. -- f.anthony.n.finchhttp://dotat.at/ Fitzroy: Southerly or southwesterly, 4 to 6, increasing 7 or gale 8 later in northwest. Moderate or rough, becoming very rough or high. Drizzle and fog patches. Good, occasionally very poor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] root zone weirdness
Merry xmas! I have been playing around with root zone archives. Jaap Akkerhuis has given me a large archive covering 1999 - 2015 which overlaps in useful and interesting ways with my collection and the update journal from David Malone that I wrote about before. There are a couple of anomalies that are kind of interesting. In the run-up to signing the root zone in 2010, there was a period during which it was signed but not verifiable, with deliberately altered DNSKEY records. Some root servers continued to serve the unsigned zone while others tested the signed version. Jaap's archive switches to the signed version on the official go-live point at serial number 2010071501. David's journal gets the signed version starting on 2010041500. There's more fun between then and go-live than I remember, in particular a number of TLDs got DS records during this test period (.br and .uk at 2010062201, .cz at 2010062400, .tm at 2010062901, .cat at 2010063001, .bg at 2010070301, .na at 2010070901). The other notable difference between the archives is to do with TTLs of root-servers.net glue and delegation NS RRsets involving root-servers.net. I'm aware that the TTLs currently differ depending on whether you look at the root zone, or .arpa, or root-servers.net. I'm not sure what the history is, and I don't trust the data I have to be accurate - I believe there were bugs related to servers being unclear which zone's records should be included in an answer. Jaap's archive has some relatively infrequent changes of TTLs between 2004090101 and 2007031401 (8 changes that look suspicious to me). David's journal has frequent churn from 2007070401 until the zone is signed, flip-flopping every few days. I would like to suppress spurious changes in a way that is as historically accurate as I can. I've got a git repository layout for these archives which canonicalizes the zone files carefully in order to work with git as well as I can manage. This churn causes different sources to disagree when I think they should not. Any reminiscences / thoughts / suggestions welcome. Happy Newtonmass, Tony. -- f.anthony.n.finchhttp://dotat.at/ Plymouth, Biscay: Variable 4 or less at first in south Biscay, otherwise westerly 5 to 7, occasionally gale 8 in Plymouth, veering northerly 2 to 4, then southeasterly 5 to 7. Rough or very rough, becoming rough, occasionally moderate. Fair. Good. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] really old root zones for saveroot
Keith Mitchell wrote: > > OARC's Zone File repository has root zone data going back to 1993, > though coverage is spotty before 2000: > > https://www.dns-oarc.net/oarc/data/zfr/root Nice :-) I was aware of that but sadly I'm not an OARC member so I don't have access. Tony. -- f.anthony.n.finchhttp://dotat.at/ Lundy, Fastnet: Variable 3 or less, becoming south or southeast 6 to gale 8, perhaps severe gale 9 later in Fastnet. Moderate or rough, occasionally very rough later. Rain later. Good, occasionally poor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] really old root zones for saveroot
I have been playing around with the old update journal in the saveroot repository, to see if I can reconstruct root zones between July 2005 and March 2014. https://github.com/fanf2/saveroot/ David Malone reminded me that I got the journal from him when I mentioned saving the root zone in a git repository, so thanks are due to him for this part of the history. https://twitter.com/dwmal1/status/441339653044461568 I think reconstruction is mostly feasible, but it would be super helpful if anyone can give me a copy of the root zone from any point in that time period to fill in a couple of gaps. There are a few gotchas that I have found. Firstly, names in the journal change from upper-case to lower-case part-way through, which makes matching records mildly inconvenient. The change coincides with the zone being (experimentally) signed in April 2010. I think I will not preserve this in the reconstrucred version: the case change has the disadvantage of making diffs less useful, and it's easy enough to recover the historically accurate upper case because the switch-over time is so obvious. Secondly, very stable records don't appear in the journal. For example, the NS RRsets for the root itself and for .com have not changed for many years. There are 785 records that appear in my first full copy of the root zone, but not in the journal. I think this is fairly straightforward to cope with. Thirdly, there's a gap between the end of the journal and the first full copy of the zone. I thought the gap was a couple of days, but on closer inspection it turns out the last serial number in the journal is 2014030500 and the first complete zone is 2014030501. Normally this would be ideal, but it turns out there were some actually meaningful changes in that update. The list below has records that appear in the journal but not in the 2014030501 zone. This is mostly simple to deal with, except for the .mk delegation change, in particular kitka.marnet.net.mk. It looks like that was a long-lived name server, mentioned in NS and A records that predated the journal (so they don't appear). I can infer the NS record but not the A record. I cannot infer any NS records that were stable for the entire lifetime of the journal and deleted in the 2014030501 update, which might be a problem for .mk and .ro (and less plausibly for other TLDs). . 86400 IN RRSIG SOA 8 0 86400 2014031200 2014030423 33655 . [...] . 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2014030500 1800 900 604800 86400 co. 86400 IN DS 27859 8 1 63D2DAEB4D479BD4DFF4202D9BDC82B309C2CCD5 co. 86400 IN DS 27859 8 2 EF8F5B56FA9A79EF29A82330DB625BA19CE3A5B140B24287855DDAAA 03EA369B co. 86400 IN RRSIG DS 8 1 86400 2014031200 2014030423 33655 . [...] kitka.marnet.net.mk.172800 IN 2a02:e48:0:3::2 kn. 86400 IN NSECkp. NS RRSIG NSEC kn. 86400 IN RRSIG NSEC 8 1 86400 2014031200 2014030423 33655 . [...] la. 86400 IN DS 54086 7 1 C468E20FD427F2EB5E4658B1E1D24840768DC8E1 la. 86400 IN DS 54086 7 2 28339FCEDF2C52583595DD1460A6B07D9FA5692A5BA8E6E5F34EE306 35230541 la. 86400 IN RRSIG DS 8 1 86400 2014031200 2014030423 33655 . [...] lt. 86400 IN DS 24556 8 1 A9D06FA34F1C9D57062899824F5702041188DE97 lt. 86400 IN DS 24556 8 2 DEA1E077D98EA2DE8750281B40ACEBC14687AEB8FE49506333C903D5 01F6C620 lt. 86400 IN RRSIG DS 8 1 86400 2014031200 2014030423 33655 . [...] mk. 172800 IN NS ns2.arnes.si. mk. 172800 IN NS ns5.univie.ac.at. ns2.arnes.si. 172800 IN A 193.2.1.91 ns2.arnes.si. 172800 IN 2001:1470:8000::91 ro. 172800 IN NS ns-ext.isc.org. xn--90a3ac. 86400 IN NSECxn--cg4bki. NS RRSIG NSEC xn--90a3ac. 86400 IN RRSIG NSEC 8 1 86400 2014031200 2014030423 33655 . [...] Tony. -- f.anthony.n.finchhttp://dotat.at/ Tyne, Dogger: Westerly or southwesterly 6 to gale 8, decreasing 3 to 5 for a time in north. Moderate or rough. Rain or showers. Good, occasionally poor. ___ 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!
Matthew Pounsett wrote: > I have yet to witness anyone splitting the NS change up into multiple > IANA requests. Amazon did it with their TLDs earlier this year, which is notable because there were/are so many of them. There have been plenty of other examples of staged switch-overs. https://github.com/fanf2/saveroot/commit/9fca29c21fbd1ce61fe56308a86da4bc10f6c18e (2019-04-23 13:33) https://github.com/fanf2/saveroot/commit/a35e56c2801df2e3aa7cd4cbc0b3760d484ac5a3 (2019-04-09 18:33) Sadly github refuses to display root zone diffs, but if you want to clone a few GB it comes with an ns-only summarizer, amongst others. Tony. -- f.anthony.n.finchhttp://dotat.at/ Shannon, South Rockall: Westerly or southwesterly 6 to gale 8, perhaps severe gale 9 later. Very rough or high. Rain or showers. Good, occasionally poor. ___ 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!
Jim Reid wrote: > > In principle, they could all change at once, In reality, they don’t. But they do. Vanuatu did yesterday, and I mentioned some other recent examples in this thread a couple of weeks ago: https://lists.dns-oarc.net/pipermail/dns-operations/2019-November/019486.html Tony. -- f.anthony.n.finchhttp://dotat.at/ work to the benefit of all___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] saveroot on GitHub
I have done the fettling required to publish my root zone archive. Get it while it is stale, rotten, and stinkin' from: https://github.com/fanf2/saveroot/ It turns out that (1a) you can't push a 150MB root.jnl file to GitHub, but (1b) split and cat exist; (2a) you can host a 100GB repository on GitHub, but on the other hand (2b) you can't push a multi-GB repository to GitHub in one go, but on the gripping hand (2c) it is possible to push in 14 stages of 1000 commits each, with a bit of scripting... Tony. -- f.anthony.n.finchhttp://dotat.at/ Dogger, Fisher, German Bight: Southwest 6 to gale 8, occasionally severe gale 9 at first. Rough or very rough. Occasional rain. Moderate or good, occasionally poor. ___ 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!
Mark Allman wrote: > > Obviously, there could be a more comprehensive analysis I have a 3.5GB git repository containing 14500 commits with versions of the root zone going back to March 2014, if anyone wants something to analyse. I also have a BIND root.jnl file (140MB gzipped) which appears to start with SOA serial number 2005072701. I'm sure someone else has a less crappy archive... Tony. -- f.anthony.n.finchhttp://dotat.at/ Rockall, Malin: Southwest 6 to gale 8, perhaps severe gale 9 later. Very rough or high. Squally showers, then rain. Moderate or poor, occasionally good. ___ 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!
Tom Ivar Helbekkmo wrote: > > Can you actually implement a TCP stack without that possibility? I vaguely speculate that it would be better to rely on SYN retries and abolish SYN/ACK retries, but I have no idea what it might break. Tony. -- f.anthony.n.finchhttp://dotat.at/ safeguard the balance of nature and the environment ___ 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!
Florian Weimer wrote: > > But does anyone swap out the name servers for a TLD over the course of > five days? Complete replacement of delegation NS RRsets happens fairly frequently. I don't pay attention to the glue, tho, so I don't know how often these are just renames as opposed to server platform changes. One memorable example was .unicom back in June https://twitter.com/fanf/status/1138372065541677056 The .mm delegation change on 7 Oct was a complete change of names and addresses. On 2 Nov, .in and their many IDN TLDs had a rename rather than a change of addresses. Tony. -- f.anthony.n.finchhttp://dotat.at/ Whitby to Gibraltar Point: North 3 or 4, becoming variable 3 or less, then east 3 or 4 later. Slight or moderate. Showers. Good. ___ 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!
Viktor Dukhovni wrote: > > refection of answers to forged source IPs is not available with TCP Attackers can get a small amplification from SYN/ACK retries, and this is being used in the wild. https://www.darkreading.com/attacks-breaches/new-ddos-attacks-leverage-tcp-amplification-/d/d-id/1336339 Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Variable 3 or less in southeast, southwesterly 3 to 5 in northwest. Moderate, occasionally rough in north and slight in southeast. Showers. Good, occasionally moderate. ___ 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!
I generally agree with Geoff Huston's thoughts on this subject http://www.potaroo.net/ispcol/2019-04/root.html Mirror zones (validated zone transfers) fall on the wrong side of the cost/benefit equation for me. But I might change my mind if there were better security for unauthenticated records (NS and glue), e.g. * xfer-over-TLS - I'm really looking forward to support for authenticated server / anonymous client for zone transfers: nice for local root zones and cross-campus zone distribution. * zone digests - interesting for end-to-end verification but maybe too complicated? Mukund Sivaraman wrote: > > There are some Twitter feeds about what kinds of > changes occur to the root zone and how frequently, e.g.: > > https://twitter.com/diffroot Note that @diffroot does not tweet about changes to glue addresses which happen a lot more frequently than NS and DS changes. Tony. -- f.anthony.n.finchhttp://dotat.at/ Biscay: Southwest, veering west, 6 to gale 8, occasionally severe gale 9 until later. Rough or very rough becoming very rough or high, becoming very rough later. Thundery showers. Good, occasionally poor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] sophosxl.net problem?
Florian Weimer wrote: > > Aren't there cases where BIND 9 caches data in a > supposedly-authoritative-only view because the data is needed to send > NOTIFY queries to the right addresses? Yes, but this doesn't cause problems because you will have set `recursion no`, which sets `allow-query-cache` to `none`. Tony. -- f.anthony.n.finchhttp://dotat.at/ Isle of Man: Southeast 4 or 5 imminently backing east 5 or 6 backing north or northeast later. Slight soon becoming slight or moderate. Isolated showers, mainly fair later. Good moderate in showers. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] sophosxl.net problem?
Viktor Dukhovni wrote: > > We can't have both of: > >* It is valid to return non-authoritative cached data for RD=0 >* It is invalid to return AA=0 in response to RD=0 requests. Well, your server can have both if it allows different clients to get one or the other :-) You can control this with things like an allow-query-cache ACL. Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: North backing northwest, 4 to 6, increasing 7 at times. Moderate or rough, becoming very rough in north. Fair. Good. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] sophosxl.net problem?
James Stevens wrote:
>
> Would it be reasonable for an authoritative-only DNS Server to reject / ignore
> / throttle requests with RD=1 ?
I think for quite a long time my toy DNS server (which runs with an
appalling hodge-podge of patches) was running with a config something
like...
view rec {
match-recursive-only yes;
# stuff
};
view auth {
recursion no;
allow-recursion { none; };
zone dotat.at { /* ... */ );
# etc.
};
The effect was that recursive queries went to the rec view then got
rejected by an ACL; RD=0 queries went to the auth view which served my
zone to all comers. The only problem I noticed was RD=1 health checks from
one of my secondaries. My config now has a match-clients clause in the rec
view which works better all round.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
promote human rights and open government
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] sophosxl.net problem?
Viktor Dukhovni wrote: > > Reading that issue it seems that the servers in question return > cached non-authoritative data even when the request has RD=0, > provided some recent RD=1 query brings the data into the cache. This is normal for recursive servers. Whether this traditional behaviour is sensible or not is another question. If a recursuve server has mutually distrusting clients then it's a privacy leak known as DNS cache snooping. > In which case the issue is not *failing* to set AA=1, but rather > a server that is authoritative for some domains and recursive for > others allowing non-authoritative cached data to leak into RD=0 > replies. > > How common are such servers? Is their behaviour incorrect? Dunno about how common they are. There are two misconfigurations: servers identified in public NS records should be authoritative for the zone (but these ones are not) and they should not offer recursion (but these ones do). Tony. -- f.anthony.n.finchhttp://dotat.at/ Humber, Thames: South veering west or southwest, 6 to gale 8. Moderate or rough. Showers. Good. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] CNAMEs pointing off into the weeds - inconsistent behavior from different recursive codebases
Rob Seastrom wrote: > > I might add that I was slightly surprised that this works - it seems > unaddressed in the ACME spec but kind of feels like a potential attack > surface tparticularly since it works even to a non-child, > non-same-origin (pedantically, not quite "out of baliwick" but YKWIM) > zone. Viktor has answered your question, but wrt this point, Let's Encrypt is in general very happy to follow indirections, whether CNAMEs for dns-01 or redirects for http-01. RFC 8555 mentions HTTP redirects but not CNAMEs. Both kinds of aliasing allow for lots of fun games. Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Northerly or northeasterly 4 to 6, increasing 7 at times in east. Rough or very rough. Fair. Good. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Random question about Google resolver behaviour and long-lived TCP sessions
Jake Zack wrote: > So I guess the question for the OARC list would be...do you see this > same kind of behaviour from Google? And the question for Google > is...what am I missing? What's the need for this? I haven't looked at this on my auth servers but I have done some tuning on my recursive servers related to DNS-over-TLS support for Android clients. So I wonder if Google have implemented EDNS TCP keepalive. If you change what BIND calls tcp-advertised-timeout, do Google's TCP connection lifetimes change to match? Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Northerly 4 or 5, occasionally 6 in east. Rough, occasionally moderate at first. Fair. Good. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Link-local IP addresses for a resolver?
John Levine wrote: > > How are they with RFC 4193 ULAs? I've been using a cache at a ULA on > my two-segment home network and it seems to work fine. I would expect them to "just work" modulo the network connectivity issues associated with ULAs mentioned by Mark. The problem with link-local addresses is "which link?" so to answer that the resolver address has to be scoped. When I looked, the common problem was to store the resolver address as 16 bare bytes which lacks space for the interface scope, rather than sockaddr_in6 which includes the scope and other complications. That's if the code parsed and ignored the scope; it was also common to simply fail to parse the scoped address. I also have vague worries about lurking bugs with RDNSS and DHCPv6 resolver configuration: the addresses on the wire are bare and only implicitly scoped to the interface they arrived on, which offers so many opportunities to make mistakes. Tony. -- f.anthony.n.finchhttp://dotat.at/ Thames, Dover, Wight, Portland, Plymouth: Southwesterly 5 to 7, occasionally gale 8 at first in Thames, Dover and Wight. Slight or moderate in Thames, but elsewhere mainly moderate or rough, although very rough at first in southwest Plymouth. Rain or showers. Good, occasionally poor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Link-local IP addresses for a resolver?
Florian Weimer wrote: > > We added scope ID support to /etc/resolv.conf in upstream glibc a > couple of years ago, in 2008. I can easily see that others may not > have done this, so I agree that there could be problems. I did a bit of a survey in 2014 and found that prominent DNS libraries didn't support link-local addresses back then http://lists.cluenet.de/pipermail/ipv6-ops/2014-July/010035.html Maybe it's better now :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ North Shannon, South Rockall: Cyclonic becoming westerly or southwesterly, 3 to 5, occasionally 6 in north Shannon. Very rough becoming rough, then becoming moderate later in south Rockall. Rain or showers. Good, occasionally poor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] sibling glue
Stephane Bortzmeyer bortzme...@nic.fr wrote: But having host objects is not mandatory and some registries (like .FR) do not use them at all, even when they use EPP. Very sensible :-) Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: In southeast, northerly 4 or 5, occasionally 6 later, but becoming cyclonic 5 to 7 later in far southeast. In northwest, variable 4. In southeast, slight or moderate. in northwest, moderate. In southeast, fair. In northwest, mainly fair. In southeast, good. In northwest, mainly good. ___ 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] sibling glue
Joe Abley jab...@hopcount.ca wrote: Thanks for your very helpful reply... The requirements I am stating below are from the DNS point of view rather than from the registry point of view. I think that's not going to help you get a clear answer, but let's give it a try. People who actually know how registries work can correct all the horrible mistakes I'm about to type. It has been a while. The EPP spec might be worth reading. EPP leaves a lot of the practical consistency constraints unspecified, as far as I can tell :-/ Whether or not a glue record is actually included in the zone depends on the algorithm by which the zone is produced from the registry. The most simple algorithm is to include a delegation for every domain object and glue records for every host object, but other algorithms that distinguish between glue that is definitively required and glue that might not be required are surely possible. Presumably (amongst other things) there has to be logic that avoids promoting glue to authoritative data. e.g. client A creates a host object www.undelegated.example and the registry doesn't know at that point whether or not A is about to create the expected domain object. e.g. the domain deadbeat.example has a number of subordinate host objects used by other domains; what happens to those host objects when deadbeat.example is cancelled? I don't think that condition is part of the EPP data model; the criteria that matters here is that the host object's name is subordinate to the name of the zone produced from the registry, which means that one or more address records for the host are required. That makes sense. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: In southeast, northerly 4 or 5, occasionally 6 later, but becoming cyclonic 5 to 7 later in far southeast. In northwest, variable 4. In southeast, slight or moderate. in northwest, moderate. In southeast, fair. In northwest, mainly fair. In southeast, good. In northwest, mainly good. ___ 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] sibling glue
A question for those who know more about registry rules than me... In the .example zone there can be five kinds of delegation NS record (taking each record separately rather than the whole delegation NS RRset). The requirements I am stating below are from the DNS point of view rather than from the registry point of view. glue-forbidden.example. IN NS ns0.example.net. ; ; You must not provide glue when the name server host name is not a ; subdomain of the parent domain (.example in this case). not-glue.example. IN NS ns1.example. ; ; A child zone's name server host name can be in the authoritative data ; for the parent zone. This isn't glue. glue-required.example. IN NS ns2.glue-required.example. ; ; You must provide glue when a child zone has a name server whose host ; name is a subdomain of the child zone's apex. ; There are two cases where a child zone has a name server whose host name ; is a subdomain of a different sibling child zone of the same parent zone. sibling-must-glue.example. IN NS ns2.glue-required.example. ; ; The name server of this child zone can also be a name server of its ; sibling zone, in which case the sibling delegation must provide glue. sibling-may-glue.example. IN NS ns3.sibling.example. ; ; The name server of this child zone can be a subdomain of its sibling ; zone but not a name server for the sibling zone. Glue is optional in ; this case. So, to a large extent, you can update a delegation knowing only data that is in the child zone. (You might also need to know about descendent zones, for cases like cam.ac.uk. IN NS dns0.cl.cam.ac.uk.) But it gets tricky if the registry requires sibling glue, since that means an update might need to know (or find out) quite a lot of contextual information. How common is it for registries to require glue for cases like sibling-may-glue.example? I suppose it makes sense from the registry point of view to require glue for all names which are subdomains of the parent zone; that means a host object can be attached to any domain object without having to worry if the delegation might lack glue that it needs. Also I get the vague impression that sibling delegations can cause interesting problems wrt ownership of host objects. For instance, is it normal for client A to be able to create host objects under a domain owned by client B? (These are edge cases which I can easily ignore, but they are annoyingly awkward...) Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Dogger: Northwest 5 or 6, becoming variable 3 or 4 later. Moderate, occasionally slight later. Fair. Good. ___ 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] Trying - Re: Fwd: Re: [Security] Glue or not glue?
Edward Lewis edward.le...@icann.org wrote: The context is some kind of name server operator protocol where ops can have some degree of control over entities that get delegated to them. That would be a good thing to have, I agree. And control during the existence of the delegation, and ability to revoke it. https://blog.cloudflare.com/updating-the-dns-registration-model-to-keep-pace-with-todays-internet/ Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Dover, Wight, Portland, Northeast Plymouth: Easterly or northeasterly, becoming cyclonic, 5 to 7, decreasing 4 at times. Slight or moderate. Thundery rain, fog patches. Moderate, occasionally very poor. ___ 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] com. Glue
Joe Abley jab...@hopcount.ca wrote: So aside from any DNS protocol discussion of whether it's legitimate for a COM nameserver to respond with additional-section glue for a nameserver named under ORG, the COM registry simply doesn't have the information it needs to publish one even if it was a good idea for it to do so. On the DNS side of things, BIND's additional-from-auth and additional-from-cache options are relevant. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Fisher: Cyclonic 4 or 5. Slight, occasionally moderate at first. Thundery showers then fair. Good, occasionally moderate. ___ 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] calculating DNSSEC keytags in awk
Frank li...@dreamofjapan.de wrote:
have you found a solution to your problem calculating DNSSEC keytags in
awk from Sat Dec 17 12:39:04 UTC 2011?
dig +multiline will show you the key tag, or you can use dnssec-dsfromkey
and pull the tag out of the result, e.g.
$ dig dnskey $zone | dnssec-dsfromkey -f - $zone | awk 'NR == 1 { print $4 }'
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
Humber, Thames: Variable 3 or 4, becoming northeast 4 or 5 in Thames. Smooth
or slight, occasionally moderate later in Thames. Occasional rain at first.
Good, occasionally poor.
___
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] Postures was Re: Stunning security discovery: AXFR may leak information
Edward Lewis edward.le...@icann.org wrote: (By the same token, why would one use NSEC3 for signed zones when the zone is available over FTP?) Opt-out. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: Cyclonic 5 or 6. Moderate or rough. Thundery showers. Moderate or good. ___ 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] dnsop-any-notimp violates the DNS standards
Edward Lewis edward.le...@icann.org wrote: But, I do agree with the handwaving argument to date is insufficient and a bit weak. It is right to challenge the proposal as it stands (as I have done too). While I an inclined to agree to deprecate qtype=ANY as well as other elements of the protocol I am also inclined to demand a better rationale before accepting a document's proposal. I think outright deprecation might be going too far, especially if it is possible to provide a non-answer to ANY queries that still provides good interoperability. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Fair Isle, Faeroes: South veering west or southwest 5 or 6, decreasing 4 at times. Rough becoming moderate. Showers. Moderate or good, occasionally poor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] What would it take...
Edward Lewis edward.le...@icann.org wrote: Note that my request was not for a means to update the parent but to prevent the child from shooting themselves in the foot. A much less involved operation. In this immediate case the problem was caused by a change of operator for the zone, and the registrar(s) failed to handle DNSSEC properly as part of the transfer. I think this is a simpler situation to deal with than a botched key rollover, assuming registrars can be persuaded to add the necessary sanity checks to their processes. This doesn't have to be anything ambitious like fully secure domain transfers: either stop the transfer or ask the registrant to make the domain insecure if the nameservers are changed and the new ones do not have a properly signed zone. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Rockall, Malin, Hebrides, Bailey: West backing southeast then veering southwest, 6 to gale 8 increasing gale 8 to storm 10, occasionally violent storm 11 later in Rockall and Bailey. Very rough or high, becoming high or very high except in Malin. Rain or showers. Moderate or poor. ___ 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] introducing: dnsdist
bert hubert bert.hub...@netherlabs.nl wrote: http://blog.powerdns.com/2015/03/11/introducing-dnsdist-dns-abuse-and-dos-aware-query-distribution-for-optimal-performance/ Thanks for linking to my notes about keepalived. I should perhaps have made it clearer that I am only using keepalived for failover, not for load balancing - I'm using the VRRP part (for automatically moving recursive server IP addresses) not the LVS redirector part (which handles load balancing across multiple back end servers). My setup is too small to need load balancing, handling up to about 4000 queries per second. (I haven't checked how many clients these servers have; the total user population is about 40 000 but there are lots of little name servers around the place.) Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ South Utsire, Forties, Cromarty, Forth, Tyne, Dogger: Southerly or southwesterly 6 to gale 8 becoming variable 4, then southeasterly 6 to gale 8 later. Moderate or rough, occasionally very rough in Forties and northeast Cromarty. Occasional rain. Good, occasionally poor. ___ 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] [DNSOP] dnsop-any-notimp violates the DNS standards
Darcy Kevin (FCA) kevin.da...@fcagroup.com wrote: Regarding the statement query type ANY 'matches all RR types CURRENTLY IN THE CACHE'. Actually, there's nothing in RFC 1034 that clearly *mandates* this behavior It is sort-of specified in the algorithm in section 4.3.2 which says, 4. Start matching down in the cache. If QNAME is found in the cache, copy all RRs attached to it that match QTYPE into the answer section. That applies to RD=0 queries. For RD=1, section 5.3.3 says, 1. See if the answer is in local information, and if so return it to the client. This is usually understood to mean what you would get from an RD=0 query. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Northwest Fitzroy, Sole: Southwesterly, backing southeasterly for a time, 4 or 5 increasing 6 to gale 8. Moderate or rough, becoming very rough later in west. Occasional rain, fog patches. Moderate or good, occasionally very poor. ___ 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] dnsop-any-notimp violates the DNS standards
D. J. Bernstein d...@cr.yp.to wrote: My qmail software is very widely deployed (on roughly 1 million SMTP server IP addresses) and, by default, relies upon ANY queries in a way that is guaranteed to work by the mandatory DNS standards. There are three bugs in the way qmail uses ANY queries. (1) qmail uses ANY queries for domain canonicalization on outgoing messages, as specified by RFC 1123. But canonicalization is not required by the current SMTP specification. It is a waste of time. Fixing this bug would make bug (3) moot. (2) qmail's DNS response buffer is too small to accommodate a complete DNS message, so it fails if it gets a large response. It uses the low-level libc resolver API which can easily handle large responses, including fallback to TCP, so it is a pity that qmail breaks this part of the resolver's functionality. This bug means it is not guaranteed to work. (3) Using an ANY query suppresses alias processing, so qmail makes a series of queries to follow CNAME chains. This is inefficient and wasteful. If you make an A or MX query, the DNS server will chase the CNAME chain for you, so you only need to make one query to get the canonical name. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: Easterly 5 or 6 in far southeast, otherwise northerly 4 or 5. Moderate or rough. Mainly fair. Good. ___ 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] [DNSOP] dnsop-any-notimp violates the DNS standards
bert hubert bert.hub...@netherlabs.nl wrote: On Mon, Mar 09, 2015 at 11:08:03AM -, D. J. Bernstein wrote: My qmail software is very widely deployed (on roughly 1 million SMTP server IP addresses) and, by default, relies upon ANY queries in a way that is guaranteed to work by the mandatory DNS standards. The way I read RFC 1034 4.3.2, this is not true. In step 4 we match whatever we find in the cache, put it in the packet, and move on to step 6. This means the algorithm might terminate returning only an A record or only an record. Or a TXT record for that matter. This reading of 4.3.2 makes 'ANY' queries to resolvers fragile. It might not return what you need. Dan is aware of that, but this particular oddity isn't a problem for qmail. Later in his message he wrote: Of course, there's no guarantee of which RR types for a node are available at a cache, but a client is guaranteed to be able to detect CNAME records from responses to query type ANY (as qmail does), since a CNAME type prohibits all regular RR types. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Fair Isle: Southeast veering west, severe gale 9 to violent storm 11. Very rough or high, becoming very high for a time. Rain then showers. Moderate or poor, becoming good. ___ 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] dnsop-any-notimp violates the DNS standards
Jared Mauch ja...@puck.nether.net wrote: Even ignoring if qmail is “broken”. (I would rather classify it as, could do better) Yes. dnsop-any-notimp violates the principle of least surprise in technology by returning NOTIMP where Paul Vixie suggested NOERROR/ANCOUNT=0 would be more appropriate with the existing definitions. This would have the amusing effect of disabling qmail's address canonicalization without patching qmail. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Rockall, Malin: Cyclonic in north Rockall at first, otherwise westerly or southwesterly severe gale 9 to violent storm 11, decreasing 5 or 6. High or very high, becoming very rough. Squally showers. Good, occasionally poor.___ 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] Mozilla Firefox and ANY queries
Paul Wouters p...@nohats.ca wrote: On Thu, 5 Mar 2015, Tony Finch wrote: * ANY always returns a TTL of 5 seconds. That 5 second TTL is an artefact of RPZ processing. By default BIND returns the upstream TTL in responses to ANY queries. Really? Wouldn't that _contribute_ to DDOS attacks when the attacker uses open recursives to attack the authoritative servers? I meant upstream with cache countdown like normal queries, rather than doing anything funny like squashing to 5s. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ South Utsire, Forties, Cromarty, Forth, Tyne, Dogger, Fisher: Southwesterly 5 to 7, occasionally gale 8 in Cromarty. Moderate, occasionally rough. Mainly fair. Good. ___ 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] Mozilla Firefox and ANY queries
Fred Morris m3...@m3047.net wrote: I didn't understand this either. So I did some cursory playing with BIND 9.9.2. * ANY always returns a TTL of 5 seconds. That 5 second TTL is an artefact of RPZ processing. By default BIND returns the upstream TTL in responses to ANY queries. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ South Fitzroy: Easterly 5 to 7, occasionally gale 8 at first, decreasing 4 or 5 in west. Moderate or rough, occasionally very rough at first. Fair. Good. ___ 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] Root-servers returning TC=1 after 5 NXDOMAINS
Paul Hoffman paul.hoff...@vpnc.org wrote: It sounds like a bad configuration for RRL at f-root, given the replies below that they are unique queries (which would make sense from a caching resolver). I don't think it is that bad. If you fail to ratelimit because all the queries are different then attackers have a trivial bypass. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Southeast Bailey: Southerly veering northerly 6 to gale 8, then easterly 4 or 5, increasing 6 or 7 later. Very rough becoming rough. Rain. Moderate or poor. ___ 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] extra records in resolver answer, any benefit?
bert hubert bert.hub...@netherlabs.nl wrote: It is all optional, and nobody does anything with that data. In fact stub resolvers do very little with what they receive. So for example, even the additional processing for an MX record is completely ignored mostly. Yes. The difficulty with MX (and SRV) additional data is that you don't get a clear indication whether the target address records are nonexistent or just unavailable, so it tends to be easier to look them up regardless of the contents of the additional section. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Shannon: Southwest 5, increasing 6 or 7, then veering west 7 or gale 8, occasionally severe gale 9 later. Rough, becoming very rough or high. Occasional rain, showers later. Moderate or good, occasionally poor. ___ 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 Resources for Deep Dive Understanding of DNS
Rubens Kuhl rube...@nic.br wrote: are DNS views recommended for resolving “internal” DNS results or is it just at risk of a fat finger errors to provide internal addresses to management teams) DNS views are a good thing, just be sure that they are the child of actual existing SLDs. Using something.internal.company.com http://internal.company.com/ (where company.com http://company.com/ is registered to you) is a good thing; using something.internal is a bad thing. Private zones are different from views. Private zones have the advantage that the same name resolves to the same RRsets wherever you make the query (or it does not resolve if you are outside the private network); views give you different answers for the same name depending on where you make the query. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Rockall, Malin, Hebrides, Bailey: West or southwest 5 to 7 increasing 7 to severe gale 9. Very rough or high. Rain or squally showers. Moderate or good, occasionally poor.___ 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] DNSSEC on host listed in MNAME
Alexander Mayrhofer alexander.mayrho...@nic.at wrote: i've been trying to find guidance whether or not the host listed in the MNAME field of the SOA record is required to have the respective zone signed (when it is signed on the authoritative servers, and a secure delegation exists at the parent)? I believe it is not required. I understand the MNAME host is not queried under normal operational circumstances, but is there any formal text? The MNAME host is often used for UPDATE requests. I agree with you that it is reasonable to have a setup where there is a bump-in-the-wire signer between the MNAME server and the public authoritative servers. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ South German Bight, Humber, Thames, Dover, Wight: Southwesterly 6 to gale 8. Rough or very rough. Occasional rain. Moderate or good. ___ 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] Test on Priming Behavior
Davey Song songlinj...@gmail.com wrote: But I do not find any specification on the priming process of resolver, There is a draft http://tools.ietf.org/html/draft-ietf-dnsop-resolver-priming Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Portland, Plymouth: Southwest 5 to 7. Rough or very rough. Occasional drizzle, rain later. Moderate or good, occasionally poor later. ___ 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] reopening discussion of stalled i-d: draft-ietf-dnsop-edns-chain-query
Paul Vixie p...@redbarn.org wrote: yes. however, i think we're all assuming that since CHAIN is an EDNS option, that EDNS BUFSIZE will be at least 1500. Why is back-to-back fragmented UDP OK when back-to-back unfragmented UDP isn't? Why is TCP such a problem for name servers when web servers seem to cope OK? Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty, Forth: Southerly in east Forties at first, otherwise northwesterly, 5 to 7, backing westerly 4 or 5. Moderate or rough, becoming slight or moderate. Rain or showers, becoming fair. Good, occasionally poor in Forties at first. ___ 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] reopening discussion of stalled i-d: draft-ietf-dnsop-edns-chain-query
Paul Vixie p...@redbarn.org wrote: Tony Finch mailto:d...@dotat.at Sunday, November 30, 2014 6:26 AM You can do that with the current DNS protocol: just send all the queries and wait for all the replies. (This is particularly easy over TCP.) There's no need for more than one round trip in most cases, or maybe two if the answer involves CNAME/MX/SRV etc. so, you're willing to send a query for every ancestor domain, even the ones that turn out not to be zone cuts. That will usually be only one, and the server will have to send back a proof of no zone cut whether you ask for it separately or as part of a bulk query. you're also willing to transmit microburst UDP, or to depend on RDNS servers having effectively unlimited TCB capacity. i am not hip to any of that. Those are fair complaints. However your initial reason was latency, but chain queries do not improve latency compared to the current protocol. And chain queries will often require TCP so your TCB complaint applies to them as well. (And if you start with UDP and have to do a TCP fallback you lose the latency benefits.) Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Lundy, Fastnet, Irish Sea: Variable 4, becoming north 5 to 7, perhaps gale 8 later. Slight or moderate, occasionally rough later. Fair then rain. Good, occasionally poor. ___ 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?
Jared Mauch ja...@puck.nether.net wrote: (aside: really wish bind would launch faster when loading these zones, or background the loading of the zones and answer those it can). Check out the map zone file format in 9.10. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Fitzroy, Sole: Southerly 6 to gale 8, occasionally severe gale 9 in west, but 4 or 5 in east at first, veering northwesterly 4 or 5 in west later. Rough or very rough, occasionally high in far west. Rain or showers. Moderate or good. ___ 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] Logging dns record changes
Ayca Taskin (Garanti Teknoloji) ayc...@garanti.com.tr wrote: We need to log DNS record changes, is there any logging option to do this on 9.9.1-P3? More detailed logging of updates was added in BIND 9.10. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ German Bight: Southeast 5 to 7. Moderate or rough. Occasional drizzle. Moderate or good. ___ 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] SERVFAIL/FORMERR for TXT mta.email.(office|microsoftonline).com
Derek Diget derek.diget+dns-operati...@wmich.edu wrote: I initially asked this question on the mailop list http://chilli.nosignal.org/mailman/listinfo/mailop and a reply mentioned this list. So I explained the cause of the problem on the mailop list (link only available to subscribers, i am afraid) http://chilli.nosignal.org/mailman/private/mailop/2014-November/005543.html and reported it on the windns-users list (including a copy of the above message) http://lists.cloudapp.net/pipermail/windns-users/2014-November/thread.html Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Bailey: North becoming cyclonic, then southeast later, 5 to 7, occasionally gale 8 at first in north. Rough or very rough. Showers. Good, occasionally poor. ___ 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
Joe Greco jgr...@ns.sol.net wrote: Assuming that the CPE is a NAT (effectively firewalling clients from poisoning attacks) and/or that the individual clients have well- designed, impervious resolvers is likely to be a fail. I was under the impression that a common failure of NATs is that they sometimes defeat source port randomization, so they can make it easier for an attacker to poison a cache that is behind a NAT than an exposed cache. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. ___ 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] ShellShock exploit through the DNS
P Vixie p...@redbarn.org wrote: Who does this? Where, in the actual world, is code deployed that does what this supposed PoC does? A CGI script invoked by Apache httpd with HostnameLookups On (the default is Off, a safer setting is Double) Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. ___ 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] How to tell bind to ignore DNSSEC for a domain/zone
Franck Martin fmar...@linkedin.com wrote: How do you do the same with bind? This feature will be in version 9.11. You can get is on the git master branch at https://source.isc.org/ Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. ___ 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] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
Rubens Kuhl rube...@nic.br wrote: It was curious to see that a to-be-unnamed TLD registry, a newcomer to the scene many years after the holy wars that ended up defining the current RFCs, writing completely new code, mentioned that they found attributes to be a better option, but decided to go with host objects due to registrar support. This doesn't prove which way is better, but for me it indicates that the role in the value chain can play a part in which option is preferred. Nominet is another example along those lines: alongside the .uk namespace change they have switched to a more standard EPP implementation. http://registrars.nominet.org.uk/namespace/uk/registration-and-domain-management/registrar-systems/epp http://registrars.nominet.org.uk/content/what-are-differences-between-nominet-epp-and-standard-epp Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. ___ 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 there a diagnostic tool to obtain delegated ns?
Paul Vixie p...@redbarn.org wrote: res_findzonecut(), inside libbind (now called netresolv), provides an API that does what you don't want (gets the zone's apex NS RRset), but is implemented with logic you could hack to grab the information you do want (the closest ancestor's delegation NS RRset), as it goes by. I don't think that will work: res_findzonecut talks to a recursive server, but to get the delegation NS RRset you need to talk to the authoritative servers for the parent zone. Also res_findzonecut works from the bottom up and stops just below the zone cut. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. ___ 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] Hearing first complains about failing internal resolving due to .prod TLD
Paul Ferguson fergdawgs...@mykolab.com wrote: https://mm.icann.org/mailman/listinfo/gtldnotification There's a big lag between notifications on that list and actual delegation, e.g. the cymru agreement was signed in May and delegation happened this month. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6. Slight or moderate. Showers in northwest. Good. ___ 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
