Re: IERS ponders reverse leapsecond...

[Tony Finch]

Forrest Christian (List Account)  wrote:
>
> Hopefully there will be some movement next year when they're scheduled to
> discuss it again.It's unfortunate that the first negative leap second
> is likely to occur before then.

Not that soon! There is not likely to be a leap second for 5 years or so,
based on the current projections.

The value to keep an eye on is UT1-UTC which is required by ITU TF.460 to
be between -0.9s and +0.9s; leap seconds are added by the IERS to keep it
in range. Broadcast time signals include a DUT1 value that is UT1-UTC
rounded to 0.1s precision, which must be between -0.8s and +0.8s.

DUT1 is currently 0.0s.

In the last couple of decades, DUT1 has decreased by about 1ms per day (on
average) which requires a positive leap second every few years.

In 2016, the length of day was 1.5ms greater than 24h; since then the long
term estimated LoD has been fairly steadily decreasing. It dropped below
24h at the end of 2020, and it's now 0.34ms short. (The LoD increased
slowly in the second half of 2021, but it has been decreasing all this
year.)

Depending on the threshold the IERS chooses, the current long-term LoD
estimate suggests a negative leap second some time between the end of 2026
(for a 0.5s threshold) and the end of 2029 (for a 0.9s threshold). That is
without making any more complicated predictions based on the downward
trend of the estimated long-term LoD.

These numbers come from IERS Bulletin A
https://www.iers.org/IERS/EN/Publications/Bulletins/bulletins.html
analyzed by my program
https://github.com/fanf2/bulletin-a/

My blog article from when this issue became more well known:
https://dotat.at/@/2020-11-13-leap-second-hiatus.html

My other collected links on this topic
https://dotat.at/writing/time.html

-- 
Tony Finchhttps://dotat.at/
Thames, Dover, Wight, Portland, Plymouth: Northeast 3 to 5, veering
east 2 to 4 later in Thames, Dover and Wight. Smooth or slight, but in
Plymouth slight, occasionally moderate at first in west and smooth
later in northeast. Fair. Good.

Re: DNSSEC Best Practices

[Tony Finch]

Arne Jensen  wrote:
>
> RFC8624 "Algorithm Implementation Requirements and Usage Guidance for
> DNSSEC"
>
> -> https://tools.ietf.org/html/rfc8624
>
> > What algorithms do you typically sign with
> > (RSASHA256, ECDSAP256SHA256, both, something other)?
>
> Those two mentioned are the ones that the vast majority seems to sign with.

Yes. I recommend p256 because the security advantages of p384 are not
significant enough to justify the increased costs in space (packet size)
and time.

If for some terrible reason you need to use RSASHA256, use 2048 bit keys,
same as the root zone.

In the future when support is widespread enough, ed25519 will be the best
choice.

> SHA256 and SHA512 have been discussed about vulnerable to length
> extension attacks, where SHA384 hasn't:

Length extension attacks aren't a problem in this context.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Lough Foyle to Carlingford Lough: Northerly or northeasterly 4 or 5,
occasionally 6 at first in far southeast, becoming variable 2 or 3
later. Slight, occasionally moderate at first. Fair at first, then
showers. Good.

Re: login.authorize.net has A and CNAME records

[Tony Finch]

Seth Mattinen  wrote:
>
> I'm beginning to think this is a DNSSEC related problem, I'll ask on the
> pdns-users list. I see it's asking for a DS record on
> login.authorize.net.cdn.cloudflare.net when the nearest one appears to be at
> cloudflare.net, so for some reason that's not being applied all the way down.

The probem is that your resolver is trying to prove that
login.authorize.net.cdn.cloudflare.net isn't a delegation point by
querying for its DS record(s). The Cloudflare authoritative DNS servers
return a SERVFAIL for this query, so your resolver isn't able to validate
the answer.

(I also replied on the pdns-users list)

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Lyme Regis to Lands End including the Isles of Scilly: North or
northwest 5 or 6, occasionally 7 at first near headlands, decreasing 2
to 4. Slight or moderate, becoming smooth in east. Showers, wintry at
first. Good, occasionally moderate at first.

Re: Famous operational issues

[Tony Finch]

Patrick W. Gilmore  wrote:
>
>   Me: Did you order that EPO cover?
>   Her: Nope.

There are apparently two kinds of EPO cover:

- the kind that stops you from pressing the button by mistake;

- and the kind that doesn't, and instead locks the button down to make
sure it isn't un-pressed until everything is safe.

We had a series of incidents similar to yours, so an EPO cover was
belatedly installed. We learned about the second kind of EPO cover when a
colleague proudly demonstrated that the EPO button should no longer be
pressed by accident, or so he thought.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
the quest for freedom and justice can never end

Re: favorite network troubleshooting tools (online)

[Tony Finch]

Mehmet Akcin  wrote:
>
> what are your favorite network troubleshooting tools?

If DNS counts then https://dnsviz.net/ and https://zonemaster.net/

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
South Fitzroy: Northeasterly 5 to 7, occasionally gale 8 in south. Moderate or
rough. Fair. Good.

Re: 60 ms cross-continent

[Tony Finch]

Mel Beckman  wrote:

> An intriguing development in fiber optic media is hollow core optical
> fiber, which achieves 99.7% of the speed of light in a vacuum.
>
> https://www.extremetech.com/computing/151498-researchers-create-fiber-network-that-operates-at-99-7-speed-of-light-smashes-speed-and-latency-records

Here's an update from 7 years after that article which hints at the
downside of hollow core fibre:

https://phys.org/news/2020-03-hollow-core-fiber-technology-mainstream-optical.html

It sounds like attenuation was a big problem: "in the space of 18 months
the attenuation in data-transmitting hollow-core fibers has been reduced
by over a factor of 10, from 3.5dB/km to only 0.28 dB/km within a factor
of two of the attenuation of conventional all-glass fiber technology."

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Shetland Isles: Southeasterly 5 or 6, veering southerly or southwesterly 3 or
4, then backing southeasterly 5 later in southwest. Slight or moderate,
occasionally rough later in far west. Occasional rain then mainly fair, but
showers far in east. Good, occasionally moderate.

Re: BGP over TLS

[Tony Finch]

Joe Abley  wrote:
>
> Well, TLS exists within a TCP session, and that TCP session could
> incorporate the MD5 signature option. I guess.

AIUI this might be useful to make it a bit harder to kill the TCP session,
tho I think modern TCPs are less vulnerable to off-path RST injection
than TCPs were when TCP-MD5 was introduced

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
German Bight, Humber, Thames: Cyclonic, mainly northeast, becoming west later,
3 to 5, occasionally 6 at first. Slight or moderate. Occasional rain. Good,
occasionally poor.

Re: worse than IPv6 Pain Experiment

[Tony Finch]

b...@theworld.com  wrote:
>
> Can I summarize the current round of objections to my admittedly
> off-beat proposal (use basically URLs rather than IP addresses in IP
> packet src/dest) as:

[snip]

This reminds me of the named data networking research project

https://named-data.net/project/faq/

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
St Davids Head to Great Orme Head, including St Georges Channel: Southwest 6
to gale 8, occasionally 5 at first, then veering west or northwest 3 to 5
later. Moderate or rough, occasionally very rough later in far south. Rain or
showers. Moderate or good, occasionally poor later.

Re: dns cache beyond ttl - viasat / exede

[Tony Finch]

William Herrin  wrote:
>
> You may be looking at a web browser "feature" called "DNS pinning." This is
> used to defeat the "DNS rebinding" attack on javascript that would allow a
> web site to instruct a browser to scan the interior behind its user's
> firewall by having an attacker rotate the IP addresses used for
> Javascript's allowed server name.
>
> Depending on the implementation, DNS pinned browsers may not recognize a
> change to your IP address until the browser is stopped and restarted.

I thought DNS pinning was only for the lifetime of the web page, so
closing the tab (or all tabs open on the site...) should be enough, if a
reload isn't.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
democracy, participation, and the co-operative principle

Re: Weekly Routing Table Report

[Tony Finch]

Patrick W. Gilmore  wrote:
>
> This time I waited for 768,000. (Everyone happy now?)

I thought the magic number for breaking old Cisco gear was 786432
(768 * 1024) ... there was a panic about it earlier this year but growth
slowed so it didn't happen as soon as they feared.

https://www.zdnet.com/article/some-internet-outages-predicted-for-the-coming-month-as-768k-day-approaches/

But looking at https://twitter.com/bgp4_table I see we passed the higher
thresold (by some metrics) last month without any apparent routing
failures so maybe the old Cisco gear isn't very important any more!

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
North Foreland to Selsey Bill: Southwesterly veering westerly, 4 or 5,
occasionally 6 at first in east. Smooth or slight, becoming slight,
occasionally moderate. Showers later. Good.

Re: Best ways to ensure redundancy with no terrestrial ISPs

[Tony Finch]

Fred Baker  wrote:
> > On Aug 3, 2019, at 3:36 PM, Mehmet Akcin  wrote:
> >
> > Feel free to open live.infrapedia.com on mobile.

> Between overlaid ads and the thing trying to force an account, i’d
> Describe it as a waste of time. Now, a page that delivered the data
> advertised...

https://openinframap.org/ works a lot better.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
justice and liberty cannot be confined by national boundaries

Re: Cost effective time servers

[Tony Finch]

Denys Fedoryshchenko  wrote:
> On 2019-06-21 14:19, Niels Bakker wrote:
> >
> > Have you tried this?  Because I have, and it's absolutely terrible.
> > GPS doesn't give you the correct time, it's supposed to give you a
> > good 1pps clock discipline against which you can measure your device's
> > internal clock and adjust accordingly for drift due to it not being
> > Cesium-based, influenced by room temperature etc.
> >
> > You're unlikely to get the 1pps signal across USB, and even then
> > there'll likely be significant latencies in the USB stack compared to
> > the serial interface that these setups traditionally use.
>
> I think it depends on recipe you are using.
> Raspberry have low latency GPIO, and some receivers have 1pps output.
> https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html

And there are tricks for avoiding temperature-related deviations :-)

https://blog.ntpsec.org/2017/02/01/heat-it-up.html

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
defend the right to speak, write, worship, associate, and vote freely

Re: NTP for ASBRs?

[Tony Finch]

Bryan Holloway  wrote:
> On 5/8/19 7:55 PM, Brian Kantor wrote:
> > On Wed, May 08, 2019 at 07:47:56PM -0500, Bryan Holloway wrote:
> > >
> > > When a NOC-ling, in their own local timezone, says, "hey, what happened
> > > two hours ago?", they have to make a calculation.
> >
> > Clocks are cheap.
>
> Cheap != free.

You already got one with your computer, and if it is Free Software:

$ TZ=Z date -d '2 hours ago' +%FT%TZ

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Trafalgar: Northwesterly 3 or 4 in southeast, otherwise southwesterly 4 or 5,
occasionally 6 in north. Moderate or rough. Occasional rain. Good,
occasionally poor.

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Tony Finch]

valdis.kletni...@vt.edu  wrote:
>
> Unless you get it down to the SMS "wait for a msg, type in the 6 digit number"
> level, it's going to be a tough start...

Isn't this what Duo's business is based on? Usable TOTP?

See also Google Authenticator, Authy, 1Password, etc. usw.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Southeast Iceland: Southwesterly gale 8 to storm 10, veering westerly 5 to 7
later. High or very high, becoming rough or very rough later. Squally showers.
Moderate or poor.

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Tony Finch]

Mark Andrews  wrote:
>
> An organisation can also deploy DLV for their own zones using their own
> registry.  While the current code DLV validating code is only invoked
> when the response validates as insecure, there is nothing preventing a
> policy which says that DLV trumps or must also validate for entries in a
> registry.  At this stage is would be a minor code change to add such
> policy knobs.  DLV is a just a in-band way of distributing trust
> anchors.

Yes (as Mark knows) I would like to be able to use DLV in this enterprisey
way. It should also help validators to continue working for local domains
when external connectivity is funted.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
East Sole, Lundy, Fastnet, Irish Sea: Southeasterly 4 or 5. Rough or very
rough, but slight or moderate in Irish Sea. Mainly fair. Good, occasionally
poor.

Re: Stupid Question maybe?

[Tony Finch]

> On 18 Dec 2018, at 22:30, Joel Halpern  wrote:
> 
> History of non-contiguous network masks, as I observed it. [snip]
> 
> When we were done, other folks looked at the work (I don't know if the 
> Internet Drafts are still in repositories, but they shoudl be.)  And 
> concluded that while this would work, no network operations staff would ever 
> be able to do it correctly.  So as a community we decided not to go down that 
> path.

In the late 1990s I was doing web server things at Demon Internet. Our 
“Homepages” service provided an IP-based virtual host for each customer (it 
predated widespread support for HTTP Host: headers), and by the time I joined 
the service had two /18s and a /16 of web sites (if my memory is correct). We 
were allocating addresses to customers sequentially, so the /18s were full and 
the /16 was in progress.

We had a small number of front-end Squid reverse proxy caches which owned all 
the IP addresses, using a BSD kernel hack (which I worked on to get published 
but it never got committed upstream 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=12071)

The problem was that the entirely static load spreading relied on the routing 
config upstream from the reverse proxies, and IIRC it just divided the space 
into /18s and allocated them to proxies. So the load allocation was very uneven.

I thought up a cunning hack, to divide the /16 by using a non-contiguous 
netmask of 0x0003 instead of 0xc000, so that successive customers would 
be allocated to front ends 0,1,2,3 cyclically. Fun :-)

But I observed that one of my colleagues had a CIDR chart stuck on the side of 
his monitor, and that all the documentation in this area warned of dragons and 
bugs, and I realised that it would be unwise to do more than try it out 
experimentally :-)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at

Re: Security issues based on post RIR allocation rules

[Tony Finch]

Spurling, Shannon  wrote:

> When I call a health care organization, or a web hosting provider, the
> first thing I get is that they think we are trying to pull one over on
> them and all these ranges must be in Africa or Asia. I show them the
> ARIN information for the specific /16, and sometimes I can make some
> headway. Sometimes there's no convincing them. This issue appears to be
> getting worse over time, so I was wondering if some misguided
> organization or group is going around pressing for the rules that are
> triggering these issues?

I'm somewhat inclined to blame poor `whois` implementations for this.

Apart from `whois` being generally very crappy, there are specific issues
on the server side and the client side which mean the human driving whois
often needs a good deal of expertise to be able to properly track down the
authoritative registration details for a netblock.

On the server side, APNIC and RIPE do not return proper referrals for ERX
netblocks. This is annoying, because they know which of the other RIRs is
responsible for the registration - they have to get the reverse DNS
information from the other RIR. Examples: 150.108.0.0 (an APNIC /8 but the
/16 is allocated to Fordham University and managed through ARIN); and
141.111.0.0 (a RIPE /8 but the /16 is allocated to LANL and managed
through ARIN).

AfriNIC's whois server is more helpful: it seems to proxy queries to RIPE
and APNIC as appopriate, and returns RDAP referrals for ARIN.

On the client side, these days it is mostly possible to find the correct
whois server to ask by following referrals from IANA. (In the past whois
clients had to have a fairly large database of starting points.) A
reasonably intelligent referral-oriented whois client can work around
missing referrals for early netblock allocations by guessing, which
usually means restarting with ARIN. But in practice most whois clients are
pretty stupid, and the referral-oriented ones keep breaking when servers
change. (e.g. I just found out AfriNIC's behaviour has changed since I
last looked...)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
West Forties, Cromarty, Forth: Southerly or southeasterly 5 or 6, occasionally
7 in Cromarty. Moderate, becoming moderate or rough. Mainly fair. Good.

Re: ARIN RPKI TAL deployment issues

[Tony Finch]

John Curran  wrote:
>
> From 
> 
>
> "CA Terms & Conditions
>
> APNIC’s Certification Authority (CA) services are provided under the
> following terms and conditions: ...
>
> • The recipient of any Digital Certificates issued by the APNIC CA
> service will indemnify APNIC against any and all claims by third parties
> for damages of any kind arising from the use of that certificate.”

That's about certificates, not about trust anchors. It applies to APNIC
members and account holders, not to relying parties.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forth: West or southwest 5 to 7, occasionally gale 8 for a time. Moderate.
Rain later. Good, occasionally moderate later.

Re: ARIN RPKI TAL deployment issues

[Tony Finch]

John Curran  wrote:
> On 26 Sep 2018, at 2:09 AM, Christopher Morrow 
> mailto:morrowc.li...@gmail.com>> wrote:
> >
> > how is arin's problem here different from that which 'lets encrypt' is
> > facing with their Cert things?
>
> The “Let’s encrypt” subscriber agreement (current version 1.2, 15 Nov
> 2018) includes "indemnify and hold harmless” clause, and parties
> affirmatively agree to those terms by requesting that ISRG issue a
> "Let’s Encrypt” Certificate to you.

The difference is that the Let's Encrypt agreement is for people obtaining
certificates from them. The ARIN equivalent would be the agreement for
ARIN members.

Let's Encrypt does not require an agreement from relying parties (i.e.
browser users), whereas ARIN does.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Rockall, Malin, Hebrides: Southwest veering northwest, 5 to 7, perhaps gale 8
later, but cyclonic 3 or 4 for a time. Rough or very rough. Rain or showers.
Good occasionally poor.

Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)

[Tony Finch]

Jens Link  wrote:
>
> jens@screen:~$ dig nanog.org @8.8.8.8 | grep "Query time"
> ;; Query time: 16 msec
> jens@screen:~$ dig nanog.org @1.1.1.1 | grep "Query time"
> ;; Query time: 3 msec

You can use dig -u to get microsecond resolution, e.g.

$ dig -u @131.111.8.42 nanog.org | grep time:
;; Query time: 611 usec

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
work to the benefit of all

Re: Time to add 2002::/16 to bogon filters?

[Tony Finch]

Jared Mauch  wrote:
>
> There is also the problem noted by Wes George with 6to4 being used in
> DNS amplification, which may be interesting..
>
> http://iepg.org/2018-03-18-ietf101/wes.pdf

I configure my DNS servers with a long-ish list of bogon addresses. For
v6, the list includes Teredo and 6to4 and various other horrors:

# RFC 5156 and IANA IPv6 address space registry
server  ::/3{ bogus yes; };
server  2001:::/32  { bogus yes; };
server  2001:0002::/48  { bogus yes; };
server  2001:0010::/28  { bogus yes; };
server  2001:0db8::/32  { bogus yes; };
server  2002::/16   { bogus yes; };
server  3000::/4{ bogus yes; };
server  4000::/2{ bogus yes; };
server  8000::/1{ bogus yes; };

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Southeast Iceland: Cyclonic, mainly westerly, 6 to gale 8, decreasing 5 later.
Rough or very rough, becoming moderate or rough later. Showers. Moderate or
good.

Re: Yet another Quadruple DNS?

[Tony Finch]

David Ulevitch  wrote:

> https://twitter.com/eastdakota/status/970214433598275584
> https://twitter.com/eastdakota/status/970359846548549632

Also the very amusing

https://twitter.com/eastdakota/status/970359846548549632

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Hebrides, Bailey: East 5 to 7, occasionally gale 8 at first. Rough,
occasionally very rough at first. Rain or showers. Good, occasionally
moderate.

Re: Internet Governance Forum DNS

[Tony Finch]

Joly MacFie  wrote:

> www.intgovforum.org’s server DNS address could not be found.

One of its three name servers doesn't exist.

; <<>> DiG 9.11.0 <<>> +norec ns www.intgovforum.org @a0.org.afilias-nst.info.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53295
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.intgovforum.org.   IN  NS

;; AUTHORITY SECTION:
intgovforum.org.86400   IN  NS  ns.vervehosting.com.
intgovforum.org.86400   IN  NS  ns2.vervehosting.com.
intgovforum.org.86400   IN  NS  ns1.vervehosting.com.

;; Query time: 251 msec
;; SERVER: 2001:500:e::1#53(2001:500:e::1)
;; WHEN: Fri Dec 09 10:22:00 GMT 2016
;; MSG SIZE  rcvd: 117

; <<>> DiG 9.11.0 <<>> +norec ns1.vervehosting.com. @ns.vervehosting.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 65348
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ns1.vervehosting.com.  IN  A

;; AUTHORITY SECTION:
vervehosting.com.   300 IN  SOA ns.vervehosting.com. 
ccharity.vervehosting.com. 2016061109 14400 7200 1209600 300

;; Query time: 74 msec
;; SERVER: 108.61.21.139#53(108.61.21.139)
;; WHEN: Fri Dec 09 10:24:29 GMT 2016
;; MSG SIZE  rcvd: 97

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Malin, Hebrides: Southerly, veering southwesterly, 6 to gale 8, occasionally 5
in southeast Malin. Rough at first, becoming very rough or high, occasionally
very high later in west Hebrides. Rain then showers. Good, occasionally poor
at first.

Re: Avalanche botnet takedown

[Tony Finch]

Ronald F. Guilmette  wrote:
>
> P.P.S.  I love this part of the press release, because it is so telling:
>
>  "The successful takedown of this server infrastructure was supported
>  by ... Registrar of Last Resort, ICANN..."

Note that these are the names of two different organizations - the part
before the comma is not a description of the role played by ICANN.

http://tldcon.ru/docs/02-Addis.pdf
http://www.rolr.org/goals.en.html

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Humber, Thames: Northwest 4 or 5, veering northeast 3 or 4. Moderate, becoming
slight later in Thames. Showers. Good.

Re: Another day, another illicit SQUAT - WebNX (AS18450) 103.11.67.0/24

[Tony Finch]

Ronald F. Guilmette  wrote:
>
> You are correct.  In this case, it would have been helpful if APNIC's WHOIS
> server returned something, when queried about 103.11.67.105, that would
> include an explicit referral to the ARIN WHOIS server.  I mean they
> obviously know all the transfers they've made.

Yes, the state of whois referrals from RIRs is a bit of a mess.

I have changed FreeBSD whois to rely more on referrals than built-in
knowledge, and this mostly works. There are a couple of hacks to cope with
awkward RIRs: AfriNIC's referrals are human-readable though they can be
parsed if you assume the rubric is fixed; for RIPE, if the netname is
NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK it is treated as a referral to ARIN;
there's a similar hack for APNIC's ERX-NETBLOCKs - but evidently this
doesn't apply to more recently transferred net blocks :-(

It's probably time to make whois use RDAP under the covers for address
lookups. Bah.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Southeast Iceland: Westerly veering northwesterly 6 to gale 8, decreasing 4 or
5 for a time. Rough or very rough, occasionally high at first, then becoming
moderate in west. Showers. Good, occasionally poor.

Re: QWEST.NET can you fix your nameservers

[Tony Finch]

Mark Andrews  wrote:
>
> My bet is the DNS vendor has issued a update already and that it
> hasn't been applied.

$ fpdns sauthns1.qwest.net.
fingerprint (sauthns1.qwest.net., 63.150.72.5): NLnetLabs NSD 3.1.0 -- 3.2.8 
[New Rules]
fingerprint (sauthns1.qwest.net., 2001:428:0:0:0:0:0:7): NLnetLabs NSD 3.1.0 -- 
3.2.8 [New Rules]
$ dig +nocookie +noall +answer version.bind ch txt @sauthns1.qwest.net.
version.bind.   0   CH  TXT "3.2.2"

https://www.nlnetlabs.nl/projects/nsd/
NSD 3.2.2 - May 18, 2009

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Humber, Thames, Dover, Wight: Cyclonic at first, but mainly northerly 5 to 7,
decreasing 4 at times later. Slight or moderate. Occasional rain, perhaps
thundery at first, fog patches at first in Humber. Moderate or poor,
occasionally very poor in Humber.

Re: Don't press the big red buttom on the wall!

[Tony Finch]

Ken Chase  wrote:

> 3 of my internet-lifetimes/startups ago, we had this happen when one of the L2
> techs was doing their 'rounds' - but had a backpack on. They swung around and
> hit the safety cover on the BRS - which got knocked off. They freaked
> out a bit while putting the cover back on... and managed to activate it.

If you get a safety cover for your EPO switch, make sure it is the right
kind of cover. Following an accidental EPO outage, we got a safety cover
that was actually a latch designed to ensure the switch stays pressed
until manually reset. We discoverd this when someone tried to demonstrate
that it was now a lot harder to accidentally press the EPO. (it wasn't)

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Biscay: Variable 3 or 4. Moderate, occasionally slight. Fair. Moderate or
good.

Re: nxdomain rfc2308 type 2, but authority is incorrect

[Tony Finch]

William Herrin  wrote:
>
> Oh! I missed that. ns*.nameresolve.com, the authoratative name servers
> for kissimmee.org, are saying NXDOMAIN for www.kissimmee.org. Any idea
> what DNS server nameresolve.com uses? Because that's... wow.

Er, me too, headdesk. NXDOMAIN with an answer?!

$ fpdns ns2.yourhostingaccount.com.
fingerprint (ns2.yourhostingaccount.com., 65.254.254.155): Unlogic Eagle DNS 
1.0 -- 1.0.1 [New Rules]

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Humber, Thames, Dover: West or southwest 4 or 5, increasing 6 at times. Slight
or moderate. Occasional rain at first. Good, occasionally poor at first.

Re: nxdomain rfc2308 type 2, but authority is incorrect

[Tony Finch]

Joe Maimon  wrote:

> www.kissimmee.org
>
> Windows appears to believe the rfc2308 type 2 response,

RFC 2308 isn't relevant to this domain. The responses aren't NXDOMAIN, so
section 2.1 doesn't apply, and the response includes answers, so section
2.2 doens't apply.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Fisher, German Bight: South, veering west or southwest, 4 or 5, increasing 6
at times. Slight or moderate. Occasional rain. Good, occasionally poor.

Re: Yahoo Postmaster or Email Admin

[Tony Finch]

For this kind of question you might hav emore luck on the mailop list,
https://chilli.nosignal.org/mailman/listinfo/mailop

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
North Fitzroy, Sole, Lundy, Fastnet: Westerly 5 or 6. Moderate, occasionally
rough later. Rain or drizzle. Moderate or poor, occasionally good.

RE: IPv4 Legacy assignment frustration

[Tony Finch]

Spurling, Shannon  wrote:

> It’s a problem with the miss-use of the RIR delegation of a legacy
> block.
>
> The assumption that because a block is assigned to a particular RIR, all
> users in that block have to be in that RIR’s territory, without actually
> running a query against that RIR’s Whois database.

Actually, a simple whois query often isn't enough to solve this problem.
Neither RIPE nor APNIC do proper whois referrals for IPv4 addresses that
are registered in other RIRs. ARIN, however, does.

(However, if the geoip people are using whois data, I can't believe they
aren't handling cases like this properly, because it's blatantly obvious
if you scan IPv4 address space for referrals.)


If you use FreeBSD-CURRENT's whois client, it tries to work mostly by
following referrals, rather than using a built-in database mapping query
strings to whois servers. If you query for 150.199.0.0 (for example) you
get the following (which I have brutally trimmed for length):

% IANA WHOIS server

refer:whois.apnic.net

inetnum:  150.0.0.0 - 150.255.255.255
organisation: Administered by APNIC
status:   LEGACY

% [whois.apnic.net]

inetnum:150.0.0.0 - 150.255.255.255
netname:ERX-NETBLOCK
descr:  Early registration addresses

remarks:Address ranges from this historical space have now
remarks:been transferred to the appropriate RIR database.remarks:
remarks:If your search has returned this record, it means the
remarks:address range is not administered by APNIC.
remarks:
remarks:Instead, please search one of the following databases:

(It then unhelpfully lists all the other RIRs.)

FreeBSD's whois client spots this failure then retries the query at ARIN.


There's a similar problem with RIPE, for instance if you query for
141.211.0.0:

% IANA WHOIS server

refer:whois.ripe.net

inetnum:  141.0.0.0 - 141.255.255.255
organisation: Administered by RIPE NCC
status:   LEGACY

% This is the RIPE Database query service.

inetnum:141.209.0.0 - 141.225.255.255
netname:NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK
descr:  IPv4 address block not managed by the RIPE NCC

remarks:You can find the whois server to query, or the
remarks:IANA registry to query on this web page:
remarks:http://www.iana.org/assignments/ipv4-address-space
remarks:
remarks:You can access databases of other RIRs at:

(It then unhelpfully lists all the other RIRs.)

Actually RIPE is even worse than APNIC because it implicitly has a
referral loop between IANA and RIPE.


BUT NOTE!

The APNIC and RIPE databases do in fact contain the referral information -
you can get it via RDAP but not whois. Repeating the examples,

$ curl -i https://rdap.apnic.net/ip/150.199.0.0
HTTP/1.1 301 Moved Permanently
Location: https://rdap.arin.net/registry/ip/150.199.0.0

$ curl -i https://rdap.db.ripe.net/ip/141.211.0.0
HTTP/1.1 301 Moved Permanently
Location: https://rdap.arin.net/registry/ip/141.211.0.0


Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Biscay: Cyclonic becoming mainly northwest, 4 or 5. Moderate. Fog patches,
thundery showers. Moderate, occasionally very poor.

Re: NIST NTP servers

[Tony Finch]

Jean-Francois Mezei  wrote:
>
> Today, if someone were to jam the GPS signal in an areas in USA, you'd
> likely hear about large number of car accidents in the news before
> noticing your systems canMt get time from the GPS-NTP and went to a
> backup ip address (nist etc).

The USA and the UK governments regularly perform GPS jamming tests, but
they do so in remote areas. See
http://www.navcen.uscg.gov/?pageName=gpsServiceInterruptions
http://stakeholders.ofcom.org.uk/spectrum/gps-jamming-exercises/
(Dunno if other governments have similar exercises.)

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Lundy, Fastnet, Irish Sea, South Shannon: Northerly or northeasterly 4 or 5,
occasionally 6 except in south Shannon. Slight or moderate. Mainly fair. Good,
occasionally poor at first in south Lundy.

Re: Latency, TCP ACKs and upload needs

[Tony Finch]

Leo Bicknell  wrote:
>
> 1460 byte payloads down, maybe 64 byte acks on the return, and with SACK
> which is widely deployed an ACK every 2-4 packets.  You would see about
> 2,140 packets/sec downstream (25Mbps/1460), and perhaps send 1070 ACKs
> back upstream, at 64 bytes each, or about 68Kbps.  Well under the 1Mbps
> upstream bandwidth.

Note that with delayed ACKs (RFC 1122) there is an ACK for every other
packet; SACK should do better than that.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Humber, Thames: Northwest, veering north or northeast, 4 or 5. Slight or
moderate. Fair. Good.

Re: Oh dear, we've all been made redundant...

[Tony Finch]

Warren Kumari  wrote:

> Found on Staple's website:
> http://www.staples.com/NetReset-Automated-Power-Cycler-for-Modems-and-Routers/product_1985686

http://thedailywtf.com/articles/ITAPPMONROBOT

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Viking, North Utsire: Northwesterly 5 to 7, decreasing 4 later. Moderate or
rough. Occasional rain. Moderate or good.

Re: finding whois servers, was .pro whois registry down?

[Tony Finch]

John Levine  wrote:
>
> I've set up .ws.sp.am (that's ws for Whois Server) which is
> updated every day from a variety of sources so it's pretty accurate.
> It's had the right server for pro.ws.sp.am all along.

It would be extra super helpful if every entry were a wildcard, so you
could look up (say) example.com.ws.sp.am and get a CNAME for the right
whois server. The reason for this is that the relevant whois server is not
always keyed off just the TLD, and sometimes the TLD doesn't provide a
referral. A particular case I know of is ac.uk vs. uk. You could have

*.uk.ws.sp.am.CNAME whois.nic.uk.
*.ac.uk.ws.sp.am. CNAME whois.ja.net.

Then I could look up cambridge.ac.uk.ws.sp.am and
cambridge.net.uk.ws.sp.am and get the right pointer in each case with a
single DNS lookup.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Southeast Fitzroy: Northerly 5 or 6, becoming variable 4 in north and west.
Rough becoming moderate later. Mainly fair. Good.

Re: FW: [tld-admin-poc] Fwd: Re: .pro whois registry down?

[Tony Finch]

Mark Andrews  wrote:
>
> Additionally 'whois' is free form text.  Whois doesn't include a
> AI to workout what this free form text means so, no, there isn't a
> actual referral for a whois application to use.

Yes, the whois data format is bullshit, but there are only a few simple
referral patterns in use, so in practice following referrals works OK.

> Additionally we should be publishing where the whois server for the
> tld is in the DNS.

>   _whois._tcp.pro. srv 0 100 43 whois.afilias.net.

That would be nice, but in practice the requirement is a whois.nic.TLD
host rather than a SRV record. And we don't really need yet another way
to find whois servers - we already have more than enough.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Humber, Thames: East or southeast 3 or 4. Slight. Mainly fair. Moderate or
good.

Re: .pro whois registry down?

[Tony Finch]

Doug Barton  wrote:

> On 03/09/2016 01:24 PM, Bryan Holloway wrote:
> > Anyone else noticing that the .pro TLD is failing for some things, and
> > their WHOIS registry appears to be unavailable?
>
> The address records for whois.dotproregistry.net are missing.

Well, it depends how you find the .pro whois servers, and I am pleased
that my recent changes to FreeBSD whois handle this case OK.

If you use pro.whois-servers.net aka whois.registrypro.pro the connection
times out. (It is sad that the often excellent whois-servers.net doesn't
work as well as it used to.)

If you use whois.nic.pro then it works. (This is the standard name
required for new gTLDs.)

If you follow the referral from whois.iana.org to whois.afilias.net then
it works.

More on whois at http://fanf.livejournal.com/140505.html

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
East Dogger, Fisher, German Bight: Southeasterly 4 or 5. Slight or moderate.
Fog patches for a time. Moderate or good, occasionally very poor.

Re: Binge On! - get your umbrellas out, stuff's hitting the fan.

[Tony Finch]

Alan Buxey  wrote:
>
> Bulk data and background update processes are things that could possibly
> by throttled - after all, that's pretty much what QoS does.  Most of my
> phone data is google play software updates and on woes phone ios and
> itunes store updates - it doesn't matter if the update ticks along in
> the background. Audio and video need to be good.

If throttling makes the data transfer take longer then it will hurt
battery life.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Biscay, Fitzroy: West veering northwest, gale 8 to storm 10, decreasing 5 to
7. Very rough or high, becoming rough or very rough. Showers, thundery at
first. Good, occasionally poor.

RE: Nat

[Tony Finch]

Alan Buxey  wrote:

> Most people don't need the devices to talk to each other

A lot of home networking uses mDNS - partitioning off devices will break
things like printing and chromecast and using your phone as a remote
control for your media players, etc. ad nauseam.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Northwest Fitzroy, Sole, Lundy, Fastnet, Irish Sea, Shannon: Mainly
southwesterly 6 to gale 8, occasionally severe gale 9. Rough or very rough,
becoming very rough or high, except in Irish Sea. Occasional rain. Moderate or
poor, occasionally good.

Re: John McAfee: Massive DDoS attack on the internet was from smartphone botnet on popular app

[Tony Finch]

Jim Shankland  wrote:

> Also, this jumped out at me:
>
> "The problem with the recent attack is that the originating IP addresses were
> evenly distributed within the IPV4 universe," McAfee says. "This is virtually
> impossible using spoofing."
>
> Am I missing something, or is an even distribution of originating IP addresses
> virtually impossible *without* using spoofing?

You are correct and McAfee is confused.

http://root-servers.org/news/events-of-20151130.txt

   DNS root name servers that use IP anycast observed this
   traffic at a significant number of anycast sites.

This implies that the botnet was widely distributed.

   The source addresses of these particular queries appear to be
   randomized and distributed throughout the IPv4 address space.

This says the attackers also used spoofing.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Rockall, Malin, Hebrides, Bailey: East 5 to 7, occasionally gale 8 in Rockall.
Moderate or rough, occasionally very rough in Rockall. Occasional rain. Good,
occasionally poor.

Re: bad announcement taxonomy

[Tony Finch]

Randy Bush  wrote:
>
> leak - i receive P and send it on to folk to whom i should not send
>it for business reasons (transit, peer, ...)
>
> 7007 - i receive P (or some sub/superset), process it in some way
>(likely through my igp), and re-originate it, or part of it,
>as my own
>
> we need a name for 7007 other then vinnie

Laundered leak?

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
German Bight, Humber, Thames, Dover: West or northwest, backing southwest for
a time, 6 to gale 8, increasing severe gale 9 at times, perhaps storm 10 later
in German Bight and Humber. Rough or very rough, occasionally high later in
German Bight and Humber. Rain at times. Good, occasionally poor.

Re: DNSSEC and ISPs faking DNS responses

[Tony Finch]

Owen DeLong  wrote:

> Again, if you’re the only resolver the clients are using, you can claim that
> nothing from the root down is signed without ever providing any cryptographic
> anything.

If the client is validating it will know the root is signed and the ISP
resolver will not be able to strip signature without breaking validation.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Thames, Dover, Wight, Portland: Southwest 6 to gale 8, decreasing 5 for a
time, perhaps severe gale 9 later. Moderate or rough, occasionally very rough
later. Rain at times. Moderate or good, occasionally poor.

RE: DNSSEC and ISPs faking DNS responses

[Tony Finch]

eric-l...@truenet.com  wrote:

> Actually, how are other places implementing these lists?  I would have
> thought to use RPZ, but as far as I know if the blocked DNS domain is
> using DNSSEC it wouldn't work.

You can configure RPZ with the "break-dnssec" option which means
validating clients will fail to resolve the blocked domains.

DNSSEC only protects you from getting bad answers. If someone wants you to
get no answers at all then DNSSEC cannot help.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Tyne, Dogger, Fisher: Southwest 6 to gale 8, occasionally severe gale 9 at
first. Rough or very rough, becoming mainly moderate in Tyne. Rain or showers.
Good, occasionally poor.

Re: DNSSEC broken for login.microsoftonline.com

[Tony Finch]

Bruce Curtis  wrote:

>   Drill run on one of our name servers shows that the error is
>
>   Existence denied: microsoftonline.com

No, drill just says there are no DS records which means the domain is
insecure so any problems with it should be unrelated to DNSSEC.

> [T] Existence denied: microsoftonline.com. DS
> ;; No ds record for delegation
> ;; Domain: microsoftonline.com.
> ;; No DNSKEY record found for microsoftonline.com.
> ;; No DS for login.microsoftonline.com.;; No ds record for delegation
> ;; Domain: login.microsoftonline.com.
> ;; No DNSKEY record found for login.microsoftonline.com.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
North Utsire: Variable 4, but southeasterly 5 to 7 in southwest, perhaps gale
8 later in far southwest. Rough in southwest, otherwise slight or moderate.
Fair. Good.

Re: DNSSEC broken for login.microsoftonline.com

[Tony Finch]

Bruce Curtis  wrote:
>
> FYI our DNS requests to resolve login.microsoftonline.com are failing
> because of a DNSSEC error.

There's no DS record for microsoftonline.com so you shouldn't have any
DNSSEC problems with it - my servers can resolve it OK. DNSvis doesn't
show any problems. The only thing which might cause trouble is the
SERVFAIL responses to DNSKEY queries flagged by the Verisign DNSSEC
debugger.

> http://dnssec-debugger.verisignlabs.com/login.microsoftonline.com
>
> http://dnsviz.net/d/login.microsoftonline.com/dnssec/

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Fitzroy, Sole: Cyclonic, mainly southwesterly, 5 to 7, occasionally gale 8 in
west Fitzroy. Very rough or high, becoming rough in Sole. Rain or thundery
showers. Moderate or poor, occasionally good.

Re: ARIN Region IPv4 Free Pool Reaches Zero

[Tony Finch]

valdis.kletni...@vt.edu  wrote:
>
> I wonder if a sudden exodus of customers whose iOS app got axed
> because it can't contact an aws-hosted server from an IPv6-only
> network will be enough to get their attention

Maybe they'll just proxy via CloudFlare to AWS.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or
moderate, but rough in southwest Viking. Showers later. Good, occasionally
poor later.

Re: outlook.com outgoing blacklists?

[Tony Finch]

Todd K Grand  wrote:

> Interesting, however those ipv6 addresses were dropped from our dns
> almost 2 weeks ago. No quad A records should exist anylonger, as it has
> been more than 48 hours.

You need to update the glue in your delegation.

; <<>> DiG 9.11.0pre-alpha <<>> +norec qkstream.com @a.gtld-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17274
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 6

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;qkstream.com.  IN  A

;; AUTHORITY SECTION:
qkstream.com.   172800  IN  NS  ns1.quickwisp.com.
qkstream.com.   172800  IN  NS  ns2.quickwisp.com.
qkstream.com.   172800  IN  NS  ns3.quickwisp.com.

;; ADDITIONAL SECTION:
ns1.quickwisp.com.  172800  IN  2001:470:b:4bb::25
ns1.quickwisp.com.  172800  IN  A   206.220.196.115
ns2.quickwisp.com.  172800  IN  2001:470:b:4bb::22
ns2.quickwisp.com.  172800  IN  A   206.220.193.189
ns3.quickwisp.com.  172800  IN  A   66.171.143.250

;; Query time: 14 msec
;; SERVER: 2001:503:a83e::2:30#53(2001:503:a83e::2:30)
;; WHEN: Thu Sep 10 15:56:31 BST 2015
;; MSG SIZE  rcvd: 209

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or
moderate, but rough in southwest Viking. Showers later. Good, occasionally
poor later.

Re: outlook.com outgoing blacklists?

[Tony Finch]

Todd K Grand  wrote:

> Content-Type: message/delivery-status
>
> Reporting-MTA: dns;COL004-OMC2S2.hotmail.com
> Received-From-MTA: dns;COL129-W41
> Arrival-Date: Wed, 9 Sep 2015 02:13:28 -0700
>
> Final-Recipient: rfc822;supp...@qkstream.com
> Action: failed
> Status: 5.5.0
> Diagnostic-Code: smtp;554 The mail could not be delivered to the recipient 
> because the domain is not reachable. Please check the domain and try again 
> (-744508417:308:-2147467259)

Looks like there are some IPv6 and TCP problems with the DNS

http://dnsviz.net/d/qkstream.com/dnssec/

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or
moderate, but rough in southwest Viking. Showers later. Good, occasionally
poor later.

Re: Dual stack IPv6 for IPv4 depletion

[Tony Finch]

Ricky Beam jfb...@gmail.com wrote:

 Talking about IPv6, we aren't carving a limit in granite. 99.9% of home
 networks currently have no need for multiple networks, and thus, don't ask for
 anything more; they get a single /64 prefix.

Personal-area networks already exist. Phone/watch/laptop etc.

Virtual machines are common, e.g. for running multiple different operating
systems on your computer.

And automotive networks need connectivity.

There are often separate VLANs for VOIP and IP TV and smart meters.

Separate wifi networks tuned for low-latency synchronized audio.

So it's very common to have multiple networks in a home with multiple
layers of routing.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Shannon, Rockall: South or southeast 5 or 6, increasing 6 or 7 later.
Moderate, occasionally rough. Rain, fog patches. Moderate, occasionally very
poor.

RE: Dual stack IPv6 for IPv4 depletion

[Tony Finch]

Matthew Huff mh...@ox.com wrote:

 When I see a car that needs a /56 subnet then I’ll take your use case
 seriously.

Cars need partitions between their automotive network, their entertainment
network, and their passenger wifi.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Southeast Fitzroy: Northeasterly becoming cyclonic 5 to 7, occasionally gale 8
at first. Moderate or rough. Fair. Moderate or good.

Re: REMINDER: LEAP SECOND

[Tony Finch]

Damian Menscher via NANOG nanog@nanog.org wrote:

 http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html
 comes dangerously close to your modest proposal.

Also
http://developerblog.redhat.com/2015/06/01/five-different-ways-handle-leap-seconds-ntp/

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Southwest Viking: Northwesterly 3 or 4, veering southeasterly 4 or 5 later.
Slight or moderate. Fair. Good.

Re: REMINDER: LEAP SECOND

[Tony Finch]

Philip Homburg pch-na...@u-1.phicoh.com wrote:

 For UTC the analog approach would be to keep time in TAI internally and
 convert to UTC when required.

This is much less of a solution than you might hope, because most APIs,
protocols, and data formats require UT. (Usually not UTC but a
representation isomorphic to traditional UT which ignores leap seconds.)

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Trafalgar: Variable 3 or 4, but northwesterly 4 or 5 in southeast. Slight,
occasionally moderate. Mainly fair. Mainly good.

Re: REMINDER: LEAP SECOND

[Tony Finch]

Harlan Stenn st...@ntp.org wrote:

 It's a problem with POSIX, not UTC.

 UTC is monotonic.

The problems are that UTC is unpredictable, and it breaks the standard
labelling of points in time that was used for hundreds (arguably
thousands) of years before 1972.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Irish Sea: Northwesterly 4 or 5, occasionally 6 at first, becoming variable 4.
Slight or moderate. Mainly fair. Good.

Re: REMINDER: LEAP SECOND

[Tony Finch]

Stephane Bortzmeyer bortzme...@nic.fr wrote:

 That's because the earth rotation is unpredictable. Any time based on
 this buggy planet's movements will be unpredictable. Let's patch it
 now!

http://mm.icann.org/pipermail/tz/2015-May/022280.html
http://mm.icann.org/pipermail/tz/2015-May/022281.html
http://mm.icann.org/pipermail/tz/2015-May/022282.html

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Northwest Faeroes, Southeast Iceland: Northeasterly 3 or 4. Moderate, becoming
mainly slight. Mainly fair. Good, occasionally poor in Southeast Iceland.

Re: REMINDER: LEAP SECOND

[Tony Finch]

shawn wilson ag4ve...@gmail.com wrote:
 So, what we should do is make clocks move. 9 slower half of the year
 (and then speed back up) so that we're really in line with earth's
 rotational time.

That's how UTC worked in the 1960s.
ftp://maia.usno.navy.mil/ser7/tai-utc.dat

It causes problems for systems that have a tight coupling between time
and frequency - broadcast, cellular, etc.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Fair Isle, Southeast Faeroes: Northeasterly 5 or 6 backing northerly 4 or 5.
Moderate, occasionally rough at first. Mainly fair. Good.

Re: Anycast provider for SMTP?

[Tony Finch]

James Hartig fastest...@gmail.com wrote:

 Just curious, how does DNS load balancing work if people are using
 8.8.8.8/208.67.222.222 or basically any public resolvers that cache and
 have a significant (relatively speaking) user-base?

http://www.afasterinternet.com/ietfdraft.htm

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Fisher, German Bight: Northwest 4 or 5, increasing 6 at times. Slight or
moderate. Showers. Good, occasionally moderate.

Re: DNS Lookup - Filter localhost

[Tony Finch]

Radke, Justin jra...@canbytel.com wrote:

 2. Do you have an actual localhost zone that issues 127.0.0.1?

Yes. I think this is best practice though it isn't required by RFC 6303
and isn't set up by default in BIND like the empty reverse DNS zones.

 3. Do you block 512 Bytes DNS requests?

512 byte requests are unlikely to be valid. Blocking 512 byte answers
breaks the DNS.

 4. Do you block non-UDP DNS requests or rate-limit requests?

Blocking TCP requests breaks the DNS. See RFC 5966.

 5. Anything else you block/filter on your DNS servers?

Have a look at these slides, especially the last 12 on mitigating abuse of
recursive servers.

http://www.isc.org/wp-content/uploads/2014/11/DNS-RRL-LISA14.pdf

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Northeast Viking, North Utsire: Southeasterly becoming variable, 3 or 4.
Slight or moderate. Showers. Good.

Re: Bare TLD resolutions

[Tony Finch]

David Conrad d...@virtualized.org wrote:

 To be clear, generic TLDs (gTLDs) can’t have bare (dotless) TLDs (or 
 wildcards).

Wildcards are being used for the name collision gubbins.

;  DiG 9.11.0pre-alpha  *.prod
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 51904
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;*.prod.IN  A

;; ANSWER SECTION:
*.prod. 3600IN  A   127.0.53.53

;; Query time: 66 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Sep 19 10:00:30 BST 2014
;; MSG SIZE  rcvd: 51

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly
5 or 6. Slight or moderate. Showers in northwest. Good.

Re: Anyone running Knot?

[Tony Finch]

RIPE have an interesting setup. They are load-balancing their name servers
across BIND, NSD, and Knot.

$ for i in `seq 10`; do
dig +norec +noall +answer version.bind ch txt @ns.ripe.net.;
  done | sort -u
version.bind.   0   CH  TXT 9.9.5
version.bind.   0   CH  TXT Knot DNS 1.5.0
version.bind.   0   CH  TXT NSD 4.0.4

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
South-east Iceland: Easterly or northeasterly 5 to 7, occasionally gale 8 in
northwest, veering southeasterly 4 in south. Slight or moderate, occasionally
rough in northwest. Rain or showers. Moderate or poor, occasionally good.

Re: TCP Window Scaling issue

[Tony Finch]

Zach Hill zach.reb...@gmail.com wrote:

 What's interesting is this is only affecting a single server and only
 when traffic is going over the WAN circuit. Testing from Server A to any
 server on it's network shows it is negotiating window scaling just fine.

Check your firewall isn't buggering about with TCP options.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
South German Bight, East Humber: Northeasterly 4 or 5. Slight, occasionally
moderate. Mainly fair. Moderate or good.

Re: Owning a name

[Tony Finch]

John Levine jo...@iecc.com wrote:

 The US has a long policy of not messing with ccTLDs, even of countries
 that we don't like such as .kp, .cu, and .iq (back in the day).

The latter had a fairly messy history:

http://www.iana.org/reports/2005/iq-report-05aug2005.pdf

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Irish Sea: East backing northeast 4 or 5. Slight or moderate. Rain or showers.
Moderate or good.

Re: IPv6 isn't SMTP

[Tony Finch]

John Levine jo...@iecc.com wrote:

 There are also some odd things in the spec.  For example, according to
 RFC 5321 this is not a syntactically valid e-mail address:

 mailbox@[IPv6:2001:12:34:56::78:ab:cd]

You aren't allowed to use :: to abbreviate one zero hexadectet according
to RFC 5952.

http://www.rfc-editor.org/errata_search.php?eid=2467

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Malin: East 5 or 6. Moderate or rough, occasionally very rough in northwest.
Showers. Good, occasionally moderate.

Re: IPv6 isn't SMTP

[Tony Finch]

Owen DeLong o...@delong.com wrote:

 Two errors, actually… As an RFC-821 address, it should be user@[IP]:port
 in both cases (user@[192.0.2.1]:25 and user@[2001:db8::1]:25).

You have never been able to specify a port number in an email address.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Lundy, Fastnet: East or northeast 4 or 5, occasionally 6 later. Moderate
becoming rough in south. Thundery showers. Good, occasionally poor.

Re: why IPv6 isn't ready for prime time, SMTP edition

[Tony Finch]

Laszlo Hanyecz las...@heliacal.net wrote:

 The usefulness of reverse DNS in IPv6 is dubious.

For most systems yes, but you might as well have it if you are manually
allocating server addresses.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Faeroes: Variable 4, becoming southeast 5 or 6. Moderate or rough. Fair. Good.

Re: misunderstanding scale, SMTP edition

[Tony Finch]

John Levine jo...@iecc.com wrote:

 If I were a spammer or an ESP who wanted to listwash, I could easily use
 a different IP addres for every single message I sent.

Until mail servers start rate-limiting the number of different addresses
that are used :-) You can do something like the following in Exim, which
limits IPv6 senders to 16 addresses per /64 per day.

  defer
hosts = ; 2000::/4
ratelimit = 16 / 1d / per_conn /\
  unique=$sender_host_address /\
  ${mask:$sender_host_address/64}

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Shannon, Rockall: Southerly 5 or 6 at first in west, otherwise variable 3 or
4, becoming northeasterly 4 or 5. Moderate or rough. Showers. Good,
occasionally moderate.

Re: why IPv6 isn't ready for prime time, SMTP edition

[Tony Finch]

Lamar Owen lo...@pari.edu wrote:

 the typical ISP has the technical capability to bill based on volume of
 traffic already, and could easily bill per-byte for any traffic with
 'e-mail properties' like being on certain ports or having certain
 characteristics.

Who do I send the bill to for mail traffic from 41.0.0.0/8 ?

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Lundy, Fastnet, Irish Sea: Northwest veering east 4 or 5, occasionally 6 later
in Irish Sea. Moderate or rough. Showers. Good, occasionally moderate.

Re: why IPv6 isn't ready for prime time, SMTP edition

[Tony Finch]

Lamar Owen lo...@pari.edu wrote:

 The entity with whom they already have a business relationship. Basically, if
 I'm an ISP I would bill each of my customers, with whom I already have a
 business relationship, for e-mail traffic.  Do this as close to the edge as
 possible.

Ooh, excellent, so I can deliver loads of spam to them and charge them for it!

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Biscay: Northwest 4 or 5, becoming variable 4. Moderate or rough. Rain or
showers. Good, occasionally moderate.

Re: why IPv6 isn't ready for prime time, SMTP edition

[Tony Finch]

Lamar Owen lo...@pari.edu wrote:
 On 03/26/2014 01:38 PM, Tony Finch wrote:
  Who do I send the bill to for mail traffic from 41.0.0.0/8 ? Tony.

 You don't.  Their upstream(s) in South Africa would bill them for outgoing
 e-mail.

You mean Nigeria. So how do I get compensated for dealing with the junk
they send me?

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://dotat.at/
Thames, Dover, Wight, Portland, Plymouth: North 4 or 5, becoming variable 3 or
4, then east 4 or 5 later. Slight or moderate, but rough in southwest
Plymouth. Rain or showers. Good, occasionally moderate.

Re: trivial changes to DNS (was: OpenNTPProject.org)

[Tony Finch]

Jared Mauch ja...@puck.nether.net wrote:

   I can point anyone interested to the place in the
 bind source to force it to reply to all UDP queries with TC=1
 to force TCP.  should be safe on any authority servers, as a recursive
 server should be able to do outbound TCP.

However see http://www.potaroo.net/ispcol/2013-09/dnstcp.html

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: OpenNTPProject.org

[Tony Finch]

Jared Mauch ja...@puck.nether.net wrote:

 3) You want to upgrade NTP, or adjust your ntp.conf to include ‘limited’
 or ‘restrict’ lines or both.  (I defer to someone else to be an expert
 in this area, but am willing to learn :) )

There is useful guidance for Cisco, Juniper, and Unix here:

https://www.team-cymru.org/ReadingRoom/Templates/secure-ntp-template.html

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: Best practice on TCP replies for ANY queries

[Tony Finch]

Anurag Bhatia m...@anuragbhatia.com wrote:

 Now I see presence of some (legitimate) DNS forwarders and hence I don't
 wish to limit queries.

You are going to have to change your mind about this one. Open recursive
resolvers are a really bad idea, unless you can afford a lot of time and
cleverness to manage the abuse. Get your users to choose a more
appropriate name server, and restrict your name server to your local
networks.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: IP Fragmentation - Not reliable over the Internet?

[Tony Finch]

Christopher Palmer christopher.pal...@microsoft.com wrote:

 What is the probability that a random path between two Internet hosts
 will traverse a middlebox that drops or otherwise barfs on fragmented
 IPv4 packets?

This question is important for large EDNS packets so you'll find some
recent practical investigations from the perspective of people interested
in DNSSEC. For instance, a couple of presentations from Roland van
Rijswijk:

https://ripe64.ripe.net/presentations/91-20120418_-_RIPE64_-_Ljubljana_-_DNSSEC_-_UDP_issues.pdf
http://toronto45.icann.org/meetings/toronto2012/presentation-dnssec-fragmentation-17oct12-en.pdf

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: Google's QUIC

[Tony Finch]

Reminds me of MinimaLT: http://cr.yp.to/tcpip/minimalt-20130522.pdf

Tony.
--
f.anthony.n.finch  d...@dotat.at  http://dotat.at/

Re: Google Public DNS Problems?

[Tony Finch]

Blair Trosper blair.tros...@gmail.com wrote:

 Goes all the way up to the A root server before failing spectacularly.

That is an extremely weird response. Are you sure your queries are not
being intercepted by a middlebox? What happens if you use dig +vc ?
Do you get a similar round-trip time when pinging 8.8.8.8 to the one
reported by dig?

 Europa:~ blair$ dig +cd @8.8.8.8 google.com A

 ;  DiG 9.8.3-P1  +cd @8.8.8.8 google.com A
 ; (1 server found)
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 47332
 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

 ;; QUESTION SECTION:
 ;google.com. IN A

 ;; AUTHORITY SECTION:
 . 467 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2013050100 1800 900 
 604800 86400

 ;; Query time: 46 msec
 ;; SERVER: 8.8.8.8#53(8.8.8.8)
 ;; WHEN: Wed May  1 10:05:46 2013
 ;; MSG SIZE  rcvd: 104

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: What do people use public suffix for?

[Tony Finch]

Joe Abley jab...@hopcount.ca wrote:

 If the rule was just the nameservers need to be the same and the SOA
 RDATA needs to be the same, for some well-documented meaning of 'same'
 then gaming that rule (e.g. for purposes of cookie injection) as a
 miscreant is unpleasantly straightforward.

To reinforce Joe's point, there doesn't even need to be a zone cut for
there to be an administrative cut. There are various ISPs and dynamic DNS
providers that put all their users in the same zone, and the common suffix
of a zone like this should be treated as public suffix even though there
is no zone cut.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: ICMP Redirect on Resolvers

[Tony Finch]

On 6 Apr 2013, at 06:36, Shahab Vahabzadeh sh.vahabza...@gmail.com wrote:

 I have two DNS Server (resolver) running on FreeBSD 9.0, I always see in
 console messages like this:
 
 icmp redirect from 192.168.140.36: 192.168.179.80 = 192.168.140.254

You probably configured the wrong default router address or netmask.

Tony.
--
f.anthony.n.finch  d...@dotat.at  http://dotat.at/

Re: Open Resolver Problems

[Tony Finch]

On 1 Apr 2013, at 14:44, Jared Mauch ja...@puck.nether.net wrote:
 On Mar 31, 2013, at 11:16 PM, valdis.kletni...@vt.edu wrote:
 
 Anybody who is looking at this as an IPv4 issue is woefully misinformed
 about the nature of the problem.
 
 :)
 
 IPv4 it's easy to collect an inventory (the math works).  IPv6, not nearly as 
 easy.

You should be able to get a reasonable sample of IPv6 resolvers from the query 
logs of a popular authoritative server.

Tony.
--
f.anthony.n.finch  d...@dotat.at  http://dotat.at/

Re: Open Resolver Problems

[Tony Finch]

Joe Abley jab...@hopcount.ca wrote:

 My assessment is that the implementations I have seen are ready for
 production use, but I think it's understandable given the moving
 goalpoasts that some vendors have not yet promoted the code to be
 included in stable releases.

It is in the current stable release of NSD 3.2.15 though it is a
build-time option. It is in the current release candidate of knot DNS
1.2.0-rc4. It will be in BIND-9.10 which has not yet reached public beta.

Our servers have been abused as reflectors, and we're using the BIND RRL
patch with versions 9.8 and 9.9 to stop the attack traffic.

There are other interim options such as using firewall rate limiting
which is worse than RRL because it is much more likely to hurt legitimate
queries. For example,
http://www.bortzmeyer.org/rate-limiting-dns-open-resolver.html

Or you can use a configuration add-on such as bindguard.
http://bindguard.activezone.de

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: Open Resolver Problems

[Tony Finch]

Jack Bates jba...@brightok.net wrote:

 Tracking the clients would be a huge dataset and be especially complicated in
 clusters.

The memory usage is guite manageable: for the BIND patch it is at most
40-80 bytes (for 32 or 64 bit machines) per request per second. You're
doing well if you need a megabyte. There's no need to get complicated with
clusters: it's enough of an improvement just to track rates per server.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: Open Resolver Problems

[Tony Finch]

Jack Bates jba...@brightok.net wrote:

 You'll also find that [DNS RRL] serves little purpose.

In my experience it works extremely well. Yes it is possible to work
around it, but you still need to stop the attacks that are happening now.
It is good to make the attacker's job harder.

 1) tcp

RRL pushes legitimate clients to TCP if they get muddled up with attack
traffic.

 2) require all requests to pad out to maximum response

I expect that is as easy to deploy as BCP38, IPv6, and DNSSEC.

 3) BCP38 (in spirit)

That should be deployed as well as RRL.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: Open Resolver Problems

[Tony Finch]

Jack Bates jba...@brightok.net wrote:

 If BCP38 was properly deployed, what would be the purpose of RRL outside of
 misbehaving clients or direct attacks against that one server?

If fictional scenario, irrelevant answer. Given the current situation,
efforts to deploy both RRL and BCP38 in parallel will reduce the mess we
are in. Let's race to see who gets to full deployment first.

 The infrastructure to switch it to TCP is prohibitive and completely
 destroys the anycast mechanisms.

Yeah, anycast for HTTP doesn't work at all. Just ask CloudFlare.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: Google's Public DNS does DNSSEC validation

[Tony Finch]

Mick O'Rourke mkorourke+na...@gmail.com wrote:

 In the potentially interestingly and perhaps not so positive - one of the
 common EDNS tests via Google pub DNS fails.

Google Public DNS's upstream behaviour is different depending on
whether its client demonstrate knowledge of DNSSEC:

Large EDNS buffer size with client DNSSEC:

$ dig +dnssec +short rs.dns-oarc.net. txt @8.8.8.8
rst.x1185.rs.dns-oarc.net.
rst.x1187.x1185.rs.dns-oarc.net.
rst.x1193.x1187.x1185.rs.dns-oarc.net.
74.125.18.151 DNS reply size limit is at least 1193
74.125.18.151 sent EDNS buffer size 1232
Tested at 2013-01-30 14:51:49 UTC

No EDNS without client DNSSEC:

$ dig +short rs.dns-oarc.net. txt @8.8.8.8
rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
74.125.17.217 DNS reply size limit is at least 490
74.125.17.217 lacks EDNS, defaults to 512
Tested at 2013-01-30 14:52:51 UTC

DNSSEC validation for DNSSEC clients:

$ dig +dnssec +noall +comments no-dnssec.dotat.at @8.8.8.8
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 54190
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512

Insecure DNS for other clients even if you set the AD flag to ask for it:

$ dig +adflag +noall +comments no-dnssec.dotat.at soa @8.8.8.8
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 54593
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: [SHAME] Spam Rats

[Tony Finch]

John Levine jo...@iecc.com wrote:

 *.4.4.3.0.5.a.0.0.8.b.d.0.1.0.0.2.ip6.arpa. PTR a.node.on.vlan344.namn.se.
 ...will work just fine, for instance.

 Since there is no  record for a.node.on.vlan344.namn.se., this
 won't work fine in any rDNS check I'm aware of.

I believe it's relatively common for mail servers to just check the
existence of a PTR record without any further sanity checking, e.g.
Postfix's reject_unknown_reverse_client_hostname smtpd_client_restrictions
option.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: why haven't ethernet connectors changed?

[Tony Finch]

Tom Morris bluen...@gmail.com wrote:

 Boy would I ever love an ethernet connector that works like Apple's
 MagSafe...

I guess a magsafe ethernet connector would have too much noise (owing to
poor quality connection) to provide decently high bandwidth.

This thread reminds me of http://fanf.livejournal.com/96172.html

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: why haven't ethernet connectors changed?

[Tony Finch]

Michael Thomas m...@mtcc.com wrote:

 I'd turn this back the other way though: in this day and age, why do we
 have any interconnection/bus that isn't just ethernet/IP?

The need for isochronous transmission and more bandwidth.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: btw, the itu imploded

[Tony Finch]

Bill Woodcock wo...@pch.net wrote:

 The main unfortunate outcome is that the ITU has managed to get Study
 Group 3 approved to try to figure out how to override peering agreements
 with government-imposed settlements.

Do you have any citations for that? I thought they had given up on trying
to interfere with Internet peering and settlement.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: btw, the itu imploded

[Tony Finch]

Nick Hilliard n...@foobar.org wrote:
 On 19/12/2012 14:25, Tony Finch wrote:
 
  Do you have any citations for that? I thought they had given up on trying
  to interfere with Internet peering and settlement.

 http://www.itu.int/net/ITU-T/lists/questions.aspx?Group=03Period=15

Looks vaguely ominous. Do they have a document which gives their
definition of international telecommunications services and NGNs?

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

RE: Dns sometimes fails using Google DNS / automatic dnssec

[Tony Finch]

Jay Ford jay-f...@uiowa.edu wrote:

 It looks like if the server has the RRSIG RR, it returns it.  For example, a
 query with +dnssec will cause it to cache the RRSIG, after which it returns
 it even if +dnssec not specified.

It's weird. If you repeatedly query 8.8.4.4 without the DO bit, you get a
mixture of responses with and without an RRSIG and with varying TTLs. With
DO it appears to consistently return an RRSIG in the answer and the TTL
drops monotonically. 8.8.8.8 is similar except DO=0 replies don't include
RRSIGs. (Querying from JANET UK and hitting some servers a lethargic 12ms
away.)

while sleep 1; do dig +dnssec @8.8.4.4 m1.mailplus.nl; done

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: hotmail.com live.com admin needed

[Tony Finch]

Suresh Ramasubramanian ops.li...@gmail.com wrote:

 authentication required is a bizzarre error to return.

It's fairly normal error from an Exchange server when the client is trying
to relay to a domain that the server doesn't host and when the server
doesn't allow the client to relay. Sounds like an internal
misconfiguration in this case.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: DNS hostnames with a duplicate CNAME and A record - which should be removed?

[Tony Finch]

Landon Stewart lstew...@superb.net wrote:

 The problem is that we have some zones that have records with the same
 hostname that have both a CNAME as well as an A record, MX record, SOA
 record and/or NS record.  Is there an easy answer for what should be
 removed?

You can never have a CNAME record at a zone apex, because a zone apex has
to have SOA and NS RRs and a CNAME can never coexist with other RRs. So
those cases are simple.

If the misconfigured CNAME is not at a zone apex then you have to decide
whether the CNAME or the other records are correct - do you get the right
result from the DNS when deleting one or the other? If it works either way
then your decision mainly depends on how frequently the target address
changes and if you need to make co-ordinated changes across many zones -
if so then a CNAME tends to be preferable. But you probably have to have a
workaround for A records at zone apexes in which case that tooling
probably removes CNAMEs' advantage and you might as well use A records
everywhere.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: Google opens Web Window on their Data Centers

[Tony Finch]

Tony Patti t...@swalter.com wrote:

 http://www.google.com/about/datacenters/gallery/#/

Also worth seeing is this article which explains how their hot aisles work:
http://www.datacenterknowledge.com/archives/2012/10/17/how-google-cools-its-armada-of-servers/
And this longer and fluffier piece in Wired:
http://www.wired.com/wiredenterprise/2012/10/ff-inside-google-data-center/all/

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: IPv4 address length technical design

[Tony Finch]

On 7 Oct 2012, at 18:17, William Herrin b...@herrin.us wrote:
 
 Intentionally crashing the moon into the earth is a new idea. How far
 should we run with it before concluding that it not only isn't a very
 good one, considering it hasn't taught us anything we didn't already
 know?

http://www.xent.com/FoRK-archive/july98/0041.html

Tony.
--
f.anthony.n.finch  d...@dotat.at  http://dotat.at/

Re: IPv4 address length technical design

[Tony Finch]

On 6 Oct 2012, at 02:11, Michael Thomas m...@mtcc.com wrote:
 
 Wasn't David Cheriton proposing something like this?
 
 http://www-dsg.stanford.edu/triad/

CCNx basically routes on URLs

http://conferences.sigcomm.org/co-next/2009/papers/Jacobson.pdf

Tony.
--
f.anthony.n.finch  d...@dotat.at  http://dotat.at/

Re: IPv4 address length technical design

[Tony Finch]

Owen DeLong o...@delong.com wrote:

 Once host identifiers are no longer dependent on or related to topology,
 there's no reason a reasonable fixed-length cannot suffice.

Host identities should be cryptographic hashes of public keys, so you have
to support algorithm agility, which probably implies variable length.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: IPv6 Address allocation best practises for sites.

[Tony Finch]

William Herrin b...@herrin.us wrote:

 but I also can't imagine hosting more than 65,000 sites on a single
 server.

Demon's homepages service was based on IPv4 virtual hosting and had IIRC a
/16 and two /18s allocated to it. It was a single web server with a few
reverse proxies that took most of the load and that also had all the IP
addresses. The Irix version used a cunning firewall configuration to
accept connections to all the addresses without stupid numbers of virtual
interfaces; the BSD version used a kernel hack.
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/12071

On the web server we stuffed the IP address into the filesystem path name
to find the document root. (Or used various evil hacks to map the IP
address to a canonical virtual server host name before stuffing the latter
in the path.)

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: Google / Gmail SSL write errors

[Tony Finch]

Paul Kelly :: Blacknight p...@blacknight.com wrote:

 Are any of you (that use Exim as their MTA) having SSL write errors in
 your exim logs when delivering e-mail to Gmail or Google addresses?

I suggest asking this question on the exim-users mailing list. Phil
Pennock has done a fair amount of work on TLS recently.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: Blocking MX query

[Tony Finch]

Ibrahim ibrah...@gmail.com wrote:

 We are thinking to block MX queries on our DNS server, so only spammer that
 use their own SMTP server will got affected. [...] Any best practice to
 block MX query?

Don't do this. It won't hinder spammers and it'll cause problems for legit
users.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: DNS caches that support partitioning ?

[Tony Finch]

Raymond Dijkxhoorn raym...@prolocation.net wrote:

 When you use forwarding it doesnt cache the entry. ('forward only'
 option in bind for example).

That's incorrect. Try configuring a forwarded zone and observe the TTLs
you get in responses. The forward only option disables recursion but
not cacheing.

 I talked with Paul Vixie about doing this internal inside bind but that was
 not something they would be delighted to do (at least not now). If you could
 define how large your cache pool was for certain objects that would fix it
 also.

You might be able to hack it using a combination of forwarding zones,
views, max-cache-ttl, and attach-cache.

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: Return two locations or low TTL [was: DNS caches that support partitioning ?]

[Tony Finch]

Patrick W. Gilmore patr...@ianai.net wrote:
 On Aug 20, 2012, at 08:47 , Chris Adams cmad...@hiwaay.net wrote:
 
  Most anything that supports IPv6 should handle this correctly, since
  getaddrinfo() will return a list of addresses to try.

 Ah, the amazing new call which destroys any possibility of randomness or
 round robin or other ways of load balancing between A /  records.
 Yes, all of us returning more than one A /  record are hoping that
 gets widely deployed instantly.  Or not.

The problem is RFC 3484 address selection; getaddrinfo is just the usual
place this is implemented. I had believed that there was work in progress
to fix this problem with the specs but it seems to have stalled.
http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-05

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.

Re: Return two locations or low TTL [was: DNS caches that support partitioning ?]

[Tony Finch]

Shumon Huque shu...@upenn.edu wrote:
 On 8/20/12 10:11 AM, Tony Finch wrote:
 
  The problem is RFC 3484 address selection; getaddrinfo is just the usual
  place this is implemented. I had believed that there was work in progress
  to fix this problem with the specs but it seems to have stalled.
  http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-05

 It's in the RFC editor queue actually:

 http://datatracker.ietf.org/doc/draft-ietf-6man-rfc3484bis/?include_text=1
 http://datatracker.ietf.org/doc/draft-ietf-6man-rfc3484bis/history/

Excellent :-)

Tony.
-- 
f.anthony.n.finch  d...@dotat.at  http://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.