Re: [dns-operations] dns-operations Digest, Vol 92, Issue 13

Vernon Schryver wrote: > > - a quick sample of DNSEC A answers finds them all larger than 1220 bytes ... but they can be much smaller if you turn on minimal responses. e.g. for cam.ac.uk, 1283 vs 209 bytes; for dotat.at, 910 vs 221 bytes. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties

Re: [dns-operations] dns-operations Digest, Vol 92, Issue 13

Paul Vixie wrote: > > for unsigned responses, i think a v6 max-udp-size of 1220 and a v4 > max-udp-size of 512 is what's called for. Why not be optimistic and assume ethernet MTUs? Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6

Re: [dns-operations] Can MX be working with CNAME?

Jeroen Massar wrote: > "Don't use CNAMEs in combination with RRs which point to other names" > > And thus CNAME -> MX -> A falls under that too. No, it is only names in RDATA that should not refer to CNAMEs. In practice, this depends a lot in the RR in question. NS pointing to CNAME is not goi

Re: [dns-operations] Can MX be working with CNAME?

Jo Rhett wrote: > Tony, you seem to be confused about how dns and mail work. Fallback to > host deliver when an MX doesn't exist was poor behavior in the original > RFC, and has been fully deprecated behavior for more than 20 years now. You might like to review section 5 of RFC 2821 and RFC 5321

Re: [dns-operations] summary of recent vulnerabilities in DNS security.

Colm MacCárthaigh wrote: > > This thread concerns the vulnerabilities uncovered in the fragment > attacks. One of those vulnerabilities is that domains can be rendered > unresolvable; even when DNSSEC is enabled. That seems like something > to take seriously. I am incresingly doubtful that EDNS b

Re: [dns-operations] summary of recent vulnerabilities in DNS security.

Vernon Schryver wrote: > > Have you turned on DNSSEC where you can? If not, why not? Can we have less of the ad hominem please. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Shower

Re: [dns-operations] chrome's 10 character QNAMEs to detect NXDOMAIN rewriting

Paul Vixie wrote: > Robert Edmonds wrote: > > i'm curious as to exactly what this root zone slaved resolver > > configuration looks like and how it would behave. [...] > > > if i understand things right, this config could only be achieved with > > particular resolver implementations that combine a

[dns-operations] Fun with DNAME and DNSSEC

We have an interesting reverse DNS setup. The University of Cambridge Computer Laboratory has its own /16 of which they have allocated the upper half for university-wide use; rather than delegating 128 sub-zones we use DNAME to greatly reduce the amount of key management bureaucracy. There is some

Re: [dns-operations] Fun with DNAME and DNSSEC

Wessels, Duane wrote: > > You should find that the Debugger now properly recognizes the DNAME record. > It previously only used the DNAME record when the owner name was equal to > the zone name. All green now, excellent :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East,

Re: [dns-operations] Fun with DNAME and DNSSEC

Casey Deccio wrote: > > DNSViz should now work too--no longer "discombobulated" :), but still slow > (needs a performance facelift). It was actually handling DNAME properly; > it just wasn't querying for PTR outside of arpa, so it wasn't following the > synthesized CNAME. Looks good, thanks! We

Re: [dns-operations] Fun with DNAME and DNSSEC

Casey Deccio wrote: > The analysis link I posted was a snapshot from hours ago. The newest > DNSViz analysis doesn't show any issues, and I confirmed that from command > line. I must have thought the 05:58 UTC was actually a new analysis when I sent my previous message at 15:15 - but the next a

Re: [dns-operations] rate-limiting state

Colm MacCárthaigh wrote: > > I don't see anyone disputing my example, and I'm not calling out RRLs > ability to dampen a reflection attack. I'm saying that RRL can be used to > counter-attack your users. Let's say a busy website gets 1,000 QPS of > "real" user queries. If I want those queries to

Re: [dns-operations] rate-limiting state

Patrick W. Gilmore wrote: > On Feb 07, 2014, at 07:09 , Tony Finch wrote: > > > > If my busy name server is getting 1000 qps of real traffic from all over > > the net, and 1000 qps of attack traffic "from" some victim, then RRL will > > attenuate responses

Re: [dns-operations] rate-limiting state

David C Lawrence wrote: > > Maybe Patrick glossed over the mere "1000 qps", which for many (most? > hand-waving) operators doesn't even blip as an attack. At the > attack-level traffic to which he is accustomed, the inbound requests > can easily surpass the server's ability to generate responses

Re: [dns-operations] Atlas Probe - Result question hostname.bind = "clboh-dns-cac-307"

$ host clboh-dns-cac-307.ohiordc.rr.com clboh-dns-cac-307.ohiordc.rr.com has address 65.24.26.42 clboh-dns-cac-307.ohiordc.rr.com has IPv6 address 2605:a000:200:16::a Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough,

Re: [dns-operations] Does DNSSEC provide any mitigation for SSL bugs, like Apple's?

Sadly not. Let's say you have an on-path attacker. Your DNS lookup returns the right IP address, validated by DNSSEC, but the attacker is intercepting traffic to that address. OK, but you have DANE to help validate the site's certificate. The attacker presents the right certificate (after all it

Re: [dns-operations] should recursors think there are only delegation data in tld name servers?

刘明星 wrote: > I want to know whether there other types of data except delegation data. Sometimes, yes. $ dig +norec +noall +answer _nicname._tcp.uk srv @nsa.nic.uk _nicname._tcp.uk. 172800 IN SRV 0 0 43 whois.nic.uk. $ dig +norec +noall +answer d.ns.at a @d.ns.at d.ns.at.

Re: [dns-operations] AAAA record for c.root-servers.net

Chris Thompson wrote: > An record for c.root-servers.net (2001:500:2::c) has appeared in the > zone and in the additional section of priming responses from the root servers Ah, I didn't consider root name server changes when I was writing the code behind https://twitter.com/diffroot - a gap

Re: [dns-operations] about the underline in hostname

wbr...@e1b.org wrote: > > Interesting reading. I bet Site 1 was quite popular: > > --- quoting RFC 229 --- > Site Standard Name Alternate Name > - -- > 1 UCLA-NMC SEX >

Re: [dns-operations] alidns

hua peng wrote: > anybody give a test and review on alidns.com? Servers are 223.5.5.5 and 223.6.6.6 It is not validating. Its support for DNSSEC is incomplete: sometimes when I dig +dnssec dotat.at I get an unsigned answer. Maybe because my first query was without +dnssec? Anyone have a domain

Re: [dns-operations] What's wrong with my domain?

Mohamed Lrhazi wrote: > I am sure I messed up something, but cant figure out what! Your DS record doesn't match your DNSKEY records. gu.edu. 86325 IN DS 3078 7 1 B4C9FB14D6519C3ECE5CC43E80C463D5847D73ED dig dnskey gu.edu @141.161.200.28 | dnssec-dsfromkey -f /dev/stdin gu.edu gu.edu. IN DS 350

Re: [dns-operations] What's wrong with my domain?

Mohamed Lrhazi wrote: > > gu.edu is, luckily, a test domain, and not production. I had enabled DNSSec > in our F5 GTM front ending DNS, and forgot about it. Seems I have to learn > that after a while keys are rolled over and I need to do some work about > it Surely it has an interlock to prev

Re: [dns-operations] www.factorymoneystore.gov DNSSec Failures

Mark Andrews wrote: > > [...] > * responds with > 512 bytes to a EDNS@512 byte TCP query > (this requires finding a response that will be > 512 bytes) > * add the OPT record to a truncated response > (this requires finding a response that can be forced to truncate) > > The last two impact vali

Re: [dns-operations] Google DNS used as amplification - aren't they caching?

Paul Wouters wrote: > > Oh, the irony :) > > http://lists.opendnssec.org/pipermail/opendnssec-user/2012-September/002195.html What harm is done by cacheing NSEC3PARAM records? Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Westerly or northwesterly, 4 or 5, occasionally 6 in southeas

Re: [dns-operations] Validating or not validating (ICANN controlled interruption)

Peter van Dijk wrote: > > But Unbound is right. The NSEC3 that covers the name you are asking for > has the opt-out flag set, and hence the denial is insecure (but not > bogus). Setting AD is, to my knowledge, not valid here. I think you are right, though it can be a bit difficult to know when to

Re: [dns-operations] Validating or not validating (ICANN controlled interruption)

Stephane Bortzmeyer wrote: > Ralf Weber wrote: > > > > In some cases (difficult to pinpoint, depending on the resolver's > > > state), both BIND and Unbound return SERVFAIL. > > Could you be more specific. > version.bind. 0 CH TXT "9.8.0-P4.jp" The BIND CHANGES file includes the follow

Re: [dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to?

Rubens Kuhl 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

Re: [dns-operations] is there a diagnostic tool to obtain delegated ns?

Paul Vixie 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

Re: [dns-operations] Hearing first complains about failing internal resolving due to .prod TLD

Paul Ferguson 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.finchhttp://dotat.at/ Trafalgar: Cy

Re: [dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to?

Warren Kumari wrote: > > I cannot remember all the details, but basically I create a host > object (nameserver) named whatever the service I want to serve is -- > so, if I have example.com, I register the nameserver as > 'www.example.com', with the IP of my webserver, and now most of my > lookups

Re: [dns-operations] EDNS with IPv4 and IPv6 (DNSSEC or large answers)

Franck Martin wrote: > > What is the recommended setup for EDNS? > -limit size to <1500? on both IPv4 and IPv6? Yes, on some if not all of your authority servers. That is, you need to limit the size of response that you send (max-udp-size in BIND terms). (Don't get confused with your advertized E

Re: [dns-operations] EDNS with IPv4 and IPv6 (DNSSEC or large answers)

Roland Dobbins wrote: > On Sep 15, 2014, at 5:52 PM, Tony Finch wrote: > > > That is, you need to limit the size of response that you send (max-udp-size > > in BIND terms). > > Do you recommend that it be lowered to 1280 or thereabouts for IPv6? Not enough data, sorry.

Re: [dns-operations] How to tell bind to ignore DNSSEC for a domain/zone

Franck Martin 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.finchhttp://dotat.at/ Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly 5 or 6

Re: [dns-operations] ShellShock exploit through the DNS

P Vixie 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.finchhttp://dotat.at/ Trafalgar: Cyclonic

Re: [dns-operations] ShellShock exploit through the DNS

The best article I have seen on the topic is by David A Wheeler (linked below). Section 2 on design approaches that would have avoided the bug is particularly good, and is not specific to unix shells. (Though it would be a great exaggeration to say it has much to do with DNS operations.) http://ww

Re: [dns-operations] resolvers considered harmful

Joe Greco 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 def

Re: [dns-operations] resolvers considered harmful

Phillip Hallam-Baker wrote: > > Right now I do not see any transition plan from IPv4 to IPv6. We have > plenty of plans that let us use IPv6 only but as yet no plan that lets us > put a pure IPv6 device on a mixed network and achieve 100% connectivity > with legacy IPv4 hosts. Such a device would

Re: [dns-operations] SERVFAIL/FORMERR for TXT mta.email.(office|microsoftonline).com

Derek Diget wrote: > > I initially asked this question on the mailop list > 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.nosig

Re: [dns-operations] Logging dns record changes

Ayca Taskin (Garanti Teknoloji) 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.finchhttp://dotat.at/ German Bight: Southeast 5 to 7. Moderate or rough. Occasi

Re: [dns-operations] Bind v6 TCP listen?

Jared Mauch 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.finchhttp://dotat.at/ Fitzroy, Sole: Southerly 6 to gale 8, occ

Re: [dns-operations] cool idea regarding root zone inviolability

Paul Vixie wrote: > > dan kaminsky proposed several years ago that a stub be able to request, > by EDNS, the full RRSIG/DNSKEY/DS chain from the qname upward to some > specified TA, to permit stub validation without requiring a stub cache > or to spend many round trips on a validation. You can do

Re: [dns-operations] reopening discussion of stalled i-d: draft-ietf-dnsop-edns-chain-query

Paul Vixie 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.) > > Th

Re: [dns-operations] reopening discussion of stalled i-d: draft-ietf-dnsop-edns-chain-query

Paul Vixie 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 O

Re: [dns-operations] DNS Security Advisory (infinite recursion)

I just saw this bit in RFC 1034 page 34/35 Step 2 looks for a name server to ask for the required data. [...] Set up their addresses using local data. It may be the case that the addresses are not available. The resolver has many choices here; the best is to start parallel resolver processes lo

Re: [dns-operations] knot-dns

Florian Weimer wrote: > > In particular, running different implementations behind a load > balancer on the same public IP address can break EDNS detection by > resolvers, and crafted queries sent to a resolver can make data > unavailable to that resolver (until a timeout occurs). I would be inter

Re: [dns-operations] DNSSEC on host listed in MNAME

Alexander Mayrhofer 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

Re: [dns-operations] Test on Priming Behavior

Davey Song 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.finchhttp://dotat.at/ Portland, Plymouth: Southwest 5 to 7. Rough or very rough. Occasional drizz

Re: [dns-operations] Best Resources for Deep Dive Understanding of DNS

Rubens Kuhl 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 .int

Re: [dns-operations] Sharing a DNSSEC key between zones

> On 9 Jan 2015, at 12:50, Stephane Bortzmeyer wrote: > > I'm looking for resources discussing the pros and cons of sharing > DNSSEC keys between zones. > > I find nothing in RFC 6841 or 6781. Any pointer? There is a paragraph about this at http://users.isc.org/~jreed/dnssec-guide/dnssec-guid

Re: [dns-operations] extra records in resolver answer, any benefit?

bert hubert 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 dat

Re: [dns-operations] Root-servers returning TC=1 after 5 NXDOMAINS

Paul Hoffman 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

Re: [dns-operations] Mozilla Firefox and ANY queries

Fred Morris 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.fi

Re: [dns-operations] Mozilla Firefox and ANY queries

Paul Wouters 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? Wou

Re: [dns-operations] dnsop-any-notimp violates the DNS standards

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. There are three bugs in the way qmail uses ANY queries. (1) qmail

Re: [dns-operations] [DNSOP] dnsop-any-notimp violates the DNS standards

bert hubert 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.

Re: [dns-operations] dnsop-any-notimp violates the DNS standards

Jared Mauch 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 ex

Re: [dns-operations] [DNSOP] dnsop-any-notimp violates the DNS standards

Darcy Kevin (FCA) 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

Re: [dns-operations] What would it take...

Edward Lewis 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

Re: [dns-operations] introducing: dnsdist

bert hubert 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 bal

Re: [dns-operations] dnsop-any-notimp violates the DNS standards

Edward Lewis 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 incl

Re: [dns-operations] Postures was Re: Stunning security discovery: AXFR may leak information

Edward Lewis 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.finchhttp://dotat.at/ Trafalgar: Cyclonic 5 or 6. Moderate or rough. Thundery showers. Moderate or good. ___

Re: [dns-operations] calculating DNSSEC keytags in awk

Frank 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

Re: [dns-operations] Authoritative name server replies NODATA for a non-existing domain

Robert Edmonds wrote: > > Interestingly, the two servers that return NOERROR are distinguishable > from the others using fpdns: > > fingerprint (a0.nic.adult., 199.115.152.1): No match found > fingerprint (a0.nic.adult., 2001:500:a0:0:0:0:0:1): No match found Gosh, doesn't fpdns try versi

Re: [dns-operations] com. Glue

Joe Abley 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

Re: [dns-operations] Trying - Re: Fwd: Re: [Security] Glue or not glue?

Edward Lewis 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. h

[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

Re: [dns-operations] sibling glue

Joe Abley 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 re

Re: [dns-operations] sibling glue

Stephane Bortzmeyer 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.finchhttp://dotat.at/ Trafalgar: In southeast, northerly 4 or 5, occasionally 6 later, but becoming

Re: [dns-operations] sibling glue

This thread from last year has a good discussion of these issues: http://thread.gmane.org/gmane.network.dns.operations/3623 Tony. -- f.anthony.n.finchhttp://dotat.at/ Fair Isle: Variable 4 at first in north, otherwise southeasterly 5 or 6. Slight or moderate. Occasional rain and fog patches

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'

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 addr

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

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)

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

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 {

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

Re: [dns-operations] [EXT] Monitoring DNS BIND with SNMP ?

Jake Zack wrote: > > 1) Perl script runs… > > a. Reads in last intervals query number total > > b. Runs ‘rndc stats’ > > c. Reads in this intervals query number total > > d. Subtracts one from the other (you need to handle BIND restarts, > though. If $current < $last then

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`

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

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/133633

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 platf

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 bal

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 st

[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 G

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.

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://git

[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 re

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

[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 tha

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 o

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::

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-prefi

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

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

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

[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 th

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 l

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,

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

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

  1   2   >