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

[Tony Finch]

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, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor 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] dns-operations Digest, Vol 92, Issue 13

[Tony Finch]

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 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor 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] Can MX be working with CNAME?

[Tony Finch]

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 going to work. MX pointing to CNAME probably will work.

CNAME pointing to anything should work, except for the historical screwup
in the way mail software handles CNAME. Note that this does not just
affect CNAME pointing to MX, but also CNAME pointing to A and CNAME
pointing to , when the CNAME is used as a mail domain.

> The problem with the above specifically is that Sendmail will cause some
> issues, as it will lookup the CNAME, and replace all headers with the
> destination, [...]
>
> Sendmail is one of the few and maybe only SMTP server that does though
> and hence you will just get very inconsistent results depending if the
> remote site (which you do not control) still uses that.

This is a remnant of the pre-DRUMS email specifications, in particular the
requirement in RFC 821 that domain aliases (i.e. CNAMEs) are not allowed
in mail, and the clarification in RFC 1123 that CNAMEs should be
interpreted as instructions to rewrite domains.

Other MTAs do similar things, for instance qmail rewrites envelope domains
(but not message headers) - http://fanf.livejournal.com/10.html

The IETF Detailed Revision and Update of Messaging Standards working group
decided to remove the ban on CNAME domains in the 1990s. But they are
still an interop disaster.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor 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] Can MX be working with CNAME?

[Tony Finch]

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, and if you
have the time you could read the discussions of this feature in the
ietf-smtp mailing list archives.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at
first. Rough, becoming slight or moderate. Showers, rain at first.
Moderate or good, occasionally poor 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] summary of recent vulnerabilities in DNS security.

[Tony Finch]

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 buffer sizes greater than the MTU are
a good idea.

Apart from avoiding fragments, are there other ways to mitigate this
attack? Perhaps by adjusting the way the recursive server handles lame
authorities, perhaps by making it more eager to re-fetch the delegation
from the parent authorities?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor 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] summary of recent vulnerabilities in DNS security.

[Tony Finch]

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. Showers, rain at first. Moderate or good,
occasionally poor 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] chrome's 10 character QNAMEs to detect NXDOMAIN rewriting

[Tony Finch]

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 authoritative and
> > recursive service into the same server, and the only implementation i
> > know of that does that is BIND 9. ...

Yadifa says it will do recursive and authoritative service in version 2.
http://www.yadifa.eu/release-300-q3-2013

> this is true.

Except that you could (I think) use Unbound as your resolver and configure
it with a stub zone for the root pointing at a local NSD which slaves the
root.

> [...] any wide-spread support for "root zone hidden slave" would have to
> deal with this. TSIG isn't the answer since the signing key has to be
> secret if we want to prevent MiTM attacks on hidden slave root zone
> content.

TKEY ought to do the trick.

> > ..., here's a crazy idea: now that the root zone is signed, add a 14th
> > root letter, and allow AS112-style service for this new root's service
> > addresses.  that way a local network could serve the root zone locally
> > (not announcing the service prefixes to any of its peers or upstreams),
> > and thus would still have at least one root server available in the case
> > of a catastrophe, and it wouldn't be dependent on any implementation
> > specifics or even configuration settings in the recursive DNS server in
> > order to achieve. [...]
>
> i loved that idea so much that i suggested it to ICANN's Identifier
> Technology Innovation committee (of which i am also a member) a few days
> before i saw the above-quoted text. see 3.(A). in the text located at:
>
> http://mm.icann.org/pipermail/itipanel/2013-November/17.html

Sounds a lot like the ICANN L-root dense anycast model.
http://blog.icann.org/2012/03/l-root-in-your-pocket/
http://www.menog.org/presentations/menog-10/Dave%20Knight%20-%20Dense%20Anycast%20Deployment%20of%20DNS%20Authority%20Servers.pdf

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor 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

[dns-operations] Fun with DNAME and DNSSEC

[Tony Finch]

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 example dig output below.

We now have secure delegation chains for both the reverse DNS down to
232.128.in-addr.arpa where the DNAMEs live, and to the DNAME target zone
in-addr.arpa.cam.ac.uk where the PTR records live.

So I thought it would be amusing to see what various debugging tools do
with these domain names.

The Verisign Labs DNSSEC debugger does quite well, though it does not
understand that CNAME records synthesized from DNAME records do not have
RRSIG records.

http://dnssec-debugger.verisignlabs.com/252.252.232.128.in-addr.arpa

The Sandia DNSViz tool seems to be discombobulated by something, and fails
to show anything unless I turn on the "denial of existence" option.

http://dnsviz.net/d/252.252.232.128.in-addr.arpa/dnssec/


; <<>> DiG 9.10.0a1 <<>> +dnssec +multiline +noauthority +noadditional 
252.252.232.128.in-addr.arpa in ptr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64633
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 7, ADDITIONAL: 18

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;252.252.232.128.in-addr.arpa. IN PTR

;; ANSWER SECTION:
252.232.128.in-addr.arpa. 78164 IN DNAME 252.232.128.in-addr.arpa.cam.ac.uk.
252.232.128.in-addr.arpa. 78164 IN RRSIG DNAME 5 5 86400 (
20140214154356 20140115150233 48747 
232.128.IN-ADDR.ARPA.
K/9DBl1nZ+arz42ZYJFruVQE7xiC9AOba3IPH+gKfV6o
nLdEUOGNmXQd9W4YHZ+XPxjSxrp5tHTid/a+b1Ngf4ai
18HW6El2HXy4qhGMLCFrH9mwWOZpiLKr4tANUGA2Ofst
8FAzoH+ZnIMmT1DAEcGmSZ+UZvlXZmZWQFCWjwA= )
252.252.232.128.in-addr.arpa. 78164 IN CNAME 
252.252.232.128.in-addr.arpa.cam.ac.uk.
252.252.232.128.in-addr.arpa.cam.ac.uk. 78164 IN PTR 
gw-223.route-opress.net.cam.ac.uk.
252.252.232.128.in-addr.arpa.cam.ac.uk. 78164 IN RRSIG PTR 5 9 86400 (
20140220054710 20140123155918 16635 
in-addr.arpa.cam.ac.uk.
LcXH4IRs1y1NVNEFuZN1Wt3l/JJxWi2qZX4QfW1eZERP
KlfHzIz4Mx/IzMr2f6vZ5zuluxE1uYTA+RIWhg3Lst0K
mECrDDnEtuy8ZE3iclKajXTDjNI23o+NhQ4gLcpHkxNb
GMocc6LoT8lyetbf88JdDsc= )

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Tue Jan 28 14:41:48 GMT 2014
;; MSG SIZE  rcvd: 2316

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor 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] Fun with DNAME and DNSSEC

[Tony Finch]

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, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor 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] Fun with DNAME and DNSSEC

[Tony Finch]

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!

Well, mostly. It's complaining about being unable to get the
in-addr.arpa.cam.ac.uk DNSKEY RRset from 129.169.8.8, which I thought my
colleagues fixed yesterday - it works when I try the query from a couple
of off-campus locations.

> Note that there are two "bubbles" for CNAME because one server provided a
> different TTL (0) than the others (86400), the former following RFC 2672,
> and the latter following updated TTL guidelines in RFC 6672.  Curiously,
> for the server returning the 0 TTL, the corresponding IPv6 address (i.e.,
> by the same name) returns the 86400 TTL.

This is ns.ripe.net which appears to be load-balancing across multiple
name server implementations, on IPv4 and IPv6 - that is, the difference
you saw was due to the load balancing not the different IP version. I can
see three distinct behaviours when I repeat the following queries:

$ dig +nsid @ns.ripe.net. 252.252.232.128.in-addr.arpa. in ptr
$ dig +nsid @ns.ripe.net. version.bind. ch txt

ns1.ams.authdns.ripe.net returns a CNAME with a full TTL and an empty
authority section. It is running "9.9.4-P2".

ns2.ams.authdns.ripe.net returns a CNAME with a zero TTL and a SOA in the
authority section. It is running "Knot DNS 1.4.2".

ns3.ams.authdns.ripe.net returns a CNAME with a zero TTL and an empty
authority section. It is running "NSD 4.0.1".

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor 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] Fun with DNAME and DNSSEC

[Tony Finch]

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 analysis didn't complete until
15:42. Oops! Still a bit puzzled why it wasn't working earlier today, 14
hours after the fix...

Anyway, thanks for the great tool.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor 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] rate-limiting state

[Tony Finch]

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 survive say with 2 retries,
> then I need to let through 40% of traffic to have a 95p confidence of them
> getting an answer. Yes, I'll have mitigated the reflection to 4Gbit/sec,
> but meanwhile users will be seeing increased resolution times and timeouts.

You seem to be assuming that RRL is a blanket rate limit. It is not.

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 to the victim without affecting other users.

In the absence of RRL, the victim will be denied service by overwhelming
traffic. In the presence of RRL the victim might have slightly slower DNS
resolution.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor 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] rate-limiting state

[Tony Finch]

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 to the victim without affecting other users.
> >
> > In the absence of RRL, the victim will be denied service by overwhelming
> > traffic. In the presence of RRL the victim might have slightly slower DNS
> > resolution.
>
> Not just the victim.

What not just the victim? In the absence of RRL the DDoS attack is likely
to cause collateral damage, yes. In the presence of RRL non-victims are
unaffected as long as the attack isn't overwhelming the name server.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor 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] rate-limiting state

[Tony Finch]

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 even if
> it ends up not sending most of them.

At that point the name server itself is the victim, and there isn't
anything it can do about the attack - DDoS mitigation has to happen well
upstream of the victim.

I picked 1000pps because it is enough to trigger RRL without killing the
server.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor 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] Atlas Probe - Result question hostname.bind = "clboh-dns-cac-307"

[Tony Finch]

$ 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, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor 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] Does DNSSEC provide any mitigation for SSL bugs, like Apple's?

[Tony Finch]

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 is public
information) so DANE and DNSSEC say it is good.

At this point things ought to break - the attacker does not have the
private key matching the certificate. But Apple's code failed to check the
signature properly. So you end up talking to the attacker, but thinking
you have authenticated the legitimate site.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
North Bailey: Southeasterly backing northeasterly 6 to gale 8, occasionally
severe gale 9. Rough or very rough. 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] should recursors think there are only delegation data in tld name servers?

[Tony Finch]

刘明星  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.172800  IN  A   81.91.161.98

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Irish Sea: Northeast 4 or 5, veering southeast 5 or 6 later. 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
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[Tony Finch]

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 gaping lacuna ...

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
East Sole, Lundy, Fastnet: Northeasterly 5 or 6, veering southeasterly 4 or 5,
becoming cyclonic 5 to 7, perhaps gale 8 later. Rough. Rain or thundery
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] about the underline in hostname

[Tony Finch]

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
> --- end quote ---

The name comes from "Sigma-7 Experimental Timesharing System"

http://www.postel.org/pipermail/internet-history/2012-May/002208.html

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Fair Isle, Faeroes: Mainly southeasterly 4 or 5, occasionally 6 at first in
east Fair Isle, decreasing 3 at times. Moderate, occasionally slight.
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] alidns

[Tony Finch]

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 that triggers the DS grandparent problem for testing?

The web page says something about them using BGP anycast for speed, but
they don't have any nodes near me. But they do not appear to be aiming
their service at Europeans :-)

ANY queries seem to trigger SERVFAIL.

I am not sure if the occasional slow response is due to rate-limiting or
packet loss.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Trafalgar: Westerly or southwesterly, 4 or 5 in southeast but 6 to gale 8 in
northwest. Slight or moderate, becoming rough or very rough in northwest. Rain
or thundery 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] What's wrong with my domain?

[Tony Finch]

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 35043 7 1 A48FC3310C9CD8708A537FB4DA8915C242378535
gu.edu. IN DS 35043 7 2 
A8AC9D69063266914164F5B756AE61C226C50CA1473C0A4E8FF9F887037A5713
gu.edu. IN DS 39339 7 1 1D35C9E35C17C1DF9577B5CC006C1CD3D4D139BB
gu.edu. IN DS 39339 7 2 
F679B374683EAD2FFB5AFC9B9EB7B2C2E9FA2ADE59020615D9CD71436CF586E1

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Humber, Thames: South or southwest 4 or 5, occasionally 6 in Humber. Mainly
slight. 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] What's wrong with my domain?

[Tony Finch]

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 prevent a KSK rollover going ahead without a
DS change?!

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
South Utsire: Westerly 3 or 4, backing southwesterly 5 or 6 for a time. Slight
or moderate. Rain for a time. 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] www.factorymoneystore.gov DNSSec Failures

[Tony Finch]

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 validators running behind firewalls that limit
> responses to 512 bytes.

The last one also provokes interop problems with BIND 9.10 even without a
firewall in the way.

Truncation seems to be Really Hard to get right :-(

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Rockall: Northwesterly, backing southwesterly for a time, 4 or 5, increasing 6
later in north. Slight or moderate, becoming rough or very rough in northwest.
Rain for a time. 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] Google DNS used as amplification - aren't they caching?

[Tony Finch]

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 southeast.
Slight or moderate. Occasional rain or showers. Moderate or good, occasionally
poor in northeast.
___
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] Validating or not validating (ICANN controlled interruption)

[Tony Finch]

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
set AD :-) I think the most pertinent text in RFC 5155 is in section 12.2
Opt-Out Considerations:

   Note that with or without Opt-Out, an insecure delegation may be
   undetectably altered by an attacker.  Because of this, the primary
   difference in security when using Opt-Out is the loss of the ability
   to prove the existence or nonexistence of an insecure delegation
   within the span of an Opt-Out NSEC3 RR.

   In particular, this means that a malicious entity may be able to
   insert or delete RRs with unsigned names.  These RRs are normally NS
   RRs, but this also includes signed wildcard expansions (while the
   wildcard RR itself is signed, its expanded name is an unsigned name).

Tony.
-- 
f.anthony.n.finchhttp://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] Validating or not validating (ICANN controlled interruption)

[Tony Finch]

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 following, which first appeared on the
9.8 branch in version 9.8.2.

3175.   [bug]   Fix how DNSSEC positive wildcard responses from a
NSEC3 signed zone are validated.  Stop sending a
unnecessary NSEC3 record when generating such
responses. [RT #26200]

Tony.
-- 
f.anthony.n.finchhttp://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?

[Tony Finch]

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 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.finchhttp://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?

[Tony Finch]

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 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.finchhttp://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

[Tony Finch]

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

[Tony Finch]

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 are handled simply by the glue.

That shouldn't work. RFC 2181 says you can't promote glue to an answer:

   Unauthenticated RRs received and cached from the least trustworthy of
   those groupings, that is data from the additional data section, and
   data from the authority section of a non-authoritative answer, should
   not be cached in such a way that they would ever be returned as
   answers to a received query.  They may be returned as additional
   information where appropriate.  Ignoring this would allow the
   trustworthiness of relatively untrustworthy data to be increased
   without cause or excuse.

Tony.
-- 
f.anthony.n.finchhttp://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] EDNS with IPv4 and IPv6 (DNSSEC or large answers)

[Tony Finch]

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 EDNS buffer size which is for
receiving responses, mainly on recursive servers.)

This improves your interoperability with resolvers at other sites that
have broken networks which drop fragmented packets.

https://dnssec.surfnet.nl/wp-content/uploads/2012/09/Recommendations-for-dealing-with-fragmentation-in-DNS-v3.pdf
https://www.usenix.org/sites/default/files/conference/protected-files/vanrisjwik_lisa12_slides.pdf

Tony.
-- 
f.anthony.n.finchhttp://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] EDNS with IPv4 and IPv6 (DNSSEC or large answers)

[Tony Finch]

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. In practice the ethernet MTU minus some slop for
headers and tunnels seems to be enough. Our main experience of DNS
resolution problems has been with Windows shops (the symptom is delayed
mail from Exchange servers) and I have never been able to get in touch
with a tech who cares enough about the problem to provide details or help
fix it.

Tony.
-- 
f.anthony.n.finchhttp://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

[Tony Finch]

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

[Tony Finch]

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

[Tony Finch]

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://www.dwheeler.com/essays/shellshock.html

Tony.
-- 
f.anthony.n.finchhttp://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] resolvers considered harmful

[Tony Finch]

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 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.finchhttp://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] resolvers considered harmful

[Tony Finch]

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 never make A record queries. It
> would only make  queries.
>
> But give me a trusted path to an IPv6 resolver that I can trust to rewrite
> DNS records so that my requests for hosts with only IPv4 connectivity are
> rewritten to give me the address of a suitable gateway for that particular
> AS.
>
> The only thing that breaks is the DNSSEC signature on the  record. And
> that should not matter because an Internet application only cares about
> domain names, the address should not be visible.

As I understand it the plan is to tell clients about the network's
NAT64/DNS64 configuration so that clients can do their own DNS64
synthesis, which means the DNSSEC breakage no longer matters.

Tony.
-- 
f.anthony.n.finchhttp://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] SERVFAIL/FORMERR for TXT mta.email.(office|microsoftonline).com

[Tony Finch]

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.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.finchhttp://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] Logging dns record changes

[Tony Finch]

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. 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] Bind v6 TCP listen?

[Tony Finch]

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, 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] cool idea regarding root zone inviolability

[Tony Finch]

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

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Southeast Iceland: Southerly veering southwesterly 7 to severe gale 9,
occasionally storm 10 for a time in northwest. Rough or very rough, becoming
high. Rain then wintry showers. Moderate, 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] reopening discussion of stalled i-d: draft-ietf-dnsop-edns-chain-query

[Tony Finch]

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.)
> > 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.finchhttp://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] reopening discussion of stalled i-d: draft-ietf-dnsop-edns-chain-query

[Tony Finch]

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 OK?

Tony.
-- 
f.anthony.n.finchhttp://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] DNS Security Advisory (infinite recursion)

[Tony Finch]

I just saw this bit in RFC 1034 page 34/35

Step 2 looks for a name server to ask for the required data.  [...] Set up
their addresses using local data.  It may be the case that the addresses
are not available.  The resolver has many choices here; the best is to
start parallel resolver processes looking for the addresses while
continuing onward with the addresses which are available.  Obviously, the
design choices and options are complicated and a function of the local
host's capabilities.  The recommended priorities for the resolver designer
are:

   1. Bound the amount of work (packets sent, parallel processes
  started) so that a request can't get into an infinite loop or
  start off a chain reaction of requests or queries with other
  implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
  SOME DATA.

... So I guess Jeeves wasn't vulnerable to this bug?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Biscay, Southeast Fitzroy: North or northwest 5, backing west or northwest 5
to 7. Rough or very rough. 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
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] knot-dns

[Tony Finch]

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 interested to know what problems of this kind that RIPE have
observed.

$ for i in $(jot 20)
  do dig +noall +answer version.bind ch txt @pri.authdns.ripe.net.
  done | sort | uniq -c
   4 version.bind.  0   CH  TXT "9.10.1-P1"
   8 version.bind.  0   CH  TXT "Knot DNS 1.6.0"
   8 version.bind.  0   CH  TXT "NSD 4.1.0"

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Fitzroy, Sole: Westerly or northwesterly 5 or 6, occasionally 4 in east. Rough
or very rough, occasionally moderate in east. Rain at times. 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

[Tony Finch]

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 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.finchhttp://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

[Tony Finch]

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 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] Best Resources for Deep Dive Understanding of DNS

[Tony Finch]

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 .internal.company.com
>  (where company.com 
> is registered to you) is a good thing; using .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.finchhttp://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] Sharing a DNSSEC key between zones

[Tony Finch]

> 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-guide.html#same-key-for-multiple-zones

It seems to me that most of the cost of DNSSEC key management is dealing with 
parent delegation changes. Sharing keys between zones does NOT help with this, 
partly because the zone name is part of the DS hash, so DS records are 
different for the same key in different zones.

About the only reason I can see for sharing keys is if you are using an HSM 
which does not support as many keys as you have zones.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at
___
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?

[Tony Finch]

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 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.finchhttp://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] Root-servers returning TC=1 after 5 NXDOMAINS

[Tony Finch]

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 a trivial bypass.

Tony.
-- 
f.anthony.n.finchhttp://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] Mozilla Firefox and ANY queries

[Tony Finch]

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.finchhttp://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] Mozilla Firefox and ANY queries

[Tony Finch]

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? 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.finchhttp://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] dnsop-any-notimp violates the DNS standards

[Tony Finch]

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 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.finchhttp://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

[Tony Finch]

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.
>
> 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.finchhttp://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

[Tony Finch]

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 existing definitions.

This would have the amusing effect of disabling qmail's address
canonicalization without patching qmail.

Tony.
-- 
f.anthony.n.finchhttp://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] [DNSOP] dnsop-any-notimp violates the DNS standards

[Tony Finch]

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 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.finchhttp://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] What would it take...

[Tony Finch]

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 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.finchhttp://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

[Tony Finch]

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 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.finchhttp://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-any-notimp violates the DNS standards

[Tony Finch]

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 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.finchhttp://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] Postures was Re: Stunning security discovery: AXFR may leak information

[Tony Finch]

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.
___
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

[Tony Finch]

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 | awk 'NR == 1 { print $4 }'

Tony.
-- 
f.anthony.n.finchhttp://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] Authoritative name server replies NODATA for a non-existing domain

[Tony Finch]

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 version.bind ?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Wight, Portland, Plymouth: East or northeast 5 or 6, becoming variable 3 or 4
later. Slight or moderate, occasionally rough Plymouth. Fog patches later.
Good, occasionally very 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] com. Glue

[Tony Finch]

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 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.finchhttp://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] Trying - Re: Fwd: Re: [Security] Glue or not glue?

[Tony Finch]

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.

https://blog.cloudflare.com/updating-the-dns-registration-model-to-keep-pace-with-todays-internet/

Tony.
-- 
f.anthony.n.finchhttp://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

[dns-operations] sibling glue

[Tony Finch]

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.finchhttp://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] sibling glue

[Tony Finch]

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 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.finchhttp://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

[Tony Finch]

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

[Tony Finch]

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 in south. Moderate or
good, occasionally very poor in south.
___
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] Link-local IP addresses for a resolver?

[Tony Finch]

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] Link-local IP addresses for a resolver?

[Tony Finch]

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] Random question about Google resolver behaviour and long-lived TCP sessions

[Tony Finch]

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] CNAMEs pointing off into the weeds - inconsistent behavior from different recursive codebases

[Tony Finch]

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] sophosxl.net problem?

[Tony Finch]

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] sophosxl.net problem?

[Tony Finch]

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?

[Tony Finch]

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] [EXT] Monitoring DNS BIND with SNMP ?

[Tony Finch]

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 disregard…otherwise it makes graphs
> useless due to insane values)
>
> e.   Saves this intervals delta to a file

I use the statistics server for this: it is less janky than reading the
statistics file and can be fetched remotely. The output from
http://server:8053/json/v1/server is about 10KB and usually has the info I
need, e.g. opcodes.QUERY, nsstats.QryTCP, nsstats.QryUDP, boot-time (for
detecting restarts).

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
harness technological change to human advantage___
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?

[Tony Finch]

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] root? we don't need no stinkin' root!

[Tony Finch]

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] root? we don't need no stinkin' root!

[Tony Finch]

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!

[Tony Finch]

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!

[Tony Finch]

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!

[Tony Finch]

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

[dns-operations] saveroot on GitHub

[Tony Finch]

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!

[Tony Finch]

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

Re: [dns-operations] root? we don't need no stinkin' root!

[Tony Finch]

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

[dns-operations] really old root zones for saveroot

[Tony Finch]

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] really old root zones for saveroot

[Tony Finch]

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] root zone weirdness

[Tony Finch]

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] Surprising behaviour by certain authoritative name servers

[Tony Finch]

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

Re: [dns-operations] Google DNS Admin

[Tony Finch]

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] [Ext] Re: help with a resolution

[Tony Finch]

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] SHA-1 chosen-prefix collisions

[Tony Finch]

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

[Tony Finch]

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

[Tony Finch]

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

[dns-operations] any registries require DNSKEY not DS?

[Tony Finch]

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] any registries require DNSKEY not DS?

[Tony Finch]

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

Re: [dns-operations] any registries require DNSKEY not DS?

[Tony Finch]

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?

[Tony Finch]

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] SHA-1 (algs 5 and 7), planning to switch to something non-deprecated?

[Tony Finch]

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