Re: [dns-operations] DNS Operations

[Randy Bush]

> As I checked with ChatGPT

ROFL!
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] differ

[Randy Bush]

>> it occurred to me that it migh tme wise to have a rancid like
>> (https://shrubbery.net/rancid/) equivalent for critical domains.
>> i.e. to git record changes and warn of radical diffs.
>> 
>> is there any foss tooling in this space?
> 
> Assuming there isn't - yet...- What would you want a tool like this to
> do ? Would a simple diff (e.g.: number of deleted lines> X, assuming
> one is working with files) be too vague ? Would you want the
> granularity to be RRsets ?

at first blush, there are two classes of change that concern me.

one is for zones that should be quite stable.  for those, a full rancid
style diff, likely ignoring dnssec rrs.

for zones which normally have churn, some summarization would probably
be needed.

this week, i am more concerned with the first.  but, knowing the dns
community, i am sure this could become a small industry :)

does it trigger on cron?  or do i want to hook it into the update event,
either local/primary or successful axfr?  this week, either will do.

why reinvent rancid?  i use it and like it a lot.  but, as joe says,
it's perl; i.e. it will not be pleasant to augment.  occasionally i have
to touch one of the ancient perl bits around here, and ugh.

randy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] differ

[Randy Bush]

it occurred to me that it migh tme wise to have a rancid like
(https://shrubbery.net/rancid/) equivalent for critical domains.
i.e. to git record changes and warn of radical diffs.

is there any foss tooling in this space?

randy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] AL

[Randy Bush]

> Add +all to the request to see the rcode. 
> 
>> rip.psg.com runs secondary for AL.  but
>> 
>>rip.psg.com:/usr/home/dns# dig @194.1.149.230 al axfr
>> 
>>; <<>> DiG 9.18.16 <<>> @194.1.149.230 al axfr
>>; (1 server found)
>>;; global options: +cmd
>>; Transfer failed.
>> 
>> the contact in the SOA does not answer, nor does the dom...@akep.al, nor
>> does n...@akep.al as listed in iana root zone.

and that will help me contacting the relevant folk how?

randy

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] AL

[Randy Bush]

rip.psg.com runs secondary for AL.  but

rip.psg.com:/usr/home/dns# dig @194.1.149.230 al axfr

; <<>> DiG 9.18.16 <<>> @194.1.149.230 al axfr
; (1 server found)
;; global options: +cmd
; Transfer failed.

the contact in the SOA does not answer, nor does the dom...@akep.al, nor
does n...@akep.al as listed in iana root zone.

anyone with clues?

randy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Stale .GN and .LR zone data in some instances of "ns-{gn, lr}.afrinic.net"

[Randy Bush]

cc:s changed and a couple of bcc:s added

> Sadly, not yet, even yesterday the SOA serial on the problem instances was
> behind, and the RRSIGs are still 2-weeks expired.  It is beginning to look
> like Afrinic are diverting all queries from Google to a separate server
> pool, and it is *that* server pool that has stale data...
> 
> ; <<>> DiG 9.11.10 <<>> @196.216.168.49 soa gn. +nosplit +dnssec +cd +nsid
> +norecur +nocrypt
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25967
> ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 1232
> ; NSID: 73 30 31 2d 6e 73 32 2e 6a 69 6e 78 ("s01-ns2.jinx")
> ;; QUESTION SECTION:
> ;gn.IN  SOA
> 
> ;; ANSWER SECTION:
> gn. 3600IN  SOA rip.psg.com.
> hostmaster.psg.com. 2202015289 86400 3600 2592000 3600
> gn. 3600IN  RRSIG   SOA 8 1 3600 20220818095230
> 20220803224100 53103 gn. [omitted]
> 
> ;; AUTHORITY SECTION:
> gn. 14400   IN  NS  rip.psg.com.
> gn. 14400   IN  NS  fork.sth.dnsnode.net.
> gn. 14400   IN  NS  ns-gn.afrinic.net.
> gn.     14400   IN  RRSIG   NS 8 1 14400 20220816200031
> 20220803023758 53103 gn. [omitted]
> 
> On Mon, 29 Aug 2022 at 23:22, Randy Bush  wrote:
> 
>>> The zone data for .GN and .LR has older SOA serial numbers and expired
>>> signatures on some of the anycast instances of ns-gn.afrinic.net and
>>> ns-lr.afrinic.net.  Specifically, at least the ones with NSID
>>> "s01-ns2.jinx".  This breaks resolution of .GN and .LR names via
>>> Google DNS from some locations. Please ensure that the zones are
>>> updated at all anycast locations.
>>
>> thanks viktor,
>>
>> i have bumped the zones at the primary.  let's see if afrinic servers
>> get the message.

thanks viktor

another day of no response from afrinic, and i guess i should ask the
iana to remove them from the NS RRset for GN and LR.

anyone have a way to get afrinic dns folk's attention?

randy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] BlackHat Presentation on DNSSEC Downgrade attack

[Randy Bush]

have you folk sufficiently damaged your academic reputations and public
images that we will not have to read more of this?

randy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Input from dns-operations on NCAP proposal

[Randy Bush]

> Do we have any idea how many systems still use search lists?

linux and freebsd installs encourage them
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] maybe a small tcp flood

[Randy Bush]

> Does your dnstop support TCP? The man page on my machine has the
> following mentioned under BUGS:
> 
> Does not support TCP at this time.

doh :(

randy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] maybe a small tcp flood

[Randy Bush]

thanks to clue from duane

Query Type Count  %   cum%
-- - -- --
A?735975   96.1   96.1
NS?109411.4   97.5
TXT?   108881.4   99.0
?   51200.7   99.6
MX?  8220.1   99.7
DS?  6420.1   99.8
PTR? 4360.1   99.9
DNSKEY?  4220.1   99.9
SOA? 1440.0  100.0
#257?1030.0  100.0
#65?  970.0  100.0

RcodeCount  %   cum%
 - -- --
Noerror2832782  100.0  100.0
Servfail200.0  100.0




___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] maybe a small tcp flood

[Randy Bush]

>> tcp query flood for cctlds and sec.cctlds, could be others
>> being sent via popular open servers: goog, neustar, ...
>> O(100)qps or higher
> 
> - What was the duration of the event (UTC time start and end)?

after a short break, it is ongoing


> - Any stats on the rtype(s)?


> - Any stats on the mix of qnames?
> * Repeated or distinct?
> * Extant, NODATA or NXDOMAIN?

i am just running dnstop from cli.  admit to need to spend time on
better tooling.  but hard to justify without some feeling that i would
be able to configure a significant defense given new data.  i have a
many decade history of just waiting for net idiots to go away.

> - Any stats on the upstream client distribution?

big dns resolvers: goog, yandex, ...  though today, it seems pretty
distributed

Sources  Count  %   cum%
 - -- --
184.80.47.40 311580.50.5
212.16.184.205   222610.30.8
112.198.115.36   184080.31.1
2001:fd8:220::4  179410.31.4
123.176.0.20 164810.21.6
212.77.192.101   149250.21.8
78.100.2.13  149130.22.1
59.18.54.69  146320.22.3
...

> To elicit TCP requests from the public DNS providers the queries would
> likely have to first elicit truncated UDP replies (DNSKEY RRset, signed
> denial of existence, ...).  Did you also observe the associated UDP
> traffic?

have not had the time to look.

randy___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] maybe a small tcp flood

[Randy Bush]

trying to understand what we are seeing, and assume other are seeing it
too.

tcp query flood for cctlds and sec.cctlds, could be others
being sent via popular open servers: goog, neustar, ...
O(100)qps or higher

randy

---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks to dmarc header butchery
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] cheap traffic measure for a small set of zones

[Randy Bush]

> is there a simple tool to run on a server to measure query and data
> rates for a small set of zones?
> 
> 

bingo!  thanks.

randy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] cheap traffic measure for a small set of zones

[Randy Bush]

is there a simple tool to run on a server to measure query and data
rates for a small set of zones?  i just want to run it for a day.

it is a a bind9 server which serves a few hundred zones.  i would like
to know the query rate and byte count for six of them.

randy

---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks to dmarc header butchery
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Monitoring for impending expiration of domains?

[Randy Bush]

you folk are sure making me appreciate the registrar i use

randy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Monitoring for impending expiration of domains?

[Randy Bush]

tangent, but you started it

> [1] IANAL, but this rather looks like a gross over-reaction to GDPR,
> with some registries and registrars continuing to provide usable
> contact details with no ill consequence.  The practice even among
> European ccTLDs varies rather widely.  It would sure be great if some
> sense returned to this space.

i find this extremely frustrating.  i realize that i am a dinosaur, but
i really want a usable response to a whois query.  compare

   whois psg.com

with

   whois -h whois.ripe.net 147.28.0.0

and the latter is in gdpr juristiction while the former is not.

randy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] DNS Flag Day 2020 will become effective on 2020-10-01

[Randy Bush]

> there are other things on the internet besides DNS

yes, bgp!  :)

see rfc 8654

randy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] DNS Flag Day 2020 will become effective on 2020-10-01

[Randy Bush]

> We should admit that actual Internet MTU is ~1500

sad but true

> PMTUD ... doesn’t work

sad but true

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

[Randy Bush]

> The speculation I've seen is that Cogent refuses to treat HE as a Tier1
> network in v6 because they don't try to also be one in v4

s/try to be/are not/

for cogent, v6 and v4 are parity

> but that they should because HE's v6 network is much wider reaching
> and much longer established than Cogent's.

and much longer tunnels and much breakage

> In any case, Cogent's refusal to peer with HE over v6 has been very
> public and well documented.  It makes Cogent unreachable from a
> significant portion of the v6 network.

for a value of 'significant' i do not see from any of my vantage points.

has this not gotten boring yet?

randy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

[Randy Bush]

>> Neither Cogent or HE buy transit from anybody else

i believe this statement to be false

randy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] .MW inconsistent zone updates?

[Randy Bush]

the occasional packet can get through

rip.psg.com:/root# ping 196.45.188.5
PING 196.45.188.5 (196.45.188.5): 56 data bytes
64 bytes from 196.45.188.5: icmp_seq=2 ttl=44 time=360.147 ms
64 bytes from 196.45.188.5: icmp_seq=55 ttl=44 time=377.265 ms
64 bytes from 196.45.188.5: icmp_seq=78 ttl=43 time=368.701 ms
64 bytes from 196.45.188.5: icmp_seq=82 ttl=43 time=369.133 ms
64 bytes from 196.45.188.5: icmp_seq=85 ttl=43 time=360.161 ms
64 bytes from 196.45.188.5: icmp_seq=91 ttl=44 time=359.521 ms
64 bytes from 196.45.188.5: icmp_seq=97 ttl=43 time=360.262 ms
64 bytes from 196.45.188.5: icmp_seq=99 ttl=44 time=360.025 ms
64 bytes from 196.45.188.5: icmp_seq=105 ttl=43 time=360.261 ms
64 bytes from 196.45.188.5: icmp_seq=108 ttl=44 time=358.269 ms
64 bytes from 196.45.188.5: icmp_seq=158 ttl=44 time=360.564 ms
^C
--- 196.45.188.5 ping statistics ---
164 packets transmitted, 11 packets received, 93.3% packet loss
round-trip min/avg/max/stddev = 358.269/363.119/377.265/5.672 ms

rip.psg.com:/root# traceroute 196.45.188.5
traceroute to 196.45.188.5 (196.45.188.5), 64 hops max, 52 byte packets
 1  psg0 (147.28.0.4)  0.297 ms  0.228 ms  0.120 ms
 2  ge-100-0-0-15.r05.sttlwa01.us.bb.gin.ntt.net (165.254.106.17)  0.732 ms  
0.838 ms  0.614 ms
 3  be3048.ccr21.sea02.atlas.cogentco.com (154.54.11.9)  23.479 ms  22.984 ms  
23.227 ms
 4  be2085.ccr21.slc01.atlas.cogentco.com (154.54.2.198)  31.595 ms  31.877 ms  
31.835 ms
 5  be2126.ccr21.den01.atlas.cogentco.com (154.54.25.65)  42.463 ms
be2127.ccr22.den01.atlas.cogentco.com (154.54.25.69)  45.835 ms
be2126.ccr21.den01.atlas.cogentco.com (154.54.25.65)  42.331 ms
 6  be2128.ccr21.mci01.atlas.cogentco.com (154.54.25.174)  54.302 ms
be2130.ccr22.mci01.atlas.cogentco.com (154.54.26.122)  53.716 ms
be2128.ccr21.mci01.atlas.cogentco.com (154.54.25.174)  54.322 ms
 7  be2156.ccr41.ord01.atlas.cogentco.com (154.54.6.86)  65.782 ms
be2157.ccr42.ord01.atlas.cogentco.com (154.54.6.118)  66.233 ms
be2156.ccr41.ord01.atlas.cogentco.com (154.54.6.86)  65.815 ms
 8  be2351.ccr21.cle04.atlas.cogentco.com (154.54.44.86)  76.760 ms
be2185.ccr22.cle04.atlas.cogentco.com (154.54.43.178)  73.506 ms  74.382 ms
 9  be2482.ccr41.jfk02.atlas.cogentco.com (154.54.27.158)  89.064 ms
be2483.ccr42.jfk02.atlas.cogentco.com (154.54.29.202)  88.665 ms
be2482.ccr41.jfk02.atlas.cogentco.com (154.54.27.158)  89.158 ms
10  be2317.ccr41.lon13.atlas.cogentco.com (154.54.30.186)  160.581 ms
be2490.ccr42.lon13.atlas.cogentco.com (154.54.42.86)  162.390 ms
be2317.ccr41.lon13.atlas.cogentco.com (154.54.30.186)  161.606 ms
11  be2494.ccr22.lon01.atlas.cogentco.com (154.54.39.129)  165.021 ms
be2178.ccr21.lon01.atlas.cogentco.com (130.117.50.205)  178.197 ms  176.103 
ms
12  be2644.rcr12.b023101-0.lon01.atlas.cogentco.com (154.54.38.34)  162.512 ms
be2422.rcr12.b023101-0.lon01.atlas.cogentco.com (154.54.37.54)  165.632 ms  
165.704 ms
13  149.6.99.3 (149.6.99.3)  161.139 ms
149.6.99.2 (149.6.99.2)  165.569 ms  164.094 ms
14  81.199.204.85.satcom-systems.net (81.199.204.85)  165.263 ms  164.139 ms  
163.508 ms
15  81.199.204.86.satcom-systems.net (81.199.204.86)  381.022 ms  379.915 ms  
379.769 ms
16  * * *
17  kalata.sdnp.org.mw (41.77.11.210)  382.879 ms * *
18  * * *
19  chambo.sdnp.org.mw (196.45.188.5)  369.388 ms *  367.459 ms
___
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] .MW inconsistent zone updates?

[Randy Bush]

all true.  but mw is a tough case, hard circumstances.  and a sat link
does not help.  so frank from tz helps watch and debug.  warren also
watches, but he is up at layers nine and ten this week.  life goes on.

randy
___
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] .MW inconsistent zone updates?

[Randy Bush]

 The Zone-OPS according to iana.org are in cc'ed and should hopefully 
 have enough debug data to see the problem and solve it?

frank has been working with them for a while and debugging.  just did
not see the need to start screaming fire in a crowded theater.

randy
___
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] .MW inconsistent zone updates?

[Randy Bush]

 I did a domain update last week on cheki.mw, but it seems like some OPs 
 are either sleeping or their syncing is not really working ;)
 
 The following auth-ns is still delivering a old record:
 mw.21599INNSrip.psg.com.
 
 $ dig +nocomments ns cheki.mw @rip.psg.com
 
 ;  DiG 9.9.5-9-Debian  +nocomments ns cheki.mw @rip.psg.com
 ;; global options: +cmd
 ;cheki.mw.INNS
 cheki.mw.86400INNS ns-1722.awsdns-23.co.uk.
 cheki.mw.86400INNS ns-1022.awsdns-63.net.
 cheki.mw.86400INNS ns-1137.awsdns-14.org.
 cheki.mw.86400INNSns-279.awsdns-34.com.
 ;; Query time: 356 msec
 ;; SERVER: 147.28.0.39#53(147.28.0.39)
 ;; WHEN: Thu Jun 25 10:21:58 SAST 2015
 ;; MSG SIZE  rcvd: 178
 
 
 
 Others, like the following, show the correct entry:
 mw.21599INNSchambo.sdnp.org.mw.
 $ dig +nocomments ns cheki.mw @chambo.sdnp.org.mw
 
 ;  DiG 9.9.5-9-Debian  +nocomments ns cheki.mw @chambo.sdnp.org.mw
 ;; global options: +cmd
 ;cheki.mw.INNS
 cheki.mw.86400INNS athena.ns.cloudflare.com.
 cheki.mw.86400INNS arch.ns.cloudflare.com.
 ;; Query time: 231 msec
 ;; SERVER: 196.45.188.5#53(196.45.188.5)
 ;; WHEN: Thu Jun 25 10:22:29 SAST 2015
 ;; MSG SIZE  rcvd: 94

and i am supposed to fix this?

per your last instructions

zone mw { type slave; file secondary/mw;
 masters { 196.45.188.5; 41.221.99.135; };
 allow-transfer { mw-allow; }; };

and

rip.psg.com:/root# dig +short @localhost mw. soa
chambo.sdnp.org.mw. domains.registrar.mw. 2010251862 43200 7200 1209600 172800

rip.psg.com:/root# dig +short @196.45.188.5 mw. soa
;; connection timed out; no servers could be reached

rip.psg.com:/root# dig +short @41.221.99.135 mw. soa
;; connection timed out; no servers could be reached

having fun over there?

randy
___
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] Lack of tlsa support

[Randy Bush]

 Do we really have to fight to get every new type supported?

likely so, especially at the rate the dns-infected invent them

randy
___
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] traffic jam

[Randy Bush]

i have two modest auth servers, a few MB/s each.  ten days ago, they
went to 80MB.  sources and dests are widely distributed.  so is it just
a ddos, or is there something for which i should be looking?

randy


___
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] traffic jam

[Randy Bush]

and sources

9895 64.89.233.211
8957 207.102.138.158
6665 64.89.230.9
6602 65.55.37.38
6569 65.55.37.40
6508 65.55.37.41
6463 65.55.37.37
6411 65.55.37.36
6394 65.55.37.39
6317 208.115.113.82
5558 216.117.191.20
2883 65.54.225.186
2487 192.0.84.33
2118 67.195.93.161
2007 209.190.113.85
1809 93.190.233.85
1778 202.133.57.94
1761 72.167.139.204
1758 67.195.93.148
1718 74.125.187.211
1717 74.125.187.212
1714 67.195.93.136
1712 74.125.187.210

nominum?  msoft?  so it is backscatter from doses toward them?

randy
___
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] traffic jam

[Randy Bush]

 What do the queries look like?  Any patterns you can seine out?

waiting for the daily dnscap/dnstop cyclic report

spent a bit of time looking for a simple query log analysis tool.  maybe
i needed more coffee.  pointers appreciated.

 If it's running BIND, try turning on RRL.

did that a couple of years ago.  pushed it at some of the nogs.

randy
___
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] traffic jam

[Randy Bush]

just a quick awk smash and grab

195524 A
64539 
17229 MX
6391 NS
6139 ANY
4418 TXT
3153 DS
1827 PTR
1681 SOA
1379 DNSKEY
1187 SRV
 611 SPF
 308 A6
 205 CNAME
   7 NAPTR
   6 TKEY
   4 NSEC
   1 RRSIG
   1 PX
   1 AXFR

interesting in itself, eh?  :)

looks normal except the server is not (supposed to be) recursive

randy
___
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] hong kong workshop, day 2, live link

[Randy Bush]

 Complementing what Edmon Chung mentioned that root-servers was already
 reserved in the last new gTLD round, here follows the complete list of
 reserved names:
 
 AFRINIC
 IANA-SERVERS
 NRO
 ALAC
 ICANN
 RFC-EDITOR
 APNIC
 IESG
 RIPE
 ARIN
 IETF
 ROOT-SERVERS
 ASO
 INTERNIC
 RSSAC
 CCNSO
 INVALID
 SSAC
 EXAMPLE
 IRTF
 TEST
 GAC
 ISTF
 GNSO
 LACNIC
 WHOIS
 GTLD-SERVERS
 LOCAL
 WWW
 IAB
 LOCALHOST
 IANA
 NIC

this is an amusing list.  i can understand EXAMPLE, LOCALHOST, and TEST.
maybe even WHOIS and WWW.  but the rest sure look as if lawyers wanted
and got what is in effect a super trademark.

randy
___
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] hong kong workshop, day 2, live link

[Randy Bush]

 this is an amusing list.  i can understand EXAMPLE, LOCALHOST, and TEST.
 maybe even WHOIS and WWW.  but the rest sure look as if lawyers wanted
 and got what is in effect a super trademark.
 
 Its also missing one thats actually really important to be reserved:
 .onion.

very much agree

randy
___
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 list's MX

[Randy Bush]

 Anyway I  think all the lists should have an explicit MX RR, which 
 should not make confusing for MTA and people like me. :P

mail delivery works, and it is well-specified.

maybe work on getting  RRs

randy
___
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] signing reverse zones

[Randy Bush]

hi mark,

 I'm interested in knowing if it is standard practice amongst folks to
 sign .arpa zones.  Is there a compelling use case for signing reverse
 zones?

standard practice?  you some kinda control freak?

first there is the arguments about whether reverse zones are useful and
should be populated.  i happen to use reverse lookup daily, so i try to
maintain them well for all the address space for which i am responsible.

so, given that i am gonna maintain the zone, why would i not want to
also sign the data?  the amount of work is trivial, and it's just one
more step in trying to paint security on the horribly insecure internet.

otoh, some ipv6 providers (ahem!) do not seem to sign reverse parents in
ip6.arpa, so it can be hard to get one's delegated /56-48 properly DSed.

randy
___
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 it illegal to query the .berlin TLD servers?

[Randy Bush]

 These ICANN rules (against dotless domains) are meaningless and
 ridiculous, anyway.

not at all.  they serve to remind us of icann's relevance.

randy

pgpy8iUxci4Km.pgp
Description: PGP signature
___
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 it illegal to query the .berlin TLD servers?

[Randy Bush]

 If you believe the laws are wrong (as many do!), come help change
 them.

i know this will come as a shock, warren.  but some people do not see
bashing their heads against concrete walls as a good use of their time.

randy

pgprHfxoA80bE.pgp
Description: PGP signature
___
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 it illegal to query the .berlin TLD servers?

[Randy Bush]

 # dig +short txt berlin
 ;; Truncated, retrying in TCP mode.
 The .berlin-zone is protected through the German Copyright-Law.  Beyond it
 is protected by criminal law and data protection law.  Unauthorised entry to
 the zone is prohibited.  All rights, in particular the right of duplication,
 circulation or usage, belong exclusively to nic.berlin, unless you have an
 explicit written agreement with nic.berlin.

you asked for a txt rr and got one

as to the content of the txt rr, it seems to say you may not transfer
the zone file.  not being able to transfer the zone file is rather
common.

this is about as exciting as a schnitzel.

randy

pgpMI5xIbPn0F.pgp
Description: PGP signature
___
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] All NSs for a TLD being in the TLD itself

[Randy Bush]

 xn--ngbc5azd. 172800  IN  NS  a.nic.xn--ngbc5azd.
 xn--ngbc5azd. 172800  IN  NS  b.nic.xn--ngbc5azd.
 xn--ngbc5azd. 172800  IN  NS  c.nic.xn--ngbc5azd.
 xn--ngbc5azd. 172800  IN  NS  d.nic.xn--ngbc5azd.
 a.nic.xn--ngbc5azd.   172800  IN  A   37.209.192.3
 a.nic.xn--ngbc5azd.   172800  IN  2001:dcd:1:0:0:0:0:3
 b.nic.xn--ngbc5azd.   172800  IN  A   37.209.194.3
 b.nic.xn--ngbc5azd.   172800  IN  2001:dcd:2:0:0:0:0:3
 c.nic.xn--ngbc5azd.   172800  IN  A   37.209.196.3
 c.nic.xn--ngbc5azd.   172800  IN  2001:dcd:3:0:0:0:0:3
 d.nic.xn--ngbc5azd.   172800  IN  A   37.209.198.3
 d.nic.xn--ngbc5azd.   172800  IN  2001:dcd:4:0:0:0:0:3
 
 This works, of course, but it feels a bit fragile for me. Is there a
 history of this being unsafe? Of being more safe than NSs whose names
 are in other TLDs?

what do you think is fragile?  the in-baliwick glue?  why?

the ip address clumping would worry me if i thought they were not
anycast.

randy
___
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] Implementation of negative trust anchors?

[Randy Bush]

i will try once more

an american idiom is keep your eye on the doughnut not the hole. this 
NTA discussion focuses on the wrong thing.


why is the frelling software on the farbled server not detecting that is 
has been farbled and screaming loudly? why is it not preventing most of 
these farblings in the first place? when mongolia tried to change key 
[alg] to one that was not in the root, their software should not have 
done it.


fix the software and the ops processes.  do not patch over the problems 
or they will increase.  the problem is weak software and processes that 
need to be fixed, and patching and denial will not fix them.


randy
___
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] Implementation of negative trust anchors?

[Randy Bush]

 I'm still not convinced that the right answer is not to standardise,
 or not to write up a BCP

how about a wcp?  nancy regan was right.

i am still at the other end of the elephant.  why is the frelling
software on the farbled server not detecting that is has been farbled
and screaming loudly?  why is it not preventing most of these farblings
in the first place?

when mongolia tried to change key [alg] to one that was not in the root,
their software should not have done it.

do not be liberal in what you accept, this is the path to entropic
death.

randy, a naggumite
___
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] Geoff Huston on DNS-over-TCP-only study.

[Randy Bush]

 http://www.circleid.com/posts/20130820_a_question_of_dns_protocols/

them aussies certainly know how to do a nice bit of wide-scale
measurement.  now we can descend into the religions un-asserted
implications violate.

randy
___
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] Geoff Huston on DNS-over-TCP-only study.

[Randy Bush]

 http://www.circleid.com/posts/20130820_a_question_of_dns_protocols
 disappointed me with this characterization of RRL:
 
 There is a conversation thread that says that resolvers should
 implement response rate limiting (RRL), and silently discard
 repetitive queries that exceed some locally configured threshold.
 
 That ignores the slip parameter.  That is irritating given the
 relevant implications of slip=2 as the default in one RRL implementation
 and the popular alternative of slip=1.
 
 I was also disappointing that it failed to mention the crushing
 costs of DNS/TCP.

jeezus!  it was a *measurement* study.  that it did not parade your or
someone elses banner is irrelevant.

randy
___
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] old dnscap files

[Randy Bush]

 #!/bin/sh
 set -e
 . /etc/sysconfig/dnscap
 
 cd `dirname ${DNSCAP_BASEPATH}`
 while sleep 1 ; do
   GB_FREE=`df -B 1G . | awk 'NR==2 {print $4}'`
   echo $GB_FREE GB free | logger
   test $GB_FREE -gt ${DNSCAP_FREE_GB}  break;
   ls -rt | grep '^dnscap\.' | head -n 1 | xargs rm -v 21 | logger
 done

ok.  cute.  but i really only use dnscap to report yesterday's
activity.  i am not a dns geek doing longitudinal analysis.  so i think
i just save the most recent .part file, yes?

randy
___
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] weird DNS problem

[Randy Bush]

 You have only two authoritative name servers, in the same /16 and the
 same AS. From traceroute, they also seem to be in the same physical
 location. That is not enough to providence resilience and reliability.
 
 A network issue with this prefix/AS/location is sufficient to explain
 the symptoms you describe. DNS depends on IP, remember.

i privately pointed him to 2182.  of course that only deals with his L3
problem.

randy
___
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] Force TCP for external queries to Open Resolvers?

[Randy Bush]

 if they won't close the open resolver, you think they're gonna force
 tcp only?
 Not all open resolvers are run by brainless admins.

between the brainless and those who don't read mailing lists or update
software, i fear enough will remain to keep us foaming at the mouth like
rabid racoons.

randy
___
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] DS keys for child zones on same server inline signing

[Randy Bush]

 Hrm, I have some imminently expiring zones which I didn't bother setting
 up DNSSEC on.  I'll see if I can reproduce.

please report back.  and maybe a recipe.  thanks.

randy, who uses opendnssec and bind
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Defending against DNS reflection amplification attacks

[Randy Bush]

 Civil lawsuits by victims of DNS reflection and other attacks that
 depend on failures to deploy BCP38 might help convince boards of
 directors.

as will black helicopters.  can we stick to reality as we actually
experience it?  it is the reality on which the management, of which
joe spoke so well, operates (well ...)

randy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Defending against DNS reflection amplification attacks

[Randy Bush]

 Civil lawsuits by victims of DNS reflection and other attacks that
 depend on failures to deploy BCP38 might help convince boards of
 directors.
 Having been a witness in two of these lawsuits,

cites, please

randy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Defending against DNS reflection amplification attacks

[Randy Bush]

 Are you willing to also help us do the hard work to do the right thing?
 
 I'm pretty sure the answer is Yes.
 
 So let's get busy, and stop finding reasons not to do the Right Thing.
 
 - ferg

you may have a problem with your mail system.  it seems to be re-sending
messages from a decade ago, though they seem to have today's date.  odd.

perhaps, after the decade of us telling others how they should run their
networks, an actual large operator who has deployed bcp38 can give us an
analysis of the costs, capex and opex, and how they minimized them.

randy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] zone format bind9

[Randy Bush]

 On my FreeBSD boxes, I don't overwrite the system named, but rc.conf
 is set to run /usr/local/sbin/named. Typical mistake when one invokes
 named* commands as PATH will usually have /usr/sbin first.

precisely what happened

randy
___
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] zone format bind9

[Randy Bush]

a remote master has gone sick.  i need to restore an older zone file.
the file(s) on backup are in binary format.

if i stick an old one in the directory and restart bind,

psg.com:/usr/home/randy/public_html# dig @rip cctld. soa

;  DiG 9.4.3-P2  @rip cctld. soa
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 21371
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;cctld.IN  SOA

;; Query time: 0 msec
;; SERVER: 147.28.0.39#53(147.28.0.39)
;; WHEN: Mon Feb 11 20:07:08 2013
;; MSG SIZE  rcvd: 20

and

rip.psg.com:/usr/home/dns/secondary# named-compilezone -f raw -F text -i 
none -o - cctld cctld
dns_master_load: unsupported file format version
zone cctld/IN: loading from master file cctld failed: not implemented

i am not in love with this binary format bleep

clue bat?

randy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] zone format bind9

[Randy Bush]

 File corrupted ? I can take a look off-list if you want.

two diff copies?



cf.tgz
Description: Binary data
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] zone format bind9

[Randy Bush]

it turns out 9.9 did not install named-compilezone.  it was antique
___
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] swiss cheese

[Randy Bush]

kiddies are out this afternoon.  no big deal, no real services but this
makes uplinks prety ugly

turning off dnssec no real help

108.193.206.169 is not the only source.  and i presume it is spoofed anyway.

clue bat?

randy

 108-193-206-169.lightspeed.frsnca.sbcglobal.net: udp
 06:28:26.448671 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 rip.psg.com.domain: 22943+ [1au] ANY? CH. (31)
 06:28:26.448676 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 rip.psg.com.domain: 22943+ [1au] ANY? CH. (31)
 06:28:26.448679 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 rip.psg.com.domain: 22943+ [1au] ANY? CH. (31)
 06:28:26.448681 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 rip.psg.com.domain: 22943+ [1au] ANY? CH. (31)
 06:28:26.448712 IP rip.psg.com.domain 
 108-193-206-169.lightspeed.frsnca.sbcglobal.net.39939: 22943*- 19/0/14
 SOA, RRSIG, RRSIG, Type51, RRSIG, RRSIG, RRSIG, RRSIG, RRSIG,
 DNSKEY[|domain]
 06:28:26.448714 IP rip.psg.com 
 108-193-206-169.lightspeed.frsnca.sbcglobal.net: udp
 06:28:26.448725 IP rip.psg.com.domain 
 108-193-206-169.lightspeed.frsnca.sbcglobal.net.39939: 22943*- 19/0/14
 SOA, RRSIG, RRSIG, Type51, RRSIG, RRSIG, RRSIG, RRSIG, RRSIG,
 DNSKEY[|domain]
 06:28:26.448727 IP rip.psg.com.domain 
 108-193-206-169.lightspeed.frsnca.sbcglobal.net.39939: 22943*- 19/0/14
 SOA, RRSIG, RRSIG, Type51, RRSIG, RRSIG, RRSIG, RRSIG, RRSIG,
 DNSKEY[|domain]
 06:28:26.448730 IP rip.psg.com 
 108-193-206-169.lightspeed.frsnca.sbcglobal.net: udp
 06:28:26.448731 IP rip.psg.com 
 108-193-206-169.lightspeed.frsnca.sbcglobal.net: udp
 06:28:26.448791 IP rip.psg.com.domain 
 108-193-206-169.lightspeed.frsnca.sbcglobal.net.39939: 22943*- 19/0/14
 SOA, RRSIG, RRSIG, Type51, RRSIG, RRSIG, RRSIG, RRSIG, RRSIG,
 DNSKEY[|domain]
 06:28:26.448794 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 rip.psg.com.domain: 22943+ [1au] ANY? CH. (31)
 06:28:26.448795 IP rip.psg.com 
 108-193-206-169.lightspeed.frsnca.sbcglobal.net: udp
 06:28:26.448800 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 rip.psg.com.domain: 22943+ [1au] ANY? CH. (31)
 06:28:26.448802 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 rip.psg.com.domain: 22943+ [1au] ANY? CH. (31)
 06:28:26.448805 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 rip.psg.com.domain: 22943+ [1au] ANY? CH. (31)
 06:28:26.448807 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 rip.psg.com.domain: 22943+ [1au] ANY? CH. (31)
 06:28:26.448809 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 rip.psg.com.domain: 22943+ [1au] ANY? CH. (31)
 06:28:26.448811 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 rip.psg.com.domain: 22943+ [1au] ANY? CH. (31)
 06:28:26.448814 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 rip.psg.com.domain: 22943+ [1au] ANY? CH. (31)
 06:28:26.448817 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 rip.psg.com.domain: 22943+ [1au] ANY? CH. (31)
 06:28:26.448819 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 rip.psg.com.domain: 22943+ [1au] ANY? CH. (31)
 06:28:26.448833 IP rip.psg.com.domain 
 108-193-206-169.lightspeed.frsnca.sbcglobal.net.39939: 22943*- 19/0/14
 SOA, RRSIG, RRSIG, Type51, RRSIG, RRSIG, RRSIG, RRSIG, RRSIG,
 DNSKEY[|domain]
 06:28:26.448835 IP rip.psg.com 
 108-193-206-169.lightspeed.frsnca.sbcglobal.net: udp
 06:28:26.448865 IP rip.psg.com.domain 
 108-193-206-169.lightspeed.frsnca.sbcglobal.net.39939: 22943*- 19/0/14
 SOA, RRSIG, RRSIG, Type51, RRSIG, RRSIG, RRSIG, RRSIG, RRSIG,
 DNSKEY[|domain]
 06:28:26.448867 IP rip.psg.com 
 108-193-206-169.lightspeed.frsnca.sbcglobal.net: udp
 06:28:26.448918 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 rip.psg.com.domain: 22943+ [1au] ANY? CH. (31)
 06:28:26.448922 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 rip.psg.com.domain: 22943+ [1au] ANY? CH. (31)
 06:28:26.448924 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 rip.psg.com.domain: 22943+ [1au] ANY? CH. (31)
 06:28:26.448927 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 rip.psg.com.domain: 22943+ [1au] ANY? CH. (31)
 06:28:26.448930 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 rip.psg.com.domain: 22943+ [1au] ANY? CH. (31)
 06:28:26.448931 IP rip.psg.com.domain 
 108-193-206-169.lightspeed.frsnca.sbcglobal.net.39939: 22943*- 19/0/14
 SOA, RRSIG, RRSIG, Type51, RRSIG, RRSIG, RRSIG, RRSIG, RRSIG,
 DNSKEY[|domain]
 06:28:26.448933 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 rip.psg.com.domain: 22943+ [1au] ANY? CH. (31)
 06:28:26.448934 IP rip.psg.com 
 108-193-206-169.lightspeed.frsnca.sbcglobal.net: udp
 06:28:26.448937 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 rip.psg.com.domain: 22943+ [1au] ANY? CH. (31)
 06:28:26.448939 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 rip.psg.com.domain: 22943+ [1au] ANY? CH. (31)
 06:28:26.448943 IP 108-193-206-169.lightspeed.frsnca.sbcglobal.net.6799 
 

Re: [dns-operations] OpenHardware FPGA-based HSM SCA6000 with OpenSSL?

[Randy Bush]

 The same is true for systems that act like HSMs.
 Indeed. So what's the difference between HSMs and systems that act
 like HSMs?

what is the difference between airport nudie scanners and sniffer dogs?
the dogs do not have a commercial lobby.

randy
___
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] OpenHardware FPGA-based HSM SCA6000 with OpenSSL?

[Randy Bush]

 The dogs also cant get sued ;-)  Sometimes it is a matter of CYA.
 
 what is the difference between airport nudie scanners and sniffer
 dogs?  the dogs do not have a commercial lobby.

in the amurikan so-called culture, dogs are more easily sued than the
lobbiests and the makers of the nudie scanners.

but it's nice to hear from an expert that it really is just security
theater.

randy
___
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: Anyone still using a Sun/Oracle SCA6000 with OpenSSL?

[Randy Bush]

 i keep wondering about the use of hsms in dnssec and rpki signing.  i
 suspect that the threat model is not well thought out.
 
 I wonder what other operator's reasons for using a HSM with DNSSEC are
 (security-relevant, not performance-relevant).

exactly.  and folk are spending very large amounts of money on hsms and
have not been able to explain their threat/security model so that i
could understand it.  of course, the lack of understanding could be my
problem.  but i suspect security theater.

randy
___
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] OpenHardware FPGA-based HSM SCA6000 with OpenSSL?

[Randy Bush]

 Making a tamper-evident box with SoftHSM is (I think) much easier to
 do, more scalable and done quicker.
 Right. I think that one question has not been asked so far: why? What's
 the real benefit that you'd get out of this?

sounds like a diy hsm to me.

and i still want to understand the threat model motivating hsm use in
dnssec and rpki signing.

randy
___
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: Anyone still using a Sun/Oracle SCA6000 with OpenSSL?

[Randy Bush]

 Be trustee is a key to use HSM or hardware encryption. And because we
 are running a critical Internet infrastructure, I think should be the
 way, be trustee.

that's called security theater.  what is the threat model?  what is the
asset you are protecting against what attack by what adversary?

[ if the cost of the hsm is zero, it adds complexity and hence is a
  security problem not a security solution ]

randy
___
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] which software is easier to setup a geo-based dns?

[Randy Bush]

 For those what's the best suitable for setup a geo-based DNS server?

what is a 'geo-based' server?  and is it authoritative or caching?

randy
___
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] dotless domains

[Randy Bush]

 perhaps narrowing core technologies to the intersection of the
 un-flawed abilities of all applications will be an increasingly
 narrowing path which leads no place pleasant.
 True. I'm not particularly against the idea of using dotless
 domains, but we know who's going to live with the support questions
 when users start complaining. Paul's piece on CircleID sums it up
 nicely. Caveat emptor.

there is a difference between how we operationally choose to deploy
things prudently and a political forum hamstringing a technology while
stepping into the turf of the ietf.

randy
___
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] keeping ICANN busy

[Randy Bush]

 It would be nice if the IAB or IETF could issue some sort of RRs in
 single-label domain names considered harmful document.
 or rrs in single-label domain names are legal.  applications should
 be able to handle them.
 What's the path of least resistance ?

putting mrs. greenberg in the cattle car.

randy
___
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] socialsecurity.gov

[Randy Bush]

what am i not understanding here?

from seattle westin

psg.com:/usr/home/randy doc -p -w socialsecurity.gov.Doc-2.2.3: doc -p -w 
socialsecurity.gov.
Doc-2.2.3: Starting test of socialsecurity.gov.   parent is gov.
Doc-2.2.3: Test date - Wed Sep 12 09:57:32 GMT 2012
Summary:
   No errors or warnings issued for socialsecurity.gov.
Done testing socialsecurity.gov.  Wed Sep 12 09:57:39 GMT 2012

from iij in tokyo

rair.psg.com:/Users/randy doc -p -w socialsecurity.gov.
Doc-2.2.3: doc -p -w socialsecurity.gov.
Doc-2.2.3: Starting test of socialsecurity.gov.   parent is gov.
Doc-2.2.3: Test date - Wed Sep 12 19:00:44 JST 2012
DIGERR (NOT_AUTHORIZED): dig @dns5.ssa.gov. for SOA of socialsecurity.gov. 
failed
DIGERR (NOT_AUTHORIZED): dig @dns6.ssa.gov. for SOA of socialsecurity.gov. 
failed
Summary:
   No errors or warnings issued for socialsecurity.gov.
   Incomplete test for socialsecurity.gov. (2)
Done testing socialsecurity.gov.  Wed Sep 12 19:01:30 JST 2012

and the log

Doc-2.2.3: doc -p -w socialsecurity.gov.
Doc-2.2.3: Starting test of socialsecurity.gov.   parent is gov.
Doc-2.2.3: Test date - Wed Sep 12 19:00:44 JST 2012
Note: Skipping parent domain testing
Found 4 NS and 4 glue records for socialsecurity.gov. @a.gov-servers.net. 
(non-AUTH)
Using NSlist from parent domain server a.gov-servers.net.
NS list summary for socialsecurity.gov. from parent (gov.) servers
  == dns1.ssa.gov. dns2.ssa.gov. dns5.ssa.gov.
  == dns6.ssa.gov.
soa @dns1.ssa.gov. for socialsecurity.gov. serial: 2011050364
soa @dns2.ssa.gov. for socialsecurity.gov. serial: 2011050364
DIGERR (NOT_AUTHORIZED): dig @dns5.ssa.gov. for SOA of socialsecurity.gov. 
failed
DIGERR (NOT_AUTHORIZED): dig @dns6.ssa.gov. for SOA of socialsecurity.gov. 
failed
SOA serial #'s agree for socialsecurity.gov.
Authoritative domain (socialsecurity.gov.) servers agree on NS for 
socialsecurity.gov.
NS list from socialsecurity.gov. authoritative servers matches list from
  ===  first parent (gov.) nameserver queried
Checking 0 potential addresses for hosts at socialsecurity.gov.
  == 
Summary:
   No errors or warnings issued for socialsecurity.gov.
   Incomplete test for socialsecurity.gov. (2)
Done testing socialsecurity.gov.  Wed Sep 12 19:01:30 JST 2012


 Query Log 

## Nameservers for gov. (dig ns gov.):

a.gov-servers.net.
b.gov-servers.net.
===

## NS records for socialsecurity.gov. domain from nameserver a.gov-servers.net.

;; got answer:
;; -header- opcode: query, status: noerror, id: 58332
;; flags: qr; query: 1, answer: 0, authority: 4, additional: 8

;; authority section:
socialsecurity.gov. 86400   in  ns  dns1.ssa.gov.
socialsecurity.gov. 86400   in  ns  dns2.ssa.gov.
socialsecurity.gov. 86400   in  ns  dns5.ssa.gov.
socialsecurity.gov. 86400   in  ns  dns6.ssa.gov.

;; additional section:
dns1.ssa.gov.   86400   in  a   199.173.231.82
dns2.ssa.gov.   86400   in  a   199.173.231.83
dns5.ssa.gov.   86400   in  a   137.200.4.30
dns6.ssa.gov.   86400   in  a   137.200.4.31
dns1.ssa.gov.   86400   in  2001:1930:c05::c
dns2.ssa.gov.   86400   in  2001:1930:c05::d
dns5.ssa.gov.   86400   in  2001:1930:e03::c
dns6.ssa.gov.   86400   in  2001:1930:e03::d

===

## SOA record for socialsecurity.gov. domain from nameserver dns1.ssa.gov.

;; got answer:
;; flags: qr aa; query: 1, answer: 1, authority: 4, additional: 8

;; answer section:
socialsecurity.gov. 36000   in  soa dns1.ssa.gov. 
dnsfwadmin.ssa.gov. 2011050364 3600 600 1209600 14400

===

## Version.bind record for nameserver dns1.ssa.gov. (socialsecurity.gov.)


;  dig 9.7.3-p3  @dns1.ssa.gov. version.bind txt chaos +norec +nocmd 
+noques +noauth +noadd +nostat +tries=2
; (2 servers found)
;; global options: +cmd
;; got answer:
;; -header- opcode: query, status: noerror, id: 36620
;; flags: qr aa; query: 1, answer: 0, authority: 1, additional: 0

===

## SOA record for socialsecurity.gov. domain from nameserver dns2.ssa.gov.

;; got answer:
;; flags: qr aa; query: 1, answer: 1, authority: 4, additional: 8

;; answer section:
socialsecurity.gov. 36000   in  soa dns1.ssa.gov. 
dnsfwadmin.ssa.gov. 2011050364 3600 600 1209600 14400

===

## Version.bind record for nameserver dns2.ssa.gov. (socialsecurity.gov.)


;  dig 9.7.3-p3  @dns2.ssa.gov. version.bind txt chaos +norec +nocmd 
+noques +noauth +noadd +nostat +tries=2
; (2 servers found)
;; global options: +cmd
;; got answer:
;; -header- opcode: query, status: noerror, id: 43701
;; flags: qr aa; query: 1, answer: 0, authority: 1, additional: 0

===

## NS records for socialsecurity.gov. domain from nameserver dns1.ssa.gov.

;; got answer:
;; -header- opcode: 

Re: [dns-operations] socialsecurity.gov

[Randy Bush]

 I can't reach the v6 addresses of dns5 or dns6; I can reach dns1 and
 dns2. I don't see anything in the log that indicates which transport
 was being used, but that would be consistent with the problem if the
 IIJ host is v6-enabled.

actually, both hosts are v6 enabled.  isn't everything?

so i disabled v6 on my tokyo host.  same result.

rair.psg.com:/Users/randy doc -p -w socialsecurity.gov.
Doc-2.2.3: doc -p -w socialsecurity.gov.
Doc-2.2.3: Starting test of socialsecurity.gov.   parent is gov.
Doc-2.2.3: Test date - Wed Sep 12 22:11:18 JST 2012
DIGERR (NOT_AUTHORIZED): dig @dns1.ssa.gov. for SOA of socialsecurity.gov. 
failed
DIGERR (NOT_AUTHORIZED): dig @dns2.ssa.gov. for SOA of socialsecurity.gov. 
failed
DIGERR (NOT_AUTHORIZED): dig @dns5.ssa.gov. for SOA of socialsecurity.gov. 
failed
DIGERR (NOT_AUTHORIZED): dig @dns6.ssa.gov. for SOA of socialsecurity.gov. 
failed
SYSerr: No servers for socialsecurity.gov. returned SOAs ...
Summary:
   YIKES: doc aborted while testing socialsecurity.gov.  parent gov.
   Incomplete test for socialsecurity.gov. (5)
Done testing socialsecurity.gov.  Wed Sep 12 22:12:06 JST 2012

but for a moment there i sure thought you had it.  thanks.

randy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] PIR's (.org) Web site looks… default...

[Randy Bush]

that's byedaddy

randy
___
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 transfer DS records to parent zone?

[Randy Bush]

 As an industry, we have the opportunity of giving our customers the
 blue pill and keeping them happy, or letting someone else give them
 the red pill and show them what can really happen.

yep

up a level.  we are deploying new technology that we think is important
to the internet, ipv6 and dnssec.  the infrastructure needed to support
them,  glue, DS at parent, ... needs to be in place.  not having it
in place is operationally negligent.

i have three administrative dns 'parents'

  o an obscure little registrar for my .com/net/org stuff, who could
deal with  glue long enough ago that i can not remember the
details, and took a few weeks to sort out their upstream plumbing
for DS

  o an upstream isp who is willing to install my DS in their ip6.arpa
zone, but that zone is not signed

  o two cctlds at iana, who is s wrapped around the pole with
bureaucracy that they have lost sight of the pole or the ground

randy
___
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] Restrict ANY query to TCP ? Re: Why would an MTA issue an ANY query instead of an MX query?

[Randy Bush]

 how about much simpler configuration option to force all
 any queries to be reissued over TCP,
   restrict-any-udp  yes/no;

as i charge by the byte, i like it a lot.  ymmv.

randy
___
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] gtld servers in oz

[Randy Bush]

are there servers for com, net, org, ... in australia?

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