Re: [dns-operations] A request for "data"

[Warren Kumari]

On Thu, Apr 25 2024 at 12:15 PM, Tim Wicinski  wrote:

I know in our fancy pants nominum s/w we run at cox I add the
> line "managed-keys" and like magic we're pulling 5011 automagic maintained.
>
> got time later today? I am open
>
> On Thu, Apr 25, 2024 at 11:58 AM Edward Lewis 
> wrote:
>
>> An open question...
>>
>> Is anyone aware of any use of Automated Updates of DNS Trust Anchors,
>> documented in RFC 5011, in the last 5 years or so?  Does anyone know of a
>> zone (other than the root) that documents or publicizes a reliance on
>> Automated Updates?
>>
>
Probably not, because there are really any (public) trust anchors other
than the root.


>> For the record, the last time a ccTLD published a revoked SEP key was April
>> 9, 2019 (this was not the revocation of the root zone KSK but a TLD's
>> KSK), so I know that none of the TLDs have completed an Automated Updates
>> roll since then.
>>
>
I don't really understand under what conditions I'd want to have a
trust-anchor for any (public) zone. The root is signed, the TLDs publish
their DS in the root, 2nd levels publish in the TLD, etc. Having a trust
anchor for anything under the root seems to just be asking for trouble — if
a TLD needed to roll their keys (because of compromise or just on schedule)
they can easily and quickly do so under the current paradigm. If I've also
installed their key as a separate TA they have a whole long and involved
process to go through. The only time that I could see this being "useful"
would be if I were in a country that wanted to be able to disconnect itself
from the public Internet for an extended period of time…


>> I have no historical data below the TLD level, so I'm seeking anecdotal
>> evidence of reliance on Automated Updates anywhere (else) in the global
>> public Internet.  I doubt there is any, but that is based on absolutely no
>> data and personal assumptions.
>>
>>
Yeah, I think that we have both been saying "public" throughout this thread
because there may well be uses of this for private, non-Internet connected
zones, which we will not really be able to see…

W


Private replies are fine...I'm not trying to name operators, just evaluate
>> the mechanism's adoption.
>>
>> Ed Lewis
>>
>>
>>
>> ___
>> dns-operations mailing list
>> dns-operations@lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>>
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Why did .KE go insecure?

[Warren Kumari via dns-operations]

--- Begin Message ---
 Me too!
W


On Sat, Dec 10 2022 at 1:37 PM, Jan-Piet Mens  wrote:

>
> >Yes. I imagine they’ll make an announcement at some point.
>
> Two months later I'm still curious; KE. remains insecure [1].
>
> -JP
>
> [1] https://dnsviz.net/d/ke/Y5TQvQ/dnssec/
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

[Warren Kumari]

On Wed, Oct 19, 2022 at 4:38 AM, Scott Morizot  wrote:

> On Wed, Oct 19, 2022 at 5:11 AM Petr Špaček  wrote:
>
>> Code is your guide :-)
>>
>
> Agreed. Any time I have a need to drill down and understand exactly what
> is happening and source code is available, that is always where I look
> first.
>


Weell… I think that the way it *should* work is: When you need to
understand how something works you read the fine RFCs… and when it doesn't
work like that, you read the code and say "See, over here in line 42 of
foozlewargh.c you are checking if bar <= 17, and you *should* be checking
if bar == 17."

Yes, I know, I know… but I did say "the way it *should* work"...

W



>
>> Now seriously: I don't think documenting it neither
>> a) necessary
>> b) good idea
>>
>
> Comments in the code are always helpful. ;-) But yes, beyond that trying
> to capture specific mechanisms rather than what is being accomplished in
> the documentation is often counter-productive.
>
>
>> It can change between versions, and we certainly do not want people to
>> depend on particular behavior. We want people to follow protocol!
>>
>
> Yep. And in this instance, I haven't found the protocol standard
> ambiguous. Once the chain of trust is broken through a valid insecure
> delegation, it can only be reestablished by a trust anchor for a zone
> farther down the hierarchy. In earlier days, before the root zone was
> signed or when there were gaps in the chain, such lower level trust anchors
> were more common for early adopters. These days, people mostly just use the
> root trust anchor so once there's a point where the chain of trust shifts
> to insecure it remains insecure for everyone for subsequent delegations. A
> DS record can only establish a secure delegation when placed in a secure
> zone. Putting one in an insecure zone does nothing for the security status
> of the delegated zone. A resolver would require a trust anchor for it to
> establish security.
>
> So the controlling point from a DNSSEC perspective is the insecure status
> of fiscal.treasury.gov.
>
> DNSVIZ captures it. The red lines note that the RRSIGs for the entries in
> fiscal.treasury.gov are no good. (I have no insight into why they are
> being generated, but it's likely a misconfiguration somewhere.) But the
> records themselves, like the delegation, are clearly marked insecure. At
> that juncture, everything below fiscal.treasury.gov becomes insecure
> unless a resolver has a trust anchor for a lower level zone.
>
> https://dnsviz.net/d/fiscal.treasury.gov/dnssec/
>
> The DS query correctly validates the non-existence of a DS record in the
> secure parent zone, treasury.gov. They should clean up the fiscal.
> treasury.gov zone and fix whatever is generating the spurious and invalid
> DNSSEC records in it. But the presence of those records should have no
> impact on validation since the zone itself is insecure. They also really
> should migrate at least to algorithm 8 and remove the SHA-1 DS record for
> treasury.gov from .gov. But none of those items actually break anything.
>
> dig @ns1.treasury.gov fiscal.treasury.gov ds +multiline +dnssec +norecurse
>
> ; <<>> DiG 9.16.28 <<>> @ns1.treasury.gov fiscal.treasury.gov ds
> +multiline +dnssec +norecurse
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10792
> ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;fiscal.treasury.gov.   IN DS
>
> ;; AUTHORITY SECTION:
> treasury.gov.   900 IN SOA ns1.treasury.gov. ecb-hosting.fiscal.
> treasury.gov. (
> 2001180551 ; serial
> 3600   ; refresh (1 hour)
> 900; retry (15 minutes)
> 1209600; expire (2 weeks)
> 900; minimum (15 minutes)
> )
> treasury.gov.   900 IN RRSIG SOA 7 2 900 (
> 20221023094202 20221016084202 3908
> treasury.gov.
>
> J0M3CKVGn+KAUhQ086q4tuAlA9HpoUQRVjfwP67wC/RO
>
> HTvSldVFCnKEV0QfTBnb8Z+bCU421PtMTjeI66efgPrc
>
> agp2BcggozZyMkonypTRJ4CW63JabXxy5RtSFq1jnTdf
> zNz2TK+yhfelkV1e3FN4uJmT2rcwcaQToOEYCzM= )
> mta7icve5v8c9rqj08ur3qeo9tpp6l6s.treasury.gov. 900 IN NSEC3 1 0 1
> 16EBC108F10FE696 (
> MTA7ICVE5V8C9RQJ08UR3QEO9TPP6L6T
> NS RRSIG )
> mta7icve5v8c9rqj08ur3qeo9tpp6l6s.treasury.gov. 900 IN RRSIG NSEC3 7 3 900
> (
> 20221026090448 20221019080448 3908
> treasury.gov.
>
> ng8mTUN469dzduIYeUWNcVJJlnRLnH8C7OA5J3ysjk+8
>
> X1yX0/CONnMmlztKL1zwCstgv6L9xr8aUJW9Z/Bn/CtI
>
> whh9ymeJ0lXQzXzg6Fi7RmeSHl9Ecu1789FrbuPQF+tA
> bwTcddJ29fDG9lgx4F8JvnzVxeHk4TqOh171Fhs= )

Re: [dns-operations] ENT NXDOMAIN problem at .BS nameserver ns36.cdns.net

[Warren Kumari]

[ - bs ]

There is a very similar issue with 'production.cloudflare.docker.com'
(https://dnsviz.net/d/production.cloudflare.docker.com/dnssec/):

A query for production.cloudflare.docker.com results in a NOERROR response,
while a query for its ancestor, cloudflare.docker.com, returns a name error
(NXDOMAIN), which indicates that subdomains of cloudflare.docker.com,
including production.cloudflare.docker.com, don't exist.

This broke my ability to use docker for a while — I'd enabled strict qname
minimization as a test, and then needed to update some containers in an
emergency. It took a while to debug the issues…

W


On Wed, Sep 21, 2022 at 8:33 AM, Viktor Dukhovni 
wrote:

> The .COM.BS  is an empty non-terminal with various child
> domains registered beneath. The "ns36.cdns.net" nameserver for .BS
> responds with NXDOMAIN to "com.bs" qname-minimised queries.
>
> This in turn can and does sometimes lead to NXDOMAIN inference for the
> child domains.
>
> This nameserver needs to be withdrawn and fixed before it is returned to
> service.
>
> 2001:678:4::24 ns36.cdns.net
> 194.0.1.36 ns36.cdns.net
>
> Example responses:
>
> @194.0.1.36
>
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3297
> ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;com.bs. IN SOA
>
> ;; AUTHORITY SECTION:
> bs. SOA dns.nic.bs. bsadmin.cob.edu.bs. 2022092000 3600 900 1814400 9000
>
> @2001:678:4::24
>
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39616
> ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;com.bs. IN SOA
>
> ;; AUTHORITY SECTION:
> bs. SOA dns.nic.bs. bsadmin.cob.edu.bs. 2022092000 3600 900 1814400 9000
>
> --
> Viktor.
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] .au DNSSEC issues

[Warren Kumari]

This is now at least listed on the Ianix website (
https://ianix.com/pub/dnssec-outages.html [0] ), but the .FJ outage from a
few weeks ago isn't.

Links:

   - https://blog.cloudflare.com/dnssec-issues-fiji/
   - https://dnsviz.net/d/fj/YicaMA/dnssec/
   -
   https://lists.dns-oarc.net/pipermail/dns-operations/2022-March/021593.html


W
[0]: Note: This site is NSFW - Not Safe For Wallidation-deployment (Sorry -
hopefully someone can come up with a better expansion



On Mon, Mar 28, 2022 at 4:56 AM, Brett Carr  wrote:

> Apparently, there was a DNSSEC issue within .au last week.
>
>
>
> https://www.auda.org.au/statement/au-update
>
>
>
> https://www.theguardian.com/technology/2022/mar/22/
> australia-internet-outage-15000-major-news-and-government-websites-affected-by-au-error
>
>
>
>
>
> This seems to of gone undiscussed on here which is unusual.
>
>
>
> Does anyone know anything about what happened. I’d like to know if there
> is anything to be learned from the problem.
>
>
>
> Thanks
>
>
>
> Brett
>
>
>
> --
> Brett Carr
> Manager DNS Engineering
> Nominet UK
>
>
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Oddness with Cloudfare authoritative servers

[Warren Kumari]

On Thu, Sep 23, 2021 at 9:34 AM Peter van Dijk 
wrote:

> On Wed, 2021-09-22 at 20:13 -0400, Warren Kumari wrote:
> > Oh, testing now gives a different / working result:
> >
> > $ curl -v https://www.deltamath.com --connect-to 
> > deltamath.com:443:172.64.80.1
> 2>&1 | grep "HTTP/2 200"
> >
>
> This one sends a Server Name Indication of www.deltamath.com (like with
> 'openssl s_client -connect 172.64.80.1:443 -servername deltapath.com').
>
> >
> > > Yes, 172.64.80.1 is a CF address, but it was being returned for
> deltamath.com.
> > > Doing a GET / over TLS with the host set to deltamath.com  was giving
> a 403 Forbidden:
> > > HTTP/1.1 403 Forbidden
>
> This one is reproducible by not sending an SNI (like with 'openssl
> s_client -connect 172.64.80.1:443').
>
> As far as I can tell -right now-, the IP is entirely valid for the
> site, as long as the client sends the correct SNI and Host header
> (which web browsers do!).
>

Hah! That explains at least some of my testing issues.
When I was testing this issue it was from a machine without curl -- and so
I used openssl and manually typed the HTTP, I didn't include -servername:
$ echo -e "GET / HTTP/1.1\r\nHost:deltamath.com\r\n\r\n" | openssl 2>&1
s_client -quiet -connect 172.64.80.1:443
depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust
Root
verify return:1
depth=1 C = US, O = "Cloudflare, Inc.", CN = Cloudflare Inc ECC CA-3
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.",
CN = sni.cloudflaressl.com
verify return:1
HTTP/1.1 403 Forbidden
Server: cloudflare
Date: Wed, 22 Sep 2021 18:36:57 GMT
Content-Type: text/html
Content-Length: 151
Connection: keep-alive
CF-RAY: 692da44bb84eeb39-LAX


403 Forbidden

403 Forbidden
cloudflare


^C

This gave a different result to testing against the other addresses, which
just error out:
$ echo -e "GET / HTTP/1.1\r\nHost:deltamath.com\r\n\r\n" | openssl 2>&1
s_client -quiet -connect 104.26.2.229:443
140607395013952:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert
handshake failure:../ssl/record/rec_layer_s3.c:1544:SSL alert number 40

I didn't really bother wondering *why* the "working" ones were giving me an
SSL failure though.

Adding '-servername deltamath.com' does at least fix that, but now I've
made CF sufficiently grumpy by sending odd requests that it's popping up a
CAPTCHA :-)

Whatever the case, the fact that William was experiencing issues when this
particular address was returned, and it seems to be the only one that
responds in this way when no SNI is provided is, um, interesting. Perhaps
whatever his customer was using isn't a web browser, or is really old, or
(being part of a school system) passes through some sort of interception
proxy which doesn't interact well, or...

W






>
> Kind regards,
> --
> Peter van Dijk
> PowerDNS.COM BV - https://www.powerdns.com/
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Oddness with Cloudfare authoritative servers

[Warren Kumari]

Oh, testing now gives a different / working result:

$ curl -v https://www.deltamath.com --connect-to deltamath.com:443:172.64.80.1
2>&1 | grep "HTTP/2 200"

So, looks like the issue is likely resolved.
W

On Wed, Sep 22, 2021 at 7:49 PM Warren Kumari  wrote:

>
>
> On Wed, Sep 22, 2021 at 7:26 PM Adam David  wrote:
>
>> This does not seem to be a DNS resolution/misconfiguration issue on
>> Cloudflare's end.
>>
>> https://172.64.80.1/ provides an error message (as it should) indicating
>> it is a CloudFlare IP. If you can't see that in a web browser, then the
>> issue is local to your network.
>>
>
> Yes, 172.64.80.1 is a CF address, but it was being returned for
> deltamath.com.
> Doing a GET / over TLS with the host set to deltamath.com  was giving a
> 403 Forbidden:
> HTTP/1.1 403 Forbidden
> Server: cloudflare
> Date: Wed, 22 Sep 2021 18:44:15 GMT
> Content-Type: text/html
> Content-Length: 151
> Connection: keep-alive
> CF-RAY: 692daefc1ffd542b-YYZ
>
> 
> 403 Forbidden
> 
> 403 Forbidden
> cloudflare
> 
> 
>
> The other address handed out all worked fine.
> So:
> 1: it is a DNS issue and they shouldn’t have handed out that address for
> that name or
> 2: that machine was borked.
>
> W
>
>
>
>
>
>
>> The main causes that I gather would be:
>>
>> 1. There was a temporary cache propagation issue on CF's network. (Still
>> not a DNS issue.)
>> 2. Your IT department is using 172.0.0.0/9 or possibly even 172.0.0.0/8
>> where they intended to use 172.16.0.0/12 (RFC1918 IP space). This would
>> block access to the netblock belonging to Cloudflare and you would have
>> difficulty accessing thousands of websites.
>>  Side Note: 172.64.0.0/13 belongs
>> to AS13335.
>>
>> You should always start with your IT department.
>> If you are a Cloudflare customer, contact them directly.
>> If you are a DeltaMath customer, then you need to contact them directly.
>>
>> Sincerely,
>>
>> Adam Vallee
>>
>>
>>
>> On Wed, Sep 22, 2021 at 4:03 PM Brown, William  wrote:
>>
>>> From: dns-operations  On Behalf Of
>>> Erik Stian Tefre
>>> Sent: Wednesday, September 22, 2021 3:38 PM
>>> To: dns-operations@lists.dns-oarc.net
>>> Subject: Re: [dns-operations] Oddness with Cloudfare authoritative
>>> servers
>>>
>>> > Possibly not a DNS issue at all, but something like this:
>>>
>>> > https://community.cloudflare.com/t/revil-ransomware/301435
>>>
>>> > (Executive summary: One Cloudflare IP being blocked by a firewall
>>> because of a different and misbehaving Cloudflare customer who happened to
>>> serve malicious content from that same IP.)
>>>
>>> > Regards,
>>> > Erik
>>>
>>> Interesting.  The real issue I am experiencing is that I am getting
>>> inconsistent responses from nominally the same authoritative server.  It
>>> just so happens that when we get 172.64.80.1 as the answer it fails.  I
>>> would prefer to get the correct answer so students can use the online
>>> educational resource the district is paying for.
>>> Confidentiality Notice: This electronic message and any attachments may
>>> contain confidential or privileged information, and is intended only for
>>> the individual or entity identified above as the addressee. If you are not
>>> the addressee (or the employee or agent responsible to deliver it to the
>>> addressee), or if this message has been addressed to you in error, you are
>>> hereby notified that you may not copy, forward, disclose or use any part of
>>> this message or any attachments. Please notify the sender immediately by
>>> return e-mail or telephone and delete this message from your system.
>>>
>>> ___
>>> dns-operations mailing list
>>> dns-operations@lists.dns-oarc.net
>>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>>>
>> ___
>> dns-operations mailing list
>> dns-operations@lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>>
> --
> Perhaps they really do strive for incomprehensibility in their specs.
> After all, when the liturgy was in Latin, the laity knew their place.
> -- Michael Padlipsky
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Oddness with Cloudfare authoritative servers

[Warren Kumari]

On Wed, Sep 22, 2021 at 7:26 PM Adam David  wrote:

> This does not seem to be a DNS resolution/misconfiguration issue on
> Cloudflare's end.
>
> https://172.64.80.1/ provides an error message (as it should) indicating
> it is a CloudFlare IP. If you can't see that in a web browser, then the
> issue is local to your network.
>

Yes, 172.64.80.1 is a CF address, but it was being returned for
deltamath.com.
Doing a GET / over TLS with the host set to deltamath.com  was giving a 403
Forbidden:
HTTP/1.1 403 Forbidden
Server: cloudflare
Date: Wed, 22 Sep 2021 18:44:15 GMT
Content-Type: text/html
Content-Length: 151
Connection: keep-alive
CF-RAY: 692daefc1ffd542b-YYZ


403 Forbidden

403 Forbidden
cloudflare



The other address handed out all worked fine.
So:
1: it is a DNS issue and they shouldn’t have handed out that address for
that name or
2: that machine was borked.

W






> The main causes that I gather would be:
>
> 1. There was a temporary cache propagation issue on CF's network. (Still
> not a DNS issue.)
> 2. Your IT department is using 172.0.0.0/9 or possibly even 172.0.0.0/8
> where they intended to use 172.16.0.0/12 (RFC1918 IP space). This would
> block access to the netblock belonging to Cloudflare and you would have
> difficulty accessing thousands of websites.
>  Side Note: 172.64.0.0/13 belongs
> to AS13335.
>
> You should always start with your IT department.
> If you are a Cloudflare customer, contact them directly.
> If you are a DeltaMath customer, then you need to contact them directly.
>
> Sincerely,
>
> Adam Vallee
>
>
>
> On Wed, Sep 22, 2021 at 4:03 PM Brown, William  wrote:
>
>> From: dns-operations  On Behalf Of
>> Erik Stian Tefre
>> Sent: Wednesday, September 22, 2021 3:38 PM
>> To: dns-operations@lists.dns-oarc.net
>> Subject: Re: [dns-operations] Oddness with Cloudfare authoritative servers
>>
>> > Possibly not a DNS issue at all, but something like this:
>>
>> > https://community.cloudflare.com/t/revil-ransomware/301435
>>
>> > (Executive summary: One Cloudflare IP being blocked by a firewall
>> because of a different and misbehaving Cloudflare customer who happened to
>> serve malicious content from that same IP.)
>>
>> > Regards,
>> > Erik
>>
>> Interesting.  The real issue I am experiencing is that I am getting
>> inconsistent responses from nominally the same authoritative server.  It
>> just so happens that when we get 172.64.80.1 as the answer it fails.  I
>> would prefer to get the correct answer so students can use the online
>> educational resource the district is paying for.
>> Confidentiality Notice: This electronic message and any attachments may
>> contain confidential or privileged information, and is intended only for
>> the individual or entity identified above as the addressee. If you are not
>> the addressee (or the employee or agent responsible to deliver it to the
>> addressee), or if this message has been addressed to you in error, you are
>> hereby notified that you may not copy, forward, disclose or use any part of
>> this message or any attachments. Please notify the sender immediately by
>> return e-mail or telephone and delete this message from your system.
>>
>> ___
>> dns-operations mailing list
>> dns-operations@lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-- 
Perhaps they really do strive for incomprehensibility in their specs.
After all, when the liturgy was in Latin, the laity knew their place.
-- Michael Padlipsky
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Oddness with Cloudfare authoritative servers

[Warren Kumari]

On Wed, Sep 22, 2021 at 7:38 PM Ethan Katz-Bassett 
wrote:

> Cloudflare in particular is experimenting with returning different IP
> addresses to different queries for all kinds of reasons:
> https://mislove.org/publications/IP-Unbound-SIGCOMM.pdf
>

Yup — but in this case, at least one of the addresses that they returned
gave a 403 Error when connecting and trying to fetch /.

Giving out different addresses is fine, but they should all work :-)

W



>
>
> On Wed, Sep 22, 2021 at 1:29 PM Warren Kumari  wrote:
>
>>
>>
>> On Wed, Sep 22, 2021 at 1:01 PM Brown, William  wrote:
>>
>>> We have a school district that is trying to resolve the domain
>>> deltamath.com.  This issue is impacting the classroom use of this
>>> service.
>>>
>>>
>>>
>>> The authoritative servers are tani.ns.cloudflare.com and
>>> jarred.ns.cloudfare.com.  Tani seems to work correctly.  Jarred
>>> however, will return two different results:
>>>
>>>
>>>
>>> Here are the results of four tries within a few seconds:
>>>
>>>
>>>
>>> [wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
>>>
>>> 172.67.75.10
>>>
>>> 104.26.2.229
>>>
>>> 104.26.3.229
>>>
>>> [wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
>>>
>>> 104.26.2.229
>>>
>>> 104.26.3.229
>>>
>>> 172.67.75.10
>>>
>>> [wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
>>>
>>> 172.67.75.10
>>>
>>> 104.26.3.229
>>>
>>> 104.26.2.229
>>>
>>> [wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
>>>
>>> 172.64.80.1
>>>
>>>
>>>
>>> Is anyone from Cloudflare of the list that can assist with resolving
>>> this?  Anyone have a contact at Cloudflare they can share to get this
>>> resolved for the school district?
>>>
>>
>> I don't really see the problem here -- all of the addresses returned seem
>> to be valid CloudFlare addresses, and (I think) that all of them are
>> answering correctly for deltamath.com.
>> Nameservers routinely answer with different answers to split the load
>> between different VIPS, provide answers which they think are "better" for
>> specific queriers, etc. As long as the servers returned are behaving
>> correctly, CF can return basically whatever they like.
>>
>> Of course, it's entirely possible/likely that I completely misunderstood
>> the issue/question.
>> W
>>
>>
>>
>>
>>
>>>
>>>
>>> --
>>>
>>> William Brown
>>>
>>> WNYRIC/Erie 1 BOCES
>>>
>>> 716-821-7285
>>>
>>>
>>>
>>> SharePoint, Eforms, Email, Spam Filtering Please reach out to
>>> messag...@e1b.org
>>>
>>> Immediate Needs Call our Service Desk at 716-821-7171
>>>
>>>
>>> Confidentiality Notice: This electronic message and any attachments may
>>> contain confidential or privileged information, and is intended only for
>>> the individual or entity identified above as the addressee. If you are not
>>> the addressee (or the employee or agent responsible to deliver it to the
>>> addressee), or if this message has been addressed to you in error, you are
>>> hereby notified that you may not copy, forward, disclose or use any part of
>>> this message or any attachments. Please notify the sender immediately by
>>> return e-mail or telephone and delete this message from your system.
>>> ___
>>> dns-operations mailing list
>>> dns-operations@lists.dns-oarc.net
>>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>>>
>>
>>
>> --
>> The computing scientist’s main challenge is not to get confused by the
>> complexities of his own making.
>>   -- E. W. Dijkstra
>> ___
>> dns-operations mailing list
>> dns-operations@lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>>
>
>
> --
> http://www.columbia.edu/~ebk2141/
>
-- 
Perhaps they really do strive for incomprehensibility in their specs.
After all, when the liturgy was in Latin, the laity knew their place.
-- Michael Padlipsky
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Oddness with Cloudfare authoritative servers

[Warren Kumari]

On Wed, Sep 22, 2021 at 1:01 PM Brown, William  wrote:

> We have a school district that is trying to resolve the domain
> deltamath.com.  This issue is impacting the classroom use of this service.
>
>
>
> The authoritative servers are tani.ns.cloudflare.com and
> jarred.ns.cloudfare.com.  Tani seems to work correctly.  Jarred however,
> will return two different results:
>
>
>
> Here are the results of four tries within a few seconds:
>
>
>
> [wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
>
> 172.67.75.10
>
> 104.26.2.229
>
> 104.26.3.229
>
> [wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
>
> 104.26.2.229
>
> 104.26.3.229
>
> 172.67.75.10
>
> [wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
>
> 172.67.75.10
>
> 104.26.3.229
>
> 104.26.2.229
>
> [wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
>
> 172.64.80.1
>
>
>
> Is anyone from Cloudflare of the list that can assist with resolving
> this?  Anyone have a contact at Cloudflare they can share to get this
> resolved for the school district?
>

I don't really see the problem here -- all of the addresses returned seem
to be valid CloudFlare addresses, and (I think) that all of them are
answering correctly for deltamath.com.
Nameservers routinely answer with different answers to split the load
between different VIPS, provide answers which they think are "better" for
specific queriers, etc. As long as the servers returned are behaving
correctly, CF can return basically whatever they like.

Of course, it's entirely possible/likely that I completely misunderstood
the issue/question.
W





>
>
> --
>
> William Brown
>
> WNYRIC/Erie 1 BOCES
>
> 716-821-7285
>
>
>
> SharePoint, Eforms, Email, Spam Filtering Please reach out to
> messag...@e1b.org
>
> Immediate Needs Call our Service Desk at 716-821-7171
>
>
> Confidentiality Notice: This electronic message and any attachments may
> contain confidential or privileged information, and is intended only for
> the individual or entity identified above as the addressee. If you are not
> the addressee (or the employee or agent responsible to deliver it to the
> addressee), or if this message has been addressed to you in error, you are
> hereby notified that you may not copy, forward, disclose or use any part of
> this message or any attachments. Please notify the sender immediately by
> return e-mail or telephone and delete this message from your system.
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] why does that domain resolve?

[Warren Kumari]

On Tue, Jun 8, 2021 at 6:03 AM Mark Delany  wrote:

> On 07Jun21, Giovane C. M. Moura via dns-operations allegedly wrote:
>
> > FWIW, we did a study a couple of years ago [1] analyzing these
> > inconsistencies. We found 13 million second-level domains (out of 166M)
> > that were inconsistent [0] (table 1, data from 2019-10-16)
>
> Asking for a friend. Did you use a tool that is generally available to the
> average Joe
> such that they can test their own domains?
>
> The most common DNS support questions I get from small-time dns admins
> invariably revolve
> around discrepancies between delegation, name servers and hidden masters.
>

Related to this, does anyone have a list of good web based "DNS checkers"?
I *feel* like there used to be a number of good tools, but I managed to
throw away that set of bookmarks. There are still many "test your recursive
servers " pages, but I'm looking for something that tests
authoratives, and walks all possible paths, checks for v4 and v6, MTU, etc.

At the moment the main site that I'm recommending for this is IIS.SEs
Zonemaster - https://zonemaster.iis.se/ and DNSViz.

Zonemaster is really close, but I'd like a few other options as well.
DNSViz is, of course, excellent for DNSSEC debugging, but it can be fairly
confusing to less experienced people trying to debug non-DNSSEC issues.

So, what are people's favorite tools, especially those that you can just
point a user at?

W



>
> I use a home-grown command-line tool which sorta, kinda works, but it's
> rough. For
> example, here's what it says about apple.com:
>
> apple.com. Errors: 12
>IP a.ns.apple.com./2620:149:ae0::53 in Name Server:c.ns.apple.com./
> 204.19.119.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./
> 192.5.6.30
>IP b.ns.apple.com./2620:149:ae7::53 in Name Server:c.ns.apple.com./
> 204.19.119.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./
> 192.5.6.30
>IP a.ns.apple.com./2620:149:ae0::53 in Name Server:d.ns.apple.com./
> 204.26.57.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./
> 192.5.6.30
>IP b.ns.apple.com./2620:149:ae7::53 in Name Server:d.ns.apple.com./
> 204.26.57.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./
> 192.5.6.30
>IP a.ns.apple.com./2620:149:ae0::53 in Name
> Server:c.ns.apple.com./2620:171:800:714::1 but not in delegation ;;
> AUTHORITY/a.gtld-servers.net./192.5.6.30
>IP b.ns.apple.com./2620:149:ae7::53 in Name
> Server:c.ns.apple.com./2620:171:800:714::1 but not in delegation ;;
> AUTHORITY/a.gtld-servers.net./192.5.6.30
>IP a.ns.apple.com./2620:149:ae0::53 in Name
> Server:d.ns.apple.com./2620:171:801:714::1 but not in delegation ;;
> AUTHORITY/a.gtld-servers.net./192.5.6.30
>IP b.ns.apple.com./2620:149:ae7::53 in Name
> Server:d.ns.apple.com./2620:171:801:714::1 but not in delegation ;;
> AUTHORITY/a.gtld-servers.net./192.5.6.30
>IP b.ns.apple.com./2620:149:ae7::53 in Name Server:b.ns.apple.com./
> 17.253.207.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./
> 192.5.6.30
>IP a.ns.apple.com./2620:149:ae0::53 in Name Server:b.ns.apple.com./
> 17.253.207.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./
> 192.5.6.30
>IP b.ns.apple.com./2620:149:ae7::53 in Name Server:a.ns.apple.com./
> 17.253.200.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./
> 192.5.6.30
>IP a.ns.apple.com./2620:149:ae0::53 in Name Server:a.ns.apple.com./
> 17.253.200.1 but not in delegation ;; AUTHORITY/a.gtld-servers.net./
> 192.5.6.30
>
> Which is a lot of verbosity to say the glue from a.gtld-servers.net (and
> presumably all
> other GTLD servers) lacks the ipv6 addresses for a.ns.apple.com and
> b.ns.apple.com yet
> they're present in the in-bailiwick name servers.
>
> This of course is a minor matter rather than a fault, but it does mean
> that the ipv6 name
> servers will get a vastly reduced set of queries compared to all other
> name servers. To my
> mind this is indicative of an oversight on the domain admin's front.
>
> I'll really like to upgrade to a clearer command-line tool which can be
> incorporated into
> a zone update work-flow so that my friends can immediately know when they
> have messed
> up.
>
> Does such a beast exist?
>
>
> Mark.
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] IMPORTANT: Please ensure your NSEC3 iteration count is sufficiently low

[Warren Kumari]

On Fri, Apr 16, 2021 at 3:04 PM Viktor Dukhovni 
wrote:

> On Fri, Apr 16, 2021 at 02:29:07PM -0400, Puneet Sood via dns-operations
> wrote:
>
> > Google Public DNS is also planning to cap NSEC3 iterations to a safe
> value.
> > Do you have data you can share on the prevalence of high iteration count
> > NSEC3 zones?
>
> Sure, below are the absolute, percentile, and cumulative percentile
> frequencies by iteration count for ~10.9 million domains using NSEC3.
> The cumulative numbers are from 0 iterations up, but the table below is
> in reverse order, showing the high iterations first, I hope that's not
> too confusing.
>
> The suggested cutoff is presently at 150, with just 279 zones out of
> 10.9 million using more than 150 iterations.



Thank you for doing this work - it’s helpful.

Do you happen to have the list of the 279 anywhere? I realize that it
*shouldn’t* matter, but if some of these are really “popular” domains the
calculation is different to them being domains which get almost no traffic.
Also, perhaps we can do some outreach to the affected domains if easy?

W


>
>#iters   #zones   %zones  cumulative%
>--   --   --  ---
>  40961   0. 100.
>  25003   0. 100.
>  20001   0. 100.
>  1600   50   0.0005 100.
>  13372   0.  99.9995
>  10241   0.  99.9995
>   500   67   0.0006  99.9995
>   4871   0.  99.9989
>   4231   0.  99.9988
>   4006   0.0001  99.9988
>   3601   0.  99.9988
>   3333   0.  99.9988
>   330   56   0.0005  99.9987
>   3004   0.  99.9982
>   250   61   0.0006  99.9982
>   2003   0.  99.9976
>   1971   0.  99.9976
>   177   17   0.0002  99.9976
>   --- suggested cutoff -
>   150 5070   0.0464  99.9974
>   149   21   0.0002  99.9510
>   1286   0.0001  99.9508
>   127 2956   0.0271  99.9508
>   1201   0.  99.9237
>   107   15   0.0001  99.9237
>   1011   0.  99.9236
>   100   978251   8.9571  99.9236
>995   0.  90.9665
>961   0.  90.9664
>90   20   0.0002  90.9664
>85   26   0.0002  90.9662
>818   0.0001  90.9660
>801   0.  90.9659
>75   33   0.0003  90.9659
>691   0.  90.9656
>64   16   0.0001  90.9656
>551   0.  90.9654
>541   0.  90.9654
>531   0.  90.9654
>52   18   0.0002  90.9654
>511   0.  90.9652
>5011837   0.1084  90.9652
>431   0.  90.8569
>42   16   0.0001  90.8568
>4050605   0.4634  90.8567
>35   12   0.0001  90.3933
>341   0.  90.3932
>33  697   0.0064  90.3932
>32   74   0.0007  90.3868
>314   0.  90.3862
>30   12   0.0001  90.3861
>25   27   0.0002  90.3860
>24   66   0.0006  90.3858
>23   20   0.0002  90.3852
>224   0.  90.3850
>21 5383   0.0493  90.3849
>20   510107   4.6707  90.3357
>195   0.  85.6650
>188   0.0001  85.6649
>17   13   0.0001  85.6649
>1614801   0.1355  85.6648
>15 4113   0.0377  85.5292
>14   19   0.0002  85.4916
>13   88   0.0008  85.4914
>12   302246   2.7674  85.4906
>11  106   0.0010  82.7232
>10  1204263  11.0265  82.7222
> 9   40   0.0004  71.6957
> 8  1168469  10.6988  71.6953
> 725308   0.2317  60.9965
> 6   55   0.0005  60.7648
> 5  1366608  12.5130  60.7643
> 4   40   0.0004  48.2513
> 328243   0.2586  48.2509
> 2 3816

Re: [dns-operations] Google ECS caching issue, looking for contact

[Warren Kumari]

Replied off-list.

W

On Wed, Jan 6, 2021 at 6:25 PM Jeff Westhead via dns-operations
 wrote:
>
>
>
>
> -- Forwarded message --
> From: Jeff Westhead 
> To: "dns-operati...@dns-oarc.net" 
> Cc:
> Bcc:
> Date: Wed, 6 Jan 2021 23:17:38 +
> Subject: Google ECS caching issue, looking for contact
>
> Hello! We are seeing some misrouting impact because a CNAME that we intended 
> to be cached at /24 is being cached at global scope by 8.8.8.8. Anyone here 
> from Google who could look into the specifics for me?
>
>
>
>
> -- Forwarded message --
> From: Jeff Westhead via dns-operations 
> To: "dns-operati...@dns-oarc.net" 
> Cc:
> Bcc:
> Date: Wed, 6 Jan 2021 23:17:38 +
> Subject: [dns-operations] Google ECS caching issue, looking for contact
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

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

Re: [dns-operations] https://secure-web.cisco.com/1ZjyzJskkYQq7sVMAaORAQUNbtLnCDdiphJXoIUgaA7_oFL6tHC8iV070aZrCZfTyULjhkVi3xJfW5opBdNn-YVZVvneE8CazN4a3cBB_5D0ERlfp-D-9kGVsbAT_XzThiOOKiL1K02Z_t969017Ug

[Warren Kumari]

Ah all sorted then.

Thanks Duane,
W

On Mon, Nov 9, 2020 at 3:30 PM Wessels, Duane  wrote:
>
>
>
> > On Nov 9, 2020, at 11:44 AM, Warren Kumari  wrote:
> >
> > Erm, what sort of glitch? (seems to work for me - wondering if it is
> > transient, or ...)
>
>
> It was easily fixed.  The glitch was a bug in the backend script such that 
> every request led to an "Internal Server Error".
>
> DW
>
>


-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] https://trans-trust.verisignlabs.com/

[Warren Kumari]

Erm, what sort of glitch? (seems to work for me - wondering if it is
transient, or ...)

In the meantime, you can try https://www.superficialinjurymonkey.com/
(click DNS Delegation Explorer), it might work for $whatever
trans-trust didn't. Note that this was thrown together while sitting
on a plane, watching Top Gear reruns.

It's likely full of bugs/may explode, killing everyone inside...

W

On Mon, Nov 9, 2020 at 4:18 AM Calvin Browne  wrote:
>
> Hi Guys,
>
>
> seems https://trans-trust.verisignlabs.com/ has developed a glitch - anyone 
> know who to poke (with thanks of course).
>
>
> regards
>
>
> --Calvin
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Strange behavior of covid.cdc.gov

[Warren Kumari]

On Mon, Aug 31, 2020 at 9:23 AM Yasuhiro Orange Morishita / 森下泰宏
 wrote:
>
> Hi,
>
> Now covid.cdc.gov seems to be DNSSEC validation error.
> Google Public DNS and some DNSSEC-enabled resolvers return SERVFAIL.
> e.g. dig covid.cdc.gov @8.8.8.8
>
> But it seems to be a little bit strange.  The auth servers of cdc.gov
> zone serve unneed (and unsigned) akam.cdc.gov zone.  But they still
> have DS RR for real akam.cdc.gov zone.
>
> This is output of digs.
> 

... and for those of us who prefer the pretty graph version:
https://dnsviz.net/d/covid.cdc.gov/dnssec/

Another thing that is interesting is:
$ dig covid.cdc.gov @ns1.cdc.gov

[SNIP]

;; ANSWER SECTION:
Covid.cdc.gov. 3600 IN CNAME covid.akam.cdc.gov.
covid.akam.cdc.gov. 3600 IN CNAME covid.cdc.gov.edgekey.net.

The uppercase 'C' in the 'Covid.cdc.gov. 3600 IN CNAME
covid.akam.cdc.gov.' from the auth is interesting... Not wrong, just
interesting...

W



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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

Re: [dns-operations] New OARC Chat Platform

[Warren Kumari]

On Tue, Aug 25, 2020 at 12:10 PM Paul Ebersman
 wrote:
>
> warren> We've often discussed if the tools are useful / doing what we
> warren> want. My concern with this is that it requires yet another app
> warren> installed for people to communicate;
>
> I'm one of the first to bitch about this when I have to install yet
> another app.
>
> However, mattermost works fine in a browser, no app required. I was on
> firefox for the last OARC virtual meeting and had no issues with that
> method.

Thank you, that helps. I think that much of my discomfort stems from
the fact that this felt like "We, the leadership have made a decision
for you, the community".
There are many many places where we want the board / org to make
decisions on our behalf, but for maintaining a sense of community,
having input on how the community interacts and discusses things feels
important...
After some reflection, I've realized that I'm not actually annoyed by
having to run another app, it is that I feel that I / we were not
asked (and here is where someone will point at the long thread where
this was discussed, and I look like even more of a jackass :-)).

W

>
> dougb> I ask because OARC is taking on a lot, and from my naive and
> dougb> distant view seems to have developed a bit of NIH
> dougb> syndrome. Looking at the migration of dnsviz for example, it's
> dougb> not clear to me why OARC volunteered to take that project on
> dougb> without adequate resourcing. And subsequently it wasn't clear why
> dougb> cloud solutions weren't utilized, which I imagine could have been
> dougb> cheaper, and faster. To my knowledge the historical data is still
> dougb> missing, is that correct?
>
> I'd guess you're not a member and don't get the detailed breakdown of
> this in the member reports? Short version is that many of the decisions
> (including why cloud frequently isn't an option) boil down to member
> survey responses and restrictions in the data sharing agreements.
>
> Keith and the OARC staff evaluate choices based on these restrictions
> and then solicit member input before making final decisions.
>
> What you are seeing is not unilateral decisions by the staff but the
> staff implementing membership wishes.



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] New OARC Chat Platform

[Warren Kumari]

On Tue, Aug 25, 2020 at 10:44 AM Ondřej Surý  wrote:
>
> > On 25. 8. 2020, at 15:52, Barry Raveendran Greene  wrote:
> >
> > Can we see the security risk assessment that OARC has done with Slack? That 
> > would be contrasted with the parallel risk assessment for MatterMost.
>
> This would neither be a time well spent by the OARC team that has
> a limited resources that would be better spent on actually working
> on the primary OARC missing.
>
> I don’t see a strong need to linger on the topic any further,
> the decision was made by the OARC team and sanctioned by the OARC board.
>
> What useful purpose does this have?  We have never questioned the choice
> of tools by the OARC team, so we should not start doing so now.

We've often discussed if the tools are useful / doing what we want. My
concern with this is that it requires yet another app installed for
people to communicate; by doing this OARC is taking a solution which a
number of people were using (Jabber), and said "Nope, you have to go
install yet another application" - unlike other OARC tools this isn't
"use your existing tools like dig and a browsers", it's "go and
install yet another app". Also, some organizations lock down what apps
can run on their corporate machines

I've already got (at least):
1: Adium for Jabber (IETF, OARC, and a number of other services)
2: Slack (12+ workspaces)
3: Telegram
4: Wire
5: Textual (IRC)
6: WhatsApp
7: iMessage
8: Skype

https://xkcd.com/1810/

> This
> is a rathole that nobody really wants to go in.

Ah, excellent. Just like with the above decision, thank you for
telling me what I want...

Message received,
W

>
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@sury.org
>
>
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

Re: [dns-operations] [Ext] Re: Separating .ARPA operations from the root zone

[Warren Kumari]

This seems to have died down, so I figured I'd ask if you'd managed to
pull anything like consensus out of it?

I intentionally didn't comment on the proposal, because, in my view
it's none of my business -- this is a purely operational change. The
IANA is responsible for making sure that lookups for things in .ARPA
resolve correctly; if decoupling it from the current architecture and
serving it using e.g a lightly toasted eggplant results in something
easier/better/stronger/faster, that's entirely the IANA's call.

It's nice to publish the plans and ask if it's going to break
anything/if anyone sees any issues (the root and arpa are somewhat
unusual), but as long as the queries still get answered correctly, how
you do so should be entirely your business.

The IANA is competent enough that if you say this will make things
better, I have no reason to doubt it.

W

On Fri, Aug 14, 2020 at 5:19 PM Kim Davies  wrote:
>
> Hi Paul,
>
> Quoting Paul Wouters on Wednesday August 12, 2020:
> >
> > > My take is this is a high-level expression of an operational change
> > > that is notable, but the details that would underly its implementation
> > > are not. Of course detailed plans are needed by the operator and other
> > > directly involved parties, as is the case of any other zone, but such
> > > ephemeral details are probably not best suited for RFCs.
> >
> > I am confused as to what would happen. Either, the root zone operators
> > will drop the .arpa zone, or they will keep serving it under a new
> > agreement.
>
> It is worth noting that basically the entire publication and distribution of
> the arpa zone is not contracted or otherwise covered by any agreements:
>
> * The RZMA, where ICANN contracts Verisign to produce and disseminate the
>   root zone to the RSOs, has no mention of .arpa;
>
> * Agreements that exist right now for individual RSOs don't mention .arpa
>   ;
>
> * RFC 2870, while superseded, for a long time stood stating root servers
>   "MUST NOT provide secondary service for any zones other than the root
>   and root-servers.net zones"
>
> > If they keep servigin it, either they will use the same
> > nameservers as for the root, or they will use different nameservers. If
> > they use the same nameservers, then in practise nothing will change except
> > some paperwork and people will still not want the new fancy RRTYPEs in
> > the .arpa zone. If they will use different servers, why can't they do
> > that right now?
>
> Changing the hostnames of the nameservers appears to be a precursor to any
> other kind of reconfiguration. It seems certain that .arpa can't have any
> meaningfully differentiated service so long as it is using
> {a-i,k-m}.root-servers.net as its NS-set.
>
> But that doesn't mean the end goal is necessarily full separation!
>
> The only concrete outcome proposed in this document is those hostname
> changes, and there is text that notes fuller separation would comprise
> changes in other areas as well. I think the need to progress down those
> paths, and the pace required, will depend on a number of factors such
> as whether there are new demands for the zone and whether the current
> parties are willing to continue their roles. Just as for any other zone
> operator, changes in the operational environment and evolving demands
> for the zone will inform future planning.
>
> > I am concerned that de-coupling .arpa might lead to the zone being
> > underserved. Or that IETF needs to start budgeting for running this
> > zone in the future itself. That might lead to instability as we
> > currently don't even have enough money to pay salaries due to a
> > pandemic and are temporarilly charging for things that we normally
> > do for free (online participation).
> > So from a risk management point of view, I see no reason for the
> > IETF to make a change, unless we can guarantee some longterm plan
> > for financing running the .arpa domain.
>
> Because of the lack of contracts or agreements noted above, I don't
> think there are any fundamental guarantees of service today and
> presumably the current operators could withdraw service at their
> discretion. Leaving the current configuration unmodified provides no
> certainty of future success.
>
> Identifying the proper operational expectations, and putting in place
> any necessary agreements around that, I think is a component of maturing
> the approach. Given running this domain is part of the IANA functions,
> my assumption is any additional costs borne in operating it would likely
> be borne as part of how the IANA functions are funded. This would mean
> there would be public review and engagement process associated with
> budget development on an annual basis.
>
> kim
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
I don't 

[dns-operations] Deep Dive on the DNS - Tomorrow (Thursday, July 23, 2020 - 18:00-19:30 UTC)

[Warren Kumari]

Hi all,

A reminder that the IETF Technology Deep Dives on the DNS is tomorrow,
Thursday, July 23, 2020  - 18:00-19:30  UTC.

Everyone understands how the Domain Name System (DNS) works, but
everyone is wrong!
During this Technical Deep Dive on the DNS you will learn *just how
wrong you are*


More information can be found at: https://www.ietf.org/live/ietf108-tdd-dns/
Links, etc are in the agenda - https://datatracker.ietf.org/meeting/108/agenda/

This session is open to all - having a Datatracker account will make
it easier to participate, but the session will also be streamed -
https://youtu.be/DV0q9s94RL8

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] .iq contacts?

[Warren Kumari]

On Thu, May 28, 2020 at 7:43 PM Warren Kumari  wrote:

>
>
> On Thu, May 28, 2020 at 6:32 PM Ray Bellis  wrote:
>
>>
>>
>> On 28/05/2020 22:56, Viktor Dukhovni wrote:
>>
>> > Indeed this looks rather precarious, and the SOA serial number is not
>> > any higher on the other remaining server, the expiration time is 7 days,
>> > so not much time left if the primary went down in the 21st.
>> >
>> > The MX record for cmc.iq is: cmc.iq. IN MX 0 in.hes.trendmicro.eu.
>> This
>> > might be useful for reaching "hostmas...@cmc.iq" should the zone expire
>> > in the meantime.  IANA lists a technical contact of "it...@cmc.iq":
>> > <https://www.iana.org/domains/root/db/iq.html>
>>
>> The ISC SNS service was actually due to be shut down on January 31st but
>> there's been a few malingerers, including .iq
>>
>> We've been trying to reach them for *months* via many different comms
>> channels, to no avail.
>>
>
> Well, perhaps this will finally get someone’s attention then...
>
> Sorry for the snark, but I’d previously spent many many hours trying to
> reach iq admins before giving up in disgust...
>

I’d like to apologize for this mail — it was sent in haste and
unnecessarily snarky.

My previous frustration was more than 10 years ago; that’s a really long
time back, and things (and the people working there) have likely changed
since.

Please accept my apologies (both the iq admins, and the list) - it was
uncalled for, and not helpful...

W




> W
>
>
>
>> However this potential failure of all listed NS servers makes this
>> somewhat more urgent.
>>
>> Ray
>>
>> ___
>> dns-operations mailing list
>> dns-operations@lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>>
> --
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair of
> pants.
>---maf
>
-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] .iq contacts?

[Warren Kumari]

On Thu, May 28, 2020 at 6:32 PM Ray Bellis  wrote:

>
>
> On 28/05/2020 22:56, Viktor Dukhovni wrote:
>
> > Indeed this looks rather precarious, and the SOA serial number is not
> > any higher on the other remaining server, the expiration time is 7 days,
> > so not much time left if the primary went down in the 21st.
> >
> > The MX record for cmc.iq is: cmc.iq. IN MX 0 in.hes.trendmicro.eu.  This
> > might be useful for reaching "hostmas...@cmc.iq" should the zone expire
> > in the meantime.  IANA lists a technical contact of "it...@cmc.iq":
> > 
>
> The ISC SNS service was actually due to be shut down on January 31st but
> there's been a few malingerers, including .iq
>
> We've been trying to reach them for *months* via many different comms
> channels, to no avail.
>

Well, perhaps this will finally get someone’s attention then...

Sorry for the snark, but I’d previously spent many many hours trying to
reach iq admins before giving up in disgust...

W



> However this potential failure of all listed NS servers makes this
> somewhat more urgent.
>
> Ray
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] looking for suggestion: ML for DNS anti-dos

[Warren Kumari]

On Thu, Apr 2, 2020 at 9:38 AM Tessa Plum  wrote:
>
> Hello
>
> I am not familiar with DNS servers, trying my hard to learn it.
> I am a researcher on ML/DL field.
> Just got a thought, do you think if it's possible to improve DNS
> anti-dos capability by deep learning?
> As we know, ML/DL is just statistics science based on big data.
> If we have got huge data to differ which are normal requests, which are
> bad requests, thus we could train the system to identify them
> automatically. And we expect to have a system who can handle zero day
> attack.
> How do you think of it?

I'm assuming you have already read:
"DNS-ADVP: A Machine Learning Anomaly Detection and Visual Platform to
Protect Top-Level Domain Name Servers Against DDoS Attacks," , L. A.
Trejo, V. Ferman, M. A. Medina-Pérez, F. M. Arredondo Giacinti, R.
Monroy and J. E. Ramirez-Marquez, in IEEE Access, vol. 7, pp.
116358-116369, 2019 -
https://ieeexplore.ieee.org/abstract/document/8744546

"Mitigating DNS query-based DDoS attacks with machine learning on
software-defined networking," M. E. Ahmed, H. Kim and M. Park, MILCOM
2017 - 2017 IEEE Military Communications Conference (MILCOM),
Baltimore, MD, 2017, pp. 11-16. -
https://ieeexplore.ieee.org/abstract/document/8170802

Detection of DDoS DNS Amplification Attack Using Classification
Algorithm - Meitei, Singh, De -
https://dl.acm.org/doi/10.1145/2980258.2980431

Machine Learning Based DDoS Attack Detection From Source Side in Cloud
- Zecheng He, Tianwei Zhang, Ruby B. Lee - Princeton -
http://palms.princeton.edu/system/files/Machine_Learning_Based_DDoS_Attack_Detection_From_Source_Side_in_Cloud_camera_ready.pdf

(roughly in that order)? There are many others, and a bunch of really
excellent presentations more on the registration side, but those have
good overlap with what you were asking...
One thing to keep in mind is that DNS traffic is a VERY noisy data
source, and corrupt / pathologic queries are incredibly common..

W

>
> Thank you.
>
> Tessa
> https://plum.ovh/
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

Re: [dns-operations] [Ext] Re: Contingency plans for the next Root KSK Ceremony

[Warren Kumari]

On Tue, Mar 31, 2020 at 3:40 PM Dave Lawrence  wrote:
>
> Grant Taylor via dns-operations writes:
> > I fail to see how any government would prevent the necessary parties
> > from attending if / when they fully understand the need.  Especially
> > when some of said governments have directives ~> mandates for use of DNSSEC.
>
> It could turn into a real-life movie thriller.  The government puts
> TCRs on special ops jets to fly off to a command center full of a
> million displays so that they can complete their vital re-signing
> mission.  The clock is ticking ...

Interesting -- my thriller was more: The gubbermint significantly
increases, and then starts enforcing the lockdown. The TCRs heroically
struggle to break through the barriers and cordons which surround the
Culpeper site[0]. This provides many opportunities for "Smokey and the
Bandit" style car chases, Anne-Marie Eklund-Löwinder piloting a
cigarette boat up the Potomac River, Joao abseiling out of a
helicopter, Subramanian doing a HALO jump from a balloon, Frederico
(in full camo gear) stalking through the forest while avoiding dogs,
and Chuck Norris roundhouse kicking everyone (just because).
But, yes, of course mine also has a large, red countdown clock showing
the time remaining till the signatures expire and the Internet deletes
itself...

W
[0]: Why is it centered on Culpeper? Because the govmnt heard that the
TCRs were coming and planning on blatantly ignoring the lockdown
order. This *of course* requires full mobilization of the navy (yay,
submarines), airforce (wheee, big planes), army (tanks and, um,...
more tanks?), FBI (oooh! sharp suits and dark glasses), green berets
(just like it says on the tin) and CIA (something, something, lasers,
something, overthrow foreign governments and install a friendly
dictator, self-destructing messages, something.). Oh, and the NSA to
quickly factor the new key before it is even generated...

Me thinks I may have been spending too much time indoors recently

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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

Re: [dns-operations] [Ext] Re: Contingency plans for the next Root KSK Ceremony

[Warren Kumari]

On Fri, Mar 27, 2020 at 5:46 AM Erwin Lansing via dns-operations
 wrote:
>
>
>
>
> -- Forwarded message --
> From: Erwin Lansing 
> To: Kim Davies 
> Cc: Sergey Myasoedov , "dns-operati...@dns-oarc.net" 
> 
> Bcc:
> Date: Fri, 27 Mar 2020 10:34:51 +0100
> Subject: Re: [dns-operations] [Ext] Re: Contingency plans for the next Root 
> KSK Ceremony
> Hi Kim,
>
> > On 27 Mar 2020, at 01.55, Kim Davies  wrote:
> >
> > Hopefully our approach does not depend solely on TCRs for confidence.
> > We've consciously sought to operate a highly transparent process
> > that allows anyone who is interested - not just TCRs - to witness
> > proceedings and be involved, either in person or remotely. Further,
> > we are audited by a third-party audit firm using the SOC 3 framework
> > (formerly SysTrust), and have received unqualified opinions each year
> > since we first started in 2010: https://www.iana.org/about/audits
> >
> > Another key protection is we seek to disseminate all the relevant
> > materials from the ceremony. All audit footage, software used, and
> > the logs and artefacts generated are posted online for download and
> > inspection.
> >
> > Certainly if there is a perception that trust hinges critically on TCRs,
> > we've either not communicated the breadth of the controls well enough,
> > or we need to do more to instill trust. Just as the security envelope
> > for the KSK involves multiple overlapping physical security controls,
> > maintaining trust in KSK management should involve multiple overlapping
> > trust mechanisms to satisfy the community.
>
> I think you hit the nail on the head here: it’s all about perception.

Yup - just like a bank (or currency), the primary concern is the
perception of trust. For the sake of argument, let's pretend I don't
trust Kim et al at all / have some agenda to call the security /
stability of DNSSEC into question.

So, the safes get drilled; on camera and with all of TCRs (and their
aunties) watching. Everyone watches the ceremony, and everyone agrees
that everything went perfectly and there were no shenanigans -- what
happens *after* the ceremony?
How can we prove that nothing bad occurred after the ceremony
concluded and the cameras were turned off? I'm assuming that new locks
will be installed, and materials returned to their rightful places,
but this still leaves Kim et al with a big pile-o-keys that they could
use. We could probably stick (on camera) numbered tamper evident seals
over the locks, and have Kim sign them, but now we have devolved the
security to just numbered stickers / numbered bags and the signature
of the same person/people who have the pile-o-keys.

Before people get all up in arms, no, I'm not suggesting that IANA is
actually going to sneak in after the cameras are turned off and
, and I also recognize that these are
exceptional circumstances - what I'm trying to do is figure out how we
accomplish this while maintaining the actual and *perceived* trust in
the system -- it would be very sad if a few months from now we realize
that there was something really simple that we could have done to
maintain the trustworthiness, but didn't think of... The IANA and TCRs
have invested heavily in maintaining the trust in the system - I'd
hate to see that lost because we didn't think of something we could
have (easily) done...

We also need to ensure that we don't end up too much in the tin foil
hat camp, but  I don't think I've seen any discussion of what happens
after the ceremony and think it would be useful to try and cover the
re-securing phase (of course, it is entirely possible I missed it...)

W

> No matter how many other controls and layer of security, drilling a safe 
> bring up certain images in peoples minds. For that reason alone, I’d also 
> rather avoid that solution, but extraordinary circumstances require 
> extraordinary solutions. As you say, the process is a transparent as it can 
> be, and with enough emphasis on the existing, and possibly extra, security 
> measures, it should be no problem to dispel that perception, and it may well 
> be the most practical way to go.
>
> Best,
> Erwin
>
>
>
> -- Forwarded message --
> From: Erwin Lansing via dns-operations 
> To: Kim Davies 
> Cc: "dns-operati...@dns-oarc.net" 
> Bcc:
> Date: Fri, 27 Mar 2020 10:34:51 +0100
> Subject: Re: [dns-operations] [Ext] Re: Contingency plans for the next Root 
> KSK Ceremony
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net

Re: [dns-operations] DNSViz Service Restoration

[Warren Kumari]

On Wed, Mar 11, 2020 at 3:44 PM Matthew Pounsett  wrote:
>
> Hi all!
>
> OARC is happy… no, ecstatic… to announce that the DNSViz historical functions 
> have been restored!  Users will now be seeing full functionality from the 
> site at .
>

Awesome, thank you all.

> A few weeks ago we made the decision to temporarily put aside the attempt to 
> completely restore the old historical data and instead stand up a new, empty 
> database so that we could get the full featureset online.  So, for now there 
> is no access to old tests run prior to the service’s move to OARC, however 
> new tests will be available for review.
>
> We’re continuing to work to restore the full historical database; we hope 
> that with the pressure off, and the temptation to cut corners in order to 
> speed up the process removed, we can restart the import from scratch with a 
> slower—but more reliable—approach to recovering those data.


Excuse my not remembering, but have y'all confirmed that this is
really worth the faff? What *I* care about is being able to use the
service *from now on*- going back and seeing the breakage of
foo.example.net in 2018 is only mildly interesting, but certainly not
(to me!) worth your time and effort...

W

>
> I’d like to thank everyone again for your patience with this whole saga.
>
> Matt Pounsett
> DNS-OARC Systems Engineering
>
>
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

[dns-operations] ... one of the more annoying captive portal breakages I've seen...

[Warren Kumari]

So, I'm sitting in a hotel in Melbourne (APRICOT20), trying to get
some work done[0].

They have a captive portal which a: logs you our fairly often and b:
requires you use their DNS server. Ugh, but OK.

..but, they have managed to invent some new, and interesting failure
mode - if I look up a name which isn't in the cache, I *immediatly*
get back a SERVFAIL. Ask the question a bunch more times, and after a
few seconds you start getting an answer.

$ dig www.snozzages.com  | grep status
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47760
$ dig www.snozzages.com  | grep status
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3344
$ dig www.snozzages.com  | grep status
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48739
 [ continues for ~4 seconds ]
$ dig www.snozzages.com  | grep status
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3417
$ dig www.snozzages.com  | grep status
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58153
$ dig www.snozzages.com  | grep status
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23212

So, this is annoying, but kind-of possibly, if you squint really hard, OK.
but, the other failure mode (which I'm having a hard time capturing at
the moment) goes:
NXDOMAIN
NXDOMAIN
NXDOMAIN
ANSWER!

This behavior is baffling - other than intentionally, how do you
managed to break something this badly / in this way!?

Oh, I just needed to rant a bit...

W
[0]: Yeah, ok, I was trying to reach Reddit.

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

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

[Warren Kumari]

On Thu, Jan 23, 2020 at 3:39 PM Florian Weimer  wrote:
>
> * Warren Kumari:
>
> > On Wed, Jan 22, 2020 at 9:19 PM Viktor Dukhovni 
wrote:
> >>
> >> On Wed, Jan 22, 2020 at 10:13:40PM +, Tony Finch wrote:
> >>
> >> > Are there any registries that configure secure delegations from
DNSKEY
> >> > records (and do their own conversion to DS records) rather than
accepting
> >> > DS records from the registrant?
> >>
> >> In answer to the converse question, at least some registries appear to
> >> allow (or have allowed in the past) DS RRs with unverified content:
> >
> >
> > This actually seems OK to me -- nonsensical, but OK.
>
> It makes attacks on the underlying hash function for the DS record
> easier.  Constructing colliding prefixes is much harder if the prefix
> itself contains the hash over something else (because you also have to
> construct that something).

That's fair - but that's more of a (good) argument for the parent
calculating the DS from the DNSKEY than not allowing children to put in
things like unregistered algorithm/ hash types.  We’ve had lots of
deployment issues with things like restrictive registrar web interfaces
that don’t allow users to enter valid DS records because they haven’t been
updated yet; there is a trade off between protecting users from themselves,
and agility...

W





-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

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

[Warren Kumari]

On Wed, Jan 22, 2020 at 9:19 PM Viktor Dukhovni  wrote:
>
> On Wed, Jan 22, 2020 at 10:13:40PM +, Tony Finch wrote:
>
> > Are there any registries that configure secure delegations from DNSKEY
> > records (and do their own conversion to DS records) rather than accepting
> > DS records from the registrant?
>
> In answer to the converse question, at least some registries appear to
> allow (or have allowed in the past) DS RRs with unverified content:


This actually seems OK to me -- nonsensical, but OK. The DS record
"belongs" to the child, and so I feel like, as long as it isn't
harmful to the parent / the Internet, the child can put whatever
silliness in there that they would like.
If I chose to hand my parent an NS record with 192.168.0.22 as the
address, I'd expect them to publish it -- I understand (and
appreciate) that some ccTLDs perform sanity checks, and have various
policies they they will only accept "good" data, but that's an
explicit choice by them - absent such a policy, I think I should be
able to add a DS with algorithm 42, digest type of 17, and rdata of
badc0ffee.

If the parent makes the DS for me from my DNSKEY, well, then the DS
suddently "feels" like it belongs more to the parent than the child,
but this is starting to get into the "I no longer know why I believe
what I believe" territory (and is internally inconsistent), so I'll
just stop thinking about this and go shopping instead :-)


W

>
> domain   | alg | digest type
> -+-+
> .go.leg.br  |   8 |0
> .go.leg.br  |   8 |1
> .pr.leg.br |   8 |0
> .sp.leg.br   |   8 |0
> .se   |  13 |8
> .se|   8 |   61
>
> The above 5 (obfuscated) domains have DS RRs with digest types outside
> the registered IANA codepoints:
>
> https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml
>
> though the first also has a valid codepoint.
>
> Among domains with at least one valid DNSKEY at least two have
> additional keys with out of range codepoints, that were either not
> checked by the parent, or added after the initial DS enrolment:
>
>   domain| alg | flags | inception
> +-+---+
> .eu  | 157 | 0 | 
> .eu  |   7 |   256 |  -"-
> .eu  |   7 |   257 |  -"-
> .net |   7 |   256 |  -"-
> .net |   7 |   257 |  -"-
> .net | 165 |   512 | 2019-02-23
>
> --
> Viktor.
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

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

[Warren Kumari]

On Wed, Jan 22, 2020 at 7:12 PM Tony Finch  wrote:
>
> Warren Kumari  wrote:
> >
> > I believe that at least SIDN used to (and perhaps still does) - this
> > was one of the reasons that the CDS record is actually CDS/CDNSKEY.
> >
> > When I first heard this I was confused as to why they'd do this -- but
> > then Antoin Verschuren / Cristian explained that they'd like to make
> > sure that a good hash is being used, and suddenly I started wondering
> > why this isn't the default...:-)
>
> In fact I have made use of this! In more than one way!
>
> I did some work on BIND last year to implement RFC 8624 section 3.3 -
> death to SHA-1 DS records! But I left out the dnssec-cds utility
> (parent-side implementation of RFC 7344) which already defaulted to
> SHA-256. However during my cam.ac.uk algorithm rollover project
> (remember, folks, RSASHA1 is shafted) I found a lacuna:
>
> By default dnssec-cds copies CDS records to make DS records, and the
> question of SHA-256 or something else only arose when it was asked to turn
> CDNSKEY records into DS records. But if the CDS records are generated by
> some ancient code from before the dawn of time, such as BIND 9.14 on my
> production servers, there will be SHA-1 CDS records which will be copied
> to the DS records. Sadface, RFC 8624 protocol violation.
>
> So I fixed dnssec-cds to filter out SHA-1 CDS records.
>
> And, if the child turns out to have been so foolish as to use only SHA-1,
> dnssec-cds will now fall back to using the CDNSKEY records to make SHA-256
> DS records instead.
>

Oooh! Cool.


> In production for my child zones I've faked this by telling dnssec-cds
> (9.14 sans patch) to only look at CDNSKEY records.
>
> All in all this is a practical example of daddy knows best wrt choice of
> DS digest types.
>

Nice / fair 'nuff.
W

> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> Faeroes: Southwest 6 to gale 8, veering west 7 to severe gale 9. Very rough or
> high. Rain then wintry showers. Good, occasionally poor.



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

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

[Warren Kumari]

On Wed, Jan 22, 2020 at 5:26 PM Tony Finch  wrote:
>
> Are there any registries that configure secure delegations from DNSKEY
> records (and do their own conversion to DS records) rather than accepting
> DS records from the registrant?

I believe that at least SIDN used to (and perhaps still does) - this
was one of the reasons that the CDS record is actually CDS/CDNSKEY.

When I first heard this I was confused as to why they'd do this -- but
then Antoin Verschuren / Cristian explained that they'd like to make
sure that a good hash is being used, and suddenly I started wondering
why this isn't the default...:-)

I *think* that someone from .ca (perhaps Jacques or Matt) said that
they also allow DNSKEYs -- but this is all from 2014 timetrams, and my
memory is (sadly) paging that out...
W

> I think I have heard that .de is one.
> Looking at OpenSRS as an example of a registrar that supports lots of
> TLDs, I see that they don't support DNSSEC for .de
> http://opensrs.help/chart and their API only supports DS records
> https://domains.opensrs.guide/docs/set_dnssec_info
>
> Also, I am uncomfortable with the endianness of their support domain names...
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> responsible stewardship of the earth and its resources
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] Re: help with a resolution

[Warren Kumari]

[ Top-post ]

... and once again I understand the "Do not disagree with the
Dukhovni, for you will end up feeling foolish..." truism...

Somehow, even though I read (and re-read) the "chosen-prefix" part of
"chosen-prefix collision", for some reason when it came to DNSSEC I
felt that the *attacker* needed to be the one choosing the prefix
(because of the concatenation of the RRSIG RDATA and the RRSET)

I started reading Tony Finch's excellent blog post (
https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html ), all the
while shaking my head in disagreement...  and then read the "sort
after the innocuous prefix" phrase and the penny finally dropped.

Ok, I see the concern now, and *do* feel foolish for not getting it sooner...

Shame cube,
W

On Wed, Jan 8, 2020 at 7:12 PM Warren Kumari  wrote:
>
> On Wed, Jan 8, 2020 at 6:47 PM Viktor Dukhovni  wrote:
> >
> > On Wed, Jan 08, 2020 at 06:00:06PM -0500, Viktor Dukhovni wrote:
> >
> > > Well, there are various services where indeed the zone administrator signs
> > > records from authenticated, but otherwise untrusted customers, provided
> > > the RR owner is associated with the customer.
> > >
> > > For example, the .DE zone (which uses algorithm 8, so not subject to
> > > any SHA-1 issues) allows registrants that only need a handful of
> > > DNS records to have those records published directly in the .DE
> > > zone, without delegation.
> > >
> > > Other zones may make similar arrangements.
> >
> > Or more simply, when Let's Encrypt, or some cloud provider asks you to
> > publish a TXT RR in your zone to prove zone control, how sure are you
> > that's not a hash collision in disguise?
>
> It **could** be, but I'm still failing to see how they could use this
> -- LE asks me to publish:
>
> _acme-challenge.example.com 600 IN TXT "I_like_Cheese" in my zone, and
> I sign it.
>
> LE asks Bob to publish:
> _acme-challenge.example.net 600 IN TXT "I_like_Natchos" in his zone,
> and Bob signs it.
>
> I_like_Cheese and I_like_Natchos hash to the same output - 0x12345,
> and both Bob and I have signed it (actually, what get signed is the
> concatenation of the RRSIG RDATA and the RRSET, and so the LE doesn't
> really get to choose the prefix, but lets ignore that).
>
> Now the attacker (LE) has gotten both Bob and I to sign this, and when
> someone queries for _acme-challenge.example.com LE could inject
> "I_like_Natchos" instead of "I_like_Cheese" -- but both of these
> strings were messages under the attackers control anyway. Yes, I feel
> that there *might* be a way that this can be pivoted into something
> useful to the attacker, but I'm still not seeing it...
>
> W
>
>
> > --
> > Viktor.
> > ___
> > dns-operations mailing list
> > dns-operations@lists.dns-oarc.net
> > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Google DNS Admin

[Warren Kumari]

Here is a RIPE Atlas measurement towards that IP
https://atlas.ripe.net/measurements/23785597/#!tracemon -- 10 out of
50 probes could not traceroute to that IP, but there didn't seem to be
an obvious single point that they all stopped at (BT and Cogent and
Liberty and ASK4 and Comcast) - this is a somewhat larger than
expected failure rate.
Out of 100 probes
(https://atlas.ripe.net/measurements/23785647/#!probes) , 27 were not
able ping that IP (and 3 haven't reported).

I don't see any interesting BGP events until ~020-01-05 07:00
Oooohhh, it seems likely that your path is dampened - its moved
around 250 times in a day.
The route 28917 6762 56630 57335 is changed to 28917 20473 57335
The route 28917 20473 57335 is changed to 28917 3257 20473 57335
The route 28917 3257 20473 57335 is changed to 28917 6762 56630 57335
The route 34681 58057 24961 20473 57335 has been announced again
The route 28917 6762 56630 57335 is changed to 28917 20473 57335
The route 28917 20473 57335 is changed to 28917 6762 56630 57335

You probably want to look at a: your BGP configs, and talk to both
AS20473 (Coopa) and AS56630 (Melbikomas UAB, NL)

https://stat.ripe.net/widget/bgplay#w.resource=185.203.205.10=1578359516=1578446100=false=0,1,2,5,6,7,10,11,13,14,15,16,18,20=null=bgp

W

On Wed, Jan 8, 2020 at 8:04 PM Daniel Corbe  wrote:
>
> Thank you for this.
>
> Is there any chance at all I can get you to do a traceroute to
> 185.203.205.10 and 2a0c:d2c4::53:5:7335
>
> And if you have access to a bgp speaking peer, show ip bgp
> 185.203.204.0/22 and show bgp ipv6 unicast 2a0c:d2c4::/32  (or
> whatever the equivalent commands are for your NOS).
>
> Best,
> Daniel
>
> On Wed, Jan 8, 2020 at 9:57 AM Tony Finch  wrote:
> >
> > Daniel Corbe  wrote:
> > >
> > > Every well-known recursor is returning valid results for as57335.net
> > > except for 8.8.8.8 and 8.8.4.4 and I'd like some assistance getting
> > > down to the root of the issue.
> >
> > Maybe connectivity problems? I can't get to any of the nameservers from
> > 131.111.0.0/16 or 2a05:b400::/32. DNSviz can see the domain OK but
> > zonemaster cannot.
> >
> > https://dnsviz.net/d/as57335.net/dnssec/
> >
> > https://zonemaster.net/result/0e70c5e9893a0ce8
> >
> > Tony.
> > --
> > f.anthony.n.finchhttp://dotat.at/
> > people involved in running their communities
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] Re: help with a resolution

[Warren Kumari]

On Wed, Jan 8, 2020 at 6:47 PM Viktor Dukhovni  wrote:
>
> On Wed, Jan 08, 2020 at 06:00:06PM -0500, Viktor Dukhovni wrote:
>
> > Well, there are various services where indeed the zone administrator signs
> > records from authenticated, but otherwise untrusted customers, provided
> > the RR owner is associated with the customer.
> >
> > For example, the .DE zone (which uses algorithm 8, so not subject to
> > any SHA-1 issues) allows registrants that only need a handful of
> > DNS records to have those records published directly in the .DE
> > zone, without delegation.
> >
> > Other zones may make similar arrangements.
>
> Or more simply, when Let's Encrypt, or some cloud provider asks you to
> publish a TXT RR in your zone to prove zone control, how sure are you
> that's not a hash collision in disguise?

It **could** be, but I'm still failing to see how they could use this
-- LE asks me to publish:

_acme-challenge.example.com 600 IN TXT "I_like_Cheese" in my zone, and
I sign it.

LE asks Bob to publish:
_acme-challenge.example.net 600 IN TXT "I_like_Natchos" in his zone,
and Bob signs it.

I_like_Cheese and I_like_Natchos hash to the same output - 0x12345,
and both Bob and I have signed it (actually, what get signed is the
concatenation of the RRSIG RDATA and the RRSET, and so the LE doesn't
really get to choose the prefix, but lets ignore that).

Now the attacker (LE) has gotten both Bob and I to sign this, and when
someone queries for _acme-challenge.example.com LE could inject
"I_like_Natchos" instead of "I_like_Cheese" -- but both of these
strings were messages under the attackers control anyway. Yes, I feel
that there *might* be a way that this can be pivoted into something
useful to the attacker, but I'm still not seeing it...

W


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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] help with a resolution

[Warren Kumari]

On Wed, Jan 8, 2020 at 1:54 PM Viktor Dukhovni  wrote:
>
> On Wed, Jan 08, 2020 at 11:34:00PM +0530, Mukund Sivaraman wrote:
>
> > > > [muks@jurassic ~/tmp-dnssec]$ dnssec-dsfromkey Kexample.org.+005+04222
> > > > example.org. IN DS 4222 5 1 7B83C10E0220CA65139DFFE14F3F24B8D8ACAEA2
> > > > example.org. IN DS 4222 5 2 
> > > > 06B8EB5B92B64B87C75E7B0F589876067E4E31B6F34750DA853FF5D79101D831
> > >
> > > Algorithm 5 (which signs with SHA-1) SHOULD NOT be used in new
> > > deployments.  The current best-practice choices are algorithm 8 (RSA
> > > with SHA2-256) and algorithm 13 (ECDSA with NIST curve P-256 and
> > > SHA2-256).
> >
> > You are absolutely right and algorithm 13 is best suited.
>
> And with the latest news about SHA-1 chosen-prefix attacks, algorithm 5 now
> really needs to be avoided.
>

Can someone please explain to me in baby words how the SHA-1 issue
affects DNSSEC? Yes, I'm all for banging the "Move to a newer hash"
drum, but I'm still failing to see how this can be used against DNSSEC
-- from what I understand, an attacker can generate a hash collision
(2 inputs which hash to the same output), but SHA-1 is still
2nd-preimage resistant - given the hash
a94a8fe5ccb19ba61c4c0873d391e987982fbbd3, it is infeasible to find
another message which hashes to this.

So, I *could* see an attacker being able to make 2 records or keys
which have the same hash -- but, meh, that's not actually useful to
them.

eg: The DS for dns-oarc.net is: 20899 8 1
6714FF6879371C5DC19BB0389F9D497520448A2E - an attacker cannot make a
new key which hashes to this. They could in theory make 2 DNSKEYs
which have the same hash (although, because of the format of DNSKEYs I
don't think they can do this in practice), but that just allows them
to replace a zone *which they control* with another zone *which they
also control*.

I'm feeling like I'm missing something obvious here...

W


> > It was really not an example to pick an algorithm, but to demonstrate
> > how to verify a zone which the poster asked. No algorithm arguments were
> > passed.
>
> Sure, but you were also advising against the SHA-1 DS digest type (still
> reasonably safe) in an example that used algorithm 5 with its now rather
> weakened RSASHA1 signature.  I think that warranted a comment, just in
> case anyway walked away with the wrong impression.
>
> - Algorithms 5 and 7 are now seriously wounded, though perhaps not
>   yet in all use-cases dead.
>
> - DS algorithm 1 is tarnished and not recommended, but there are
>   no known attacks.
>
> > Loop's toolchain has had the default algorithms so, which it inherited. 
> > There
> > is a branch that changes the defaults, but it won't be merged in the first
> > quarter of this year.
>
> If there is a default, it should promptly change to 8 or 13.
>
> > > Instead, the attacks are against SHA-1 based *signature* algorithms, where
> > > the key-holder (typically parent zone) signs data that is partly under the
> > > control of potentially hostile others.  So the important thing is avoiding
> > > algorithms 5 and 7, NOT avoiding digest type 1.
> >
> > The mail only said SHA-1 is weakening in security day by day. A better 
> > choice
> > is available and widely supported which is digest 2, which was printed by 
> > the
> > default run of dnssec-dsfromkey in the example and explained as preferrable.
>
> See above, yes SHA-1 is tarnished, but its is as a DS digest type is not the
> reason, there are no known attacks there, the real issue is DNSKEY algorithms
> 5 and 7.
>
> > With the chosen-prefix collision attack, a rogue actor who is in charge of
> > creating KSKs may create 2 KSKs that generate the same DS SHA-1 digest 
> > field.
>
> If you have a rogue actor controlling your KSKs, all bets are off.
>
> > He may then submit and deploy the 1st key at his workplace and then sell the
> > 2nd key that would lead a different paper trail than the first
>
> I don't see the point, why not just sell the real key, what difference does it
> make.  Indeed if the second key gets discovered, then it is clear the keys
> were cooked, and who the guilty party is.  But with a leak of the single
> legitimate key, it is far less clear a-priori who leaked the key.
>
> > MD5 also doesn't have a practical second pre-image attack, but it was not
> > added as a DS digest.
>
> Indeed, we avoid new uses of tarnished algorithms.
>
> > Having read many of your posts, I greatly respect your opinion. It seems
> > unnatural to me that you would use SHA-1 as a DS digest type today, or not
> > advise a friend to switch from it if you saw it being used.
>
> I would not introduce new uses of SHA-1 in DS RRs.  Below is my complete
> DS RRset:
>
> dukhovni.org. IN DS 34314 13 2 
> 1efe87df8925417c29df1791b0ea495550acb2ff76515cc3005863497ef6b9d2
>
> my point is that if you do have a SHA-1 DS RR, that's not an immediate
> problem, but algorithms 5 and 7, especially in zones that sign other
> people's data, are a much more immediate 

Re: [dns-operations] help with a resolution

[Warren Kumari]

Your DNSSEC is broken - see https://dnsviz.net/d/pike-aviation.com/dnssec/

.com says that the domain is signed (with keyid 41388), but there is
no DNSKEY in the zone.
W

On Tue, Jan 7, 2020 at 8:33 PM William C  wrote:
>
> Hi
>
> Can you help check why public nameservers (all 8.8.8.8, 1.1.1.1, 9.9.9.9
> etc) can't resolve this domain?
>
> $ dig pike-aviation.com @8.8.8.8
>
> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> pike-aviation.com @8.8.8.8
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15133
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;pike-aviation.com. IN  A
>
> ;; Query time: 17 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Wed Jan 08 08:53:56 CST 2020
> ;; MSG SIZE  rcvd: 46
>
>
> But the domain's auth servers did respond it.
>
> $ dig pike-aviation.com @ns70.domaincontrol.com
>
> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> pike-aviation.com @ns70.domaincontrol.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5923
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1472
> ;; QUESTION SECTION:
> ;pike-aviation.com. IN  A
>
> ;; ANSWER SECTION:
> pike-aviation.com.  3600IN  A   67.205.137.55
>
> ;; AUTHORITY SECTION:
> pike-aviation.com.  3600IN  NS  ns70.domaincontrol.com.
> pike-aviation.com.  3600IN  NS  ns69.domaincontrol.com.
>
> ;; Query time: 10 msec
> ;; SERVER: 173.201.72.45#53(173.201.72.45)
> ;; WHEN: Wed Jan 08 08:55:58 CST 2020
> ;; MSG SIZE  rcvd: 114
>
>
>
> Thank you.
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Flush DNSSEC from Cache

[Warren Kumari]

On Wed, Dec 18, 2019 at 9:10 AM Jay, Tim via dns-operations
 wrote:
>
>
>
>
> -- Forwarded message --
> From: "Jay, Tim" 
> To: "dns-operations@lists.dns-oarc.net" 
> Cc:
> Bcc:
> Date: Wed, 18 Dec 2019 07:06:56 +
> Subject: Flush DNSSEC from Cache
>
> Hello DNSOPS,
>
>
>
> Will you please flush adp.com from your caches if you are doing DNSSEC 
> validation?
>
>
>
> I would greatly appreciate a reply if you have been able to flush your cache 
> succusfully.
>
>


Flushed from Google's 8.8.8.8 resolvers

Cloudflare provides a page at https://cloudflare-dns.com/purge-cache/
-- I clicked some buttons there, and so it should be flushed from
1.1.1.1 as well...


A few years back Joe Abley and I had written "A Mechanism for
Remote-Triggered DNS Cache Flushes (DNS FLUSH)"
(draft-jabley-dnsop-dns-flush-00), and "Requirements for a Mechanism
for Remote-Triggered DNS Cache Flushes"
(draft-jabley-dnsop-flush-reqs-00). I've also got a draft,
presentation and some PoC code for creating a "DNS exchange" (a
concept similar to an IXP, but for DNS). This would allow sharing of
zonefiles, and also the ability to request cache flushes through an
automated, authenticated system. Other projects got in the way, but
I've been meaning to get back to this sometime...

W


>
> Thank you,
>
>
>
> Tim Jay
>
> Domain Client Services Manager, MarkMonitor |  Clarivate Analytics
>
> Phone +1.208.685.1789 |  Fax +1.208.389.5771
>
> 3540 East Longwing Lane, Suite 300 |  Meridian, ID 83646 |  US
>
>
>
> Have feedback? Contact my supervisor directly at olga.bou...@markmonitor.com
>
>
>
> NOTE: All transactions with MarkMonitor are subject to our standard terms and 
> conditions set forth at https://www.markmonitor.com/legal/tc_dm.php or the 
> specific terms and conditions of your written agreement with MarkMonitor. If 
> you do not agree to be bound by these terms and conditions, please contact us 
> immediately to cancel your order - (800) 337-7520.  MarkMonitor’s proposed 
> prices and terms of service are highly confidential and proprietary to 
> MarkMonitor, and may only be used for your internal purchasing purposes.  
> This information may not be shared with any third parties, except as 
> necessary in connection with any legal action or proceeding.  If you do not 
> agree with these confidentiality obligations, please notify the sender by 
> return e-mail, and delete or destroy all copies of this email and any 
> attachments.
>
>
>
>
>
>
>
>
> -- Forwarded message --
> From: "Jay, Tim via dns-operations" 
> To: "dns-operations@lists.dns-oarc.net" 
> Cc:
> Bcc:
> Date: Wed, 18 Dec 2019 07:06:56 +
> Subject: [dns-operations] Flush DNSSEC from Cache
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

[Warren Kumari]

On Fri, Oct 11, 2019 at 9:00 PM Joe Abley  wrote:

> On 11 Oct 2019, at 14:21, Paul Vixie  wrote:
>
> > in the earlier days of DNS-OARC (where dnsviz migrated to recently),
> there was a server at cogent, which was not reachable over IPv6 from users
> are hurricane. i don't remember anybody blaming hurricane for this, which
> is why it seems odd to blame cogent today when DNS-OARC is hosted at
> hurricane. hurricane has transit for their IPv4 network but not for their
> IPv6 network. cogent's peering policy isn't fully "open." it's hard for me
> to see that either of them is "in the wrong."
>
> For me, too. People need to put their pitchforks away.
>
> The root server system as a whole accomplishes this kind of redundancy in
> connectivity by having multiple root servers that are each
> differently-connected to the Internet. Many of those individual root
> servers are further distributed across multiple connectivity providers
> using anycast. C is one that is not, but since it's an active goal of the
> system as a whole to be diverse it's hard to see that as a problem. I
> guarantee that there are attack scenarios where having all the anycast
> nodes (and hence the attack traffic) in one AS is going to be an advantage
> for measurement, or mitigation, or something.
>
> There is a ridiculous amount of diversity in this system precisely so that
> nobody has to lose any hair when one (or even many) specific components are
> not reachable.
>
> What some people are seeing in this thread as a problem is actually a nice
> demonstration that the system as a whole is immune to damage due to
> partial-table peering disagreements.


Indeed.
W



>
> Joe
>
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
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?

[Warren Kumari]

On Thu, Oct 10, 2019 at 4:59 PM Frank Louwers  wrote:
>
> Hi Warren,
>
> The lack of peering with a network doesn't prevent my accessing them,
> it just means that my packets take a sub-optimal[0] route.
> The above doesn't look like that at all, it looks like $something else
> (like dropped fragments), which is completely different to not
> peering[1].
>
>
> I feel like I haven't had my morning coffee, and am missing something
> wildly obvious here -- please, what it is?
> W
> [0]: Well, sub-optimal in terms of number of AS's, not necessarily in
> terms of congestion, latency, reliability, geography, etc.
>
>
> You don't peer with HE, but you buy transit from a company that does peer 
> with HE.
>
> Neither Cogent or HE buy transit from anybody else. They only peer and have 
> customers. They don't buy "fallback" traffic.

Oh... yes. As I said, I *felt* like I was missing something
obvious. That was it and now I feel like an idiot :-P

Thanks,
W



>
> Now if Cogent refuses to peer with HE (or the other way around), and they 
> both don't buy traffic from anybody else, they can't reach each other...
>
> Frank
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
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?

[Warren Kumari]

On Thu, Oct 10, 2019 at 5:12 AM Matthew Pounsett  wrote:
>
>
>
> On Wed, 9 Oct 2019 at 22:57, Viktor Dukhovni  wrote:
>>
>> On Wed, Oct 09, 2019 at 05:41:43PM -0400, Viktor Dukhovni wrote:
>>
>> > No, even small responses receive no answers from the IPv6 addresses
>> > of the C and F roots.  Both of the below time out even though I'm
>> > not setting the "DO" bit:
>> >
>> > $ dig -6 +norecur -t soa arpa. @2001:500:2f::f
>> > $ dig -6 +norecur -t soa arpa. @2001:500:2::c
>> >
>> > Looks like an outage from my vantage point.
>
>
> I can't speak to the reachability of F from that vantage point, but Cogent 
> has famously refused to peer over v6 with HE, which is why they're 
> unreachable from OARC (and therefore DNSViz) and lots of other places on the 
> Internet.
>

I must admit I'm feeling really stupid here, but I feel like I'm
missing something. Yes, Cogent might not peer with HE over v6, but I'm
trying to understand the failure mode -- I also (not famously at all!)
don't peer with Cogent over both v4 **and** v6 -- and yet, I can still
send and receive packets to them. I also don't peer with "E-Gate
Communications Inc., CA", which announces 67.215.196.35
(ns1.conundrum.com), and yet I can resolve conundrum.com.

The lack of peering with a network doesn't prevent my accessing them,
it just means that my packets take a sub-optimal[0] route.
The above doesn't look like that at all, it looks like $something else
(like dropped fragments), which is completely different to not
peering[1].


I feel like I haven't had my morning coffee, and am missing something
wildly obvious here -- please, what it is?
W
[0]: Well, sub-optimal in terms of number of AS's, not necessarily in
terms of congestion, latency, reliability, geography, etc.
[1]: I guess you could make the argument that if the peering existed,
packets are less likely to take tunnels / paths with small MTU /
broken pMTUD, etc, but that's a different argument...


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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Link-local IP addresses for a resolver?

[Warren Kumari]

On Wed, Sep 25, 2019 at 6:33 PM Joe Abley  wrote:
>
> On 25 Sep 2019, at 18:18, Warren Kumari  wrote:
>
> > Yes, the best practice and advice is to choose something random, but
> > network engineers are humans too, and if you had to remember and try
> > tell someone over the phone to use fd5a:8109:a679:180a:45d3:d653:22:1
> > or fd00:1::1 as the default gateway, which would you rather do?
>
> You could choose something random then give the end-user a DNSSEC-signed DNS 
> name instead of the address.

That only works once they have a working network, which is why I used
the example of "default gateway" and not "browse to
fd5a:8109:a679:180a:45d3:d653:22:1". I've seen people encode the
building number / floor / VLAN / etc into the network address, when
you are configuring a router you almost always enter interface address
instead of using DNS, etc. Having a deterministic, and easy to
remember address is much much easier at 3AM, I'm less likely to typo
fd00:13:1 than  fde3:783e:127d: , etc.

I personally don't use ULAs / site local, but I fully understand why
those who do use easy addresses...

> So long as they are using a centralised resolver service with a long enough 
> privacy policy, a different address family to do the resolution over and the 
> operating system uses DoH by default, security is guaranteed and end-users 
> gain the reliability of having large companies responsible for communicating 
> their local network parameters instead of unreliable local technicians who 
> are invariably up to no good. All we need is the universal deployment of 
> IPv6, DNSSEC and DoH.

Yup, let me know once that's done and I'll buy you dinner :-P

Thanks,
W
>
>
> Joe



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

Re: [dns-operations] Link-local IP addresses for a resolver?

[Warren Kumari]

On Tue, Sep 24, 2019 at 8:03 PM John R Levine  wrote:
>
> On Wed, 25 Sep 2019, Mark Andrews wrote:
>
> > ISP’s advertings ULA’s to customers have similar problems with
> > advertising LLL to customers. The CPE should be the site boundary making
> > the ISP’s DNS servers unreachable from inside the customer’s network.
>
> > DNS servers that are expected to be reached across sites need to be
> > globally unique addresses which ULA and LL are not.
>
> If a ULA isn't globally unique, something is pretty broken.  Each ULA
> contains a 40 bit random global ID in the prefix that's there so ULAs on
> different networks won't collide if they happen to be connected.  That's
> why the U stands for, you know, Unique.
>

ULAs are very from unique -- there is a huge bias towards things which
humans can remember / cute names, etc (this is very similar to the
"IPv6 space is namp / scannable because people name hosts in
deterministic ways" - see some presentations from Fernando Gont).
There is a large ULA bias towards fd00::, fd10::, fdfd::,
fd00:dead:beef:, fd00:bad:coff:ee::.

Yes, the best practice and advice is to choose something random, but
network engineers are humans too, and if you had to remember and try
tell someone over the phone to use fd5a:8109:a679:180a:45d3:d653:22:1
or fd00:1::1 as the default gateway, which would you rather do?

W

> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. 
> https://jl.ly___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

Re: [dns-operations] The root zone at past 1000.

[Warren Kumari]

On Mon, Jul 13, 2015 at 3:43 PM, Stephane Bortzmeyer bortzme...@nic.fr wrote:
 On Mon, Jul 13, 2015 at 01:01:36PM +,
  Shane Kerr sh...@time-travellers.org wrote
  a message of 23 lines which said:

 I look forward to reviewing the next DITL captures and seeing how
 much this has improved the lives of everyday Internet users! ;)

 I feel much better now that we have .pizza, .black and .cafe.

You see, Shane. It *has* made Internet users' lives better -- without
this how would Stephane ever have been able to find pizza and
coffee...

W


 ___
 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
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] The root zone at past 1000.

[Warren Kumari]

On Mon, Jul 13, 2015 at 3:01 PM, Shane Kerr sh...@time-travellers.org wrote:
 William,

 On Wed, 8 Jul 2015 14:07:20 -0400 (EDT)
 William Sotomayor w...@ottix.net wrote:


 Well we've had December 2012 come and go, and now we're at 1003 entries
 in the root zone.  I think we're all still here and the Internet seems
 functional for various definitions of 'functional'.

 I look forward to reviewing the next DITL captures and seeing how much
 this has improved the lives of everyday Internet users! ;)

What, you have doubts? Heresy.

W



 Cheers,

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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
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] .co broken for non-stock queries?

[Warren Kumari]

On Wed, Jun 10, 2015 at 3:48 AM, Mark Andrews ma...@isc.org wrote:

 See http://ednscomp.isc.org/compliance/tld-typereport.txt and covers
 all tld servers.


Oh, cool...

What would be really helpful is a description (or link to a
description) of what the tests being performed are -- when it says:
google. @216.239.60.105 (ns-tld5.charlestonroadregistry.com.): all ok

what all does all ok cover? From scrolling down and looking at
failures on other TLDs I can see some things that are being tested,
but knowing all the test would be useful.

W



 The report is several days old.  A new report is being generated
 and should be regenerated daily.  A file system fault was causing
 the server to panic and reboot while the report was being generated.
 Some timeouts may be due to network issues / rrl so confirmation
 testing should be done.

 The CDS=refused is be due to a bug in BIND 9.8.8, BIND 9.9.6 and
 BIND 9.10.1. The at parent attribute was not cleared when converting
 the DS code to handle CDS.  This bug is fixed in BIND 9.9.7 and
 BIND 9.10.2.  BIND 9.8.8 users should upgrade to BIND 9.9.7 or BIND
 9.10.2.

 Mark

 In message alpine.lfd.2.11.1506091204070.32...@bofh.nohats.ca, Paul Wouters 
 w
 rites:

 I noticed that the .co TLD servers seem to not respond to various
 queries, eg:

 dig +norecurse -t openpgpkey roessner.co. @ns1.cctld.co.
 dig +norecurse -t cds roessner.co. @ns1.cctld.co.
 dig +norecurse -t uri roessner.co. @ns1.cctld.co.

 It oddly enough does return answers for the private use range.

 Anyone know of a .co contact to ask what's going on?

 Paul



 ___
 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
 --
 Mark Andrews, ISC
 1 Seymour St., Dundas Valley, NSW 2117, Australia
 PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
 ___
 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
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

[Warren Kumari]

On Wed, May 27, 2015 at 1:32 PM, Joe Abley jab...@hopcount.ca wrote:


 On 27 May 2015, at 16:16, Mark Andrews wrote:

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

 Mark

 marka@ednscomp ~/tld-report]$ awk '$4 == NS {print $1, $5}' root.db | sh
 gentypereport tlsa | grep -v all ok
 accountant. @156.154.144.195 (ns1.dns.nic.accountant.): tlsa=timeout
 accountant. @156.154.145.195 (ns2.dns.nic.accountant.): tlsa=timeout
 accountant. @156.154.159.195 (ns3.dns.nic.accountant.): tlsa=timeout
 accountant. @156.154.156.195 (ns4.dns.nic.accountant.): tlsa=timeout
 accountant. @156.154.157.195 (ns5.dns.nic.accountant.): tlsa=timeout
 accountant. @156.154.158.195 (ns6.dns.nic.accountant.): tlsa=timeout


 It's hard to know what you're testing (what gentypereport does), but if
 you're looking for TLSA records in the ACCOUNTANT zone above, I'm not sure
 why; new gTLD operators are constrained by contract as to the RRTypes
 they're allowed to publish, and TLSA isn't one of them. It's not obvious
 that this is a problem for anybody, though; it's not like you'd expect to
 see a TLSA RRSet in there.

 What is the point you're making?

I think that point is that a timeout is not the right response.


 For what it's worth, I have no problem getting a reasonable (negative)
 response to ACCOUNTANT/IN/TLSA or SOMETHING.ACCOUNTANT/IN/TLSA from
 156.154.144.195 with EDNS0.DO=1 or without EDNS0. Perhaps I'm special :-)

Unable to parse. Are you saying that you *are* getting a reasonable
(negative) response to ACCOUNTANT/IN/TLSA? Or that you would be OK
getting on if that is what they decided to send you?

I get:
dig TLSA accountant @156.154.144.195

;  DiG 9.8.3-P1  TLSA accountant @156.154.144.195
;; global options: +cmd
;; connection timed out; no servers could be reached


Same thing for TYPE67 (unassigned):
dig TYPE67 accountant @156.154.144.195

;  DiG 9.8.3-P1  TYPE67 accountant @156.154.144.195
;; global options: +cmd
;; connection timed out; no servers could be reached


NoERROR/NODATA (yes please), REFUSED, NOTIMP, etc are all better than
just not answering (which means the recursive and stub / app both hang
around burning state).

W





 Joe

 ___
 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
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

[Warren Kumari]

On Wed, May 27, 2015 at 3:02 PM, Joe Abley jab...@hopcount.ca wrote:


 On 27 May 2015, at 19:14, Warren Kumari wrote:

 For what it's worth, I have no problem getting a reasonable (negative)
 response to ACCOUNTANT/IN/TLSA or SOMETHING.ACCOUNTANT/IN/TLSA from
 156.154.144.195 with EDNS0.DO=1 or without EDNS0. Perhaps I'm special :-)

Yah, /I/ know you are special -- but I don't know how 156.154.144.195
knows you are.

Can you include a dig (or similar) showing you asking the question and
getting an answer (not a timeout?). I've queried from multiple places
with no love...

W




 Unable to parse.


 Unsure why. :-)

 Are you saying that you *are* getting a reasonable
 (negative) response to ACCOUNTANT/IN/TLSA?


 Yes. And also to SOMETHING.ACCOUNTANT, both with EDNS0.DO=1 and with no
 EDNS0 (see above).


 Joe



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
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] Stunning security discovery: AXFR may leak information

[Warren Kumari]

On Tue, Apr 14, 2015 at 2:47 PM, Marjorie marjo...@id3.net wrote:
 This is an interesting discussion actually.
 It's all about a rather benign but widespread misconfiguration.

It's only a misconfiguration if the operator didn't choose to do that
intentionally...

 Not long ago, I ran a survey against a small ccTLD and tested each
 domain name for AXFR.
 The ccTLD zone file itself having been obtained - you guessed it - by
 way of zone transfer...

A number of ccTLD operators intentionally allow AXFR of the zone. They
take the view that what is registered is:
A: public and or
B: will become public anyway. By allowing AXFR they cut down on
dictionally attacks and similar...


 Surprisingly, AXFR requests were honored by one server out of seven or
 something.
 So the prevalence of AXFR-enabled DNS servers is still quite high. I
 would guess this is the result of using default configuration settings
 from older Bind versions, but I didn't fingerprint the DNS software
 versions.

 Still many seem to consider that zone transfer is a moot point anyway,
 because the zone file can be reconstructed by scanning known IP ranges,
 then resolving hostnames.
 I disagree with this.  There is no valid reason for exposing your
 network topology to the outside world. You are only making the job
 easier for potential attackers.

If your security is somehow predicated on attackers not knowing the
names of machines you are going to have a bad day...


 I think the biggest issue with zone transfers, is that they may leak
 information that cannot be easily guessed otherwise.
 Specifically: hostnames declared outside the IP ranges that are known to
 the attacker.

 For example, company acme.com may have a zone file like this (IP
 addresses are of course made up):

 IN  SOA ns1.acme.com. hostmaster.acme.com. (
 2015041001 ; serial
 3H ; refresh
 15 ; retry
 1w ; expire
 3h ; minimum
 )
 ...
 sqlserverA204.63.177.1
 mailserverA204.63.177.21
 mailserver2A204.63.177.22
 sharepointA204.63.177.40
 archiveA204.63.177.55
 backupserverA89.52.67.31
 ...


 By looking at the zone file, you now know they have a backup server
 (89.52.67.31) hosted with a third party provider, thus you have one
 additional target to try.
 Thank you AXFR for helping hackers.

Again, if you were hoping that a hacker wouldn't have thought to
query for backupserver.acme.com and that this was providing you
protection you will become sad.
Also, let me introduce you to Farsight Security's DNSDB
(https://www.dnsdb.info/#Home) (many similar, but inferior services do
similar things)...


 Occasionally I have found sensitive comments in TXT records (HINFO
 records are telling too, sometimes).

 The bottom line is that unrestricted AXFR is generally evil, except for
 researchers of course.

... and those who want to cut down on dictionary attacks... and those
who run public zones, like the root and .arpa, and...


AXFR is also nice when you operate a search engine
 and want to find as many hosts as possible.


This is usually not open AXFR, but rather an agreement between the
search engine and TLD operators, with the TLD operator allowing AXFR
from a specific source block

 DNS is like webhosting: the majority of the users do not have in-depth
 understanding of the mechanisms at work. They just have enough knowledge
 to make things run more or less smoothly.

 Marj



 On 14-04-2015 17:52, Samson Oduor wrote:
 On 4/14/2015 6:38 PM, Jelte Jansen wrote:
 some DNS geeks even enable open AXFR on purpose, btw. Open AXFR is not
 necessarily a security hole or data leak.

 open AXFR =  good for conducting reconnaissance
 ___
 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 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
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] Stunning security discovery: AXFR may leak information

[Warren Kumari]

On Tue, Apr 14, 2015 at 4:31 PM, Michael Sinatra mich...@brokendns.net wrote:
 On 4/14/15 12:00 PM, Mike Hoskins (michoski) wrote:

 I disagree with this.  There is no valid reason for exposing your
 network topology to the outside world. You are only making the job
 easier for potential attackers.

 Yes agreed.  The finding is nothing new, and it's not a weakness in AXFR
 itself as others have rightly pointed out...so the timing and way in which
 it was reported were less than ideal...but your point is spot on.  Many
 speak against security by obscurity but I think that is often taken too
 far -- in some ways blocking AXFR is no different than DMZs and
 firewalls...hey, why not have everything on public IP with all ports
 exposed?  Security is an onion, and as many layers as you can put between
 you and the adversary are generally good assuming the obscurity is not
 adding unnecessary complexity or other hidden cost (proper config of a DNS
 server is quite easy and can be automated).

 The problem I have with the way that this is posed by the US-CERT
 advisory is that it neglects to point out that DNS is designed to be a
 public database.  If you put information in the DNS that makes it easy
 to guess things about your network that you don't want people to guess,
 well, you have a problem then.  Relying on AXFR restrictions to mask
 that problem is, at best, a weak control.  (See Paul's post.)  Because
 security is indeed an onion, AXFR restrictions really shouldn't be
 *that* important--just another layer in a set of good security practices.

 The real reason I see for restricting AXFR is to preserve resources on
 the server.  This is less of an issue now than it was in the BIND 4 days
 (didn't BIND 4 used to fork() for outbound zone transfers?), but I still
 don't want any- and every-one to hammer my DNS servers with AXFR
 requests.

Depends on who you are and who is interested in the contents of your
zone -- if you are operating a ccTLD (and depending on the number of
records, the distribution of records, phase of the moon, etc) it *may*
be cheaper to simply allow AXFR instead of having a bunch of spammers
do dictionary attacks trying to guess all the names. At least one
ccTLD (that I know of) became much happier after they just threw in
the towel and allowed AXFR...

W

  I am kind of surprised and disappointed that the US-CERT
 doesn't mention that component of the issue.

 michael

 ___
 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
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] Stunning security discovery: AXFR may leak information

[Warren Kumari]

On Tue, Apr 14, 2015 at 3:15 PM, Edward Lewis edward.le...@icann.org wrote:
 On 4/14/15, 14:47, Marjorie marjo...@id3.net wrote:

The bottom line is that unrestricted AXFR is generally evil,

 I'd go with generally unwise.  There are folks that believe it is fine
 to allow access to their zones and I have no reason to say they are
 foolish.

+1.

Included in this are (at least):
. (from [b,c,f,g,k].root-servers.net)
.arpa
.bb
.bd
.bi
.bv
.capetown
.cg
.ci
.cy
... and then I got bored...

Some of the above operators *may* be surprised, but *certainty* not
all. I know a number of the operators of the above and know that they
have done this by choice.

  Folks who are not concerned with the minutia of operating their
 DNS server most likely would not want to allow the access and the tools
 they use should meet their likely expectations.

 ___
 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] DNS Flush Protocol

[Warren Kumari]

On Fri, Mar 27, 2015 at 2:40 PM, George Michaelson g...@apnic.net wrote:
 I would agree that assumptions are a road to perdition.

 But the model of concentration of eyeballs through resolvers is not
 new. So, whilst I agree in *principle* I think it bears thinking
 about: do you actually really expect a disruptive (sea)change  here?

 I mean, I think its more likely we get a sea-change in the signed root
 outcomes, than less people use 8.8.8.8 and 4.4.4.4 personally. Or
 Comcast, given their centrality in current (and forseeable future)
 market share now they're getting the eyes behind TW. Or China's
 concentration of views behind 3-4 carriers.

 So yes. But then again.. Perhaps.. No.

This isn't really an architectural decision -- currently the way we
flush caches is someone posts a OMG, I just did something dumb,
please can everyone flush their cache for $foo on some set of mailing
lists... and then we all wander around asking how / why we should
trust that mail, some set of people actually flush, some don't read
them mail till 4 days later, some bemoan the fact that we still
haven't solved this problem, etc.

I was saying is that we don't really need to reach *every* recursive,
whatever we do manage to do will be better than the current position.

Sure, a fully awesome, all shining, all dancing cache flush solution
that can securely flush all caches everywhere would be best, but until
this comes along, something, anything really, is better than posting
on DNS-Operations

W
[0}: I'm assuming everyone knows about:
https://developers.google.com/speed/public-dns/cache and
http://cachecheck.opendns.com/ ?



 On 27 March 2015 at 14:16, Paul Vixie p...@redbarn.org wrote:
 see also:

 http://www.techrepublic.com/blog/data-center/opendns-and-neustars-real-time-directory-aim-to-speed-dns-update-times/
 ___
 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 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
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] Saga of HBONow DNSSEC Failure

[Warren Kumari]

On Tue, Mar 10, 2015 at 11:09 AM, Matthew Pounsett m...@conundrum.com wrote:

 On Mar 9, 2015, at 23:50 , Livingood, Jason 
 jason_living...@cable.comcast.com wrote:

 So earlier today HBO announced a new HBONow streaming service (at an Apple 
 event). The FQDN to order, which should have been DNSSEC-enabled, was 
 order.hbonow.com. This unfortunately suffered from a rather inconveniently 
 timed DNSSEC problem (http://dnsviz.net/d/order.hbonow.com/VP5DKQ/dnssec/). 
 :-( Of course, these being hot Net Neutrality days in the U.S., we at 
 Comcast were quickly blamed for blocking access to ordering this new service 
 (despite failures at Google and other validators).

 I’d just like to comment how pleased I am that Comcast continues to push 
 DNSSEC validation, despite taking regular hits from end users.

+lots. Thank you Comcast, and Jason.

W

  I keep hoping others will follow suit.. the more large validator
operators that enable it, the fewer hits anyone will take for doing
so.




 ___
 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

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

[Warren Kumari]

On Friday, January 9, 2015, Tony Finch fa...@cam.ac.uk wrote:


  On 9 Jan 2015, at 12:50, Stephane Bortzmeyer bortzme...@nic.fr
 javascript:; wrote:
 
  I'm looking for resources discussing the pros and cons of sharing
  DNSSEC keys between zones.
 
  I find nothing in RFC 6841 or 6781. Any pointer?

 There is a paragraph about this at
 http://users.isc.org/~jreed/dnssec-guide/dnssec-guide.html#same-key-for-multiple-zones

 It seems to me that most of the cost of DNSSEC key management is dealing
 with parent delegation changes.


Obligatory marketing message on automating this:
https://tools.ietf.org/html/rfc7344

W






 Sharing keys between zones does NOT help with this, partly because the
 zone name is part of the DS hash, so DS records are different for the same
 key in different zones.

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

 Tony.
 --
 f.anthony.n.finch  d...@dotat.at javascript:;  http://dotat.at
 ___
 dns-operations mailing list
 dns-operations@lists.dns-oarc.net javascript:;
 https://lists.dns-oarc.net/mailman/listinfo/dns-operations
 dns-jobs mailing list
 https://lists.dns-oarc.net/mailman/listinfo/dns-jobs



-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[Warren Kumari]

On Mon, Dec 1, 2014 at 6:13 PM, Paul Vixie p...@redbarn.org wrote:


   Paul Vixie p...@redbarn.org
  Sunday, November 30, 2014 2:29 PM

 why? (your use case is not obvious from what you've written.) ...

   Chuck Anderson c...@wpi.edu
  Monday, December 01, 2014 7:09 AM

 Silent on-disk corruption. It happens, and it would be nice to be
 able to detect that.

  if you're concerned about operating system or hardware or network errors,
 then i assume you're also concerned about them hitting your name server
 executable, in which case you'll be running a file system like ZFS that
 catches these things.

 if you're concerned about malevolent on-disk editing, then i assume you're
 running something like tripwire to snapshot with secure hashes every file
 in your operating system, and that it will have hooks to manage and monitor
 the zone files as well.

 either way i'm not seeing a unique has to be done with an in-zone
 signature situation here.


It's not necessarily a has to be done with an in-zone signature, but
doing it with an in-zone signature is:
A: easy
B: convenient
C: I have a single blob I can validate.
If you are concerned about malevolent on-disk editing and OS issues, you
can run ZFS and tripwire to snapshot with secure hashes every file *as well
as this.

Using the root-zone as an example, currently if I want to validate the zone
I do:
wkumari-macbookpro1:root-zone wkumari$ wget -q
ftp://ftp.internic.net/domain/root.zone
wkumari-macbookpro1:root-zone wkumari$ wget -q
ftp://ftp.internic.net/domain/root.zone.sig
wkumari-macbookpro1:root-zone wkumari$ gpg --verify root.zone.sig root.zone
gpg: Signature made Mon Dec  1 13:53:30 2014 EST using DSA key ID 4150E298
gpg: Good signature from Registry Administrator ns...@verisign-grs.com
(entertainingly enough I trust 4150E298 because it was signed on 2013-02-11
by Larson, Matt /o=VERISIGN/ou=VA-EAST/cn=Recipients/cn=mlarson)

Clearly detached signatures *do* work, but if I happened to get the
root.zone at 6:52:59PM and the root.zone.sig file at 6:53:01PM I'd have an
issue (noting that the file time stamp is 6:53:00 PM) I now have an
issue. This also gets finicky if I try and keep multiple copies of the
zones for historical reasons, to be able to show that what I served was
what I got, etc. Yes, having version numbers on the files and detached sigs
is doable (or simply retrying if I get a validation failure, etc) but I
cannot see the downside to including it in the zone as well - if you
dislike the ZONESIG RR (just made up name) you can simply choose not to
check it.

Similarly, if someone emails me example.com.db and says Please serve this
zonefile, I signed it with my GPG key, and the signature is
0xdeadbeef...cafe (or I attached example.com.db.sig) I have a bunch more
places where things could go wrong, including the obvious forgetting to
attach both files, having a signature for serial 2014120117 and the zone
contents for serial 2014120142, etc.
Having Here is the signed zone example.com.db and passing that to
load_and_validate_zone.sh or 'rndc addzone --validate example.com. is
(IMO) much less error prone.

I think that this is similar to how, when you get a PGP signed email you
get the signature in the same message, and not one email saying Foo Bar
Baz and then a second email with a signature for the first message.


W




 --
 Paul Vixie

 ___
 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




-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
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] Reminder: Workshop on DNS Future Root Service Architecture, Hong Kong, December 8-9, 2014

[Warren Kumari]

Hi all,

A reminder that, if you are coming to the Workshop on DNS Future Root
Service Architecture, Hong Kong, December 8-9, 2014 meeting to please
let Paul Vixie p...@redbarn.org or myself Warren Kumari
war...@kumari.net know.

We have a room block at venue hotel. To reserve a room in this block,
visit the URL shown below:
https://bookings.ihotelier.com/The-Mira-Hong-Kong/bookings.jsp?hotelID=85171groupID=1333820
If you have reserved a room at the conference hotel, *and did not use
the signup link*, please let us know, so we can associate you with our
room block[0].

Participants are invited to submit proposals for several open slots,
with final selection to be made during the workshop itself.

The current agenda:

Monday:
0900-0910: Welcome from ISOC-HK (local host)
0910-0915: Welcome from ZDNS/BII (sponsor)
0915-0920: Welcome from CNNIC (sponsor)
0920-0930: Logistics and late agenda changes (co-chairs)
0930-0945: Current problem statement (co-chairs)
0945-1030: Decreasing Access Time to Root Servers by Running One on
Loopback (W. Kumari, P. Hoffman)
(present current draft, field questions and objections, propose text
or logic revisions)
1030-1100: Break (coffee)
1100-1145: How to scale the DNS root system? (X. Li, P. Vixie)
(present current draft, field questions and objections, propose text
or logic revisions)
1145-1230: Open discussion of the two drafts, with expected
refinements to the problem statement
1230-1400: Lunch (hosted)
1400-1430: Testbed for IPv6-only DNS development (Dr. Linjian Song, BII Lab)
1430-1500: Evolution of DNS root zone operation and management (Dr.
Declan Ma, ZDNS Lab)
1500-1530:  Offering DNS root zone on unmanaged anycast: comparisons
with AS112 (Paul Hoffman)
1530-1600:  Integrity protection for entire zones (Presented TBD)
1600-1700: Open (proposals welcome, workshop participants to decide in
the moment)
1700-1900: (Unscheduled private time)
1900-2200: Dinner (hosted)

Tuesday:
0900-0930: Summary of day 1, new issues, closed issues, opened issues
(co-chairs)
0930-1030: Summary of changes to text of Internet Drafts accepted
during workshop
1030-1100: Break (coffee)
1100-1230: Open (proposals welcome, workshop participants to decide in
the moment)
1230-1400: Lunch (hosted)


Thank you, and sorry for the interruption.

W


-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
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] Looking for a public blackhole/sinkhole IP address

[Warren Kumari]

On Wed, Nov 26, 2014 at 7:12 PM, Robert Edmonds edmo...@mycre.ws wrote:
 Warren Kumari wrote:
 This thingie has many aspects that look a bunch like AS112 -- I'm
 wondering if it makes sense to also request an AS number for this.
 It's not strictly needed, but having fewer inconsistent origin routes
 is always nice.

 It also seems that (also like AS112), networks could do this in one of
 (at least) 3 ways:
 1: They can spin up this route purely within their own network  --
 basically have one or more places where the route points at null0 /
 discard and *not announce it to peers / customers* or
 2: announce to customers only or
 3: be good citizens and announce it to everyone.

 1 and 2 already exist, for RTBH (like you mention in the doc), they
 are just not anycasted. I wonder if we ask the IANA nicely if they'd
 assign 666.666.666.0/24 to.. oh, bugger

 The more people who do this, the more benefit there is - unfortunately
 this argument often doesn't work on the Internets, but still worth
 trying...

 If one is trying to dispose of 250 million DNS requests per second [0]
 or  1Mr/s (mega-requests per second) [1], then you probably *don't*
 want the traffic to be routed to whoever happens to have announced it,
 or anywhere, really.

Yes -- which is why many (most?) networks already have a RTBH
destination / null route. If you are at the receiving end of [0] or
[1], you sure don't want to be routing this back out to a community
blackhole, you want to drop it as soon as possible instead[*]. This
means shuffling it off to something that can drop it ASAP, like as
soon as you touch it -- you'll probably send this to a discard route
(forwarding  filtering) -- in which case you A: route it to your
already existing discard prefix, in which case why not use the address
we are requesting for this? or B: you realize you really should have a
discard prefix -- in which case, why not spin up the prefix we are
requesting?


  That seems to be a much different use case (drop
 the traffic as quickly and universally as possible, minimizing
 collateral damage) from routing the traffic to something like a
 community sinkhole.

Yes -- and the whole point of this plan would provide the as quickly
and universally as possible. The theory (hope) is that *most* people
will spin up this prefix and null route it, preferably on their edges.
Perhaps community sinkhole^Wblackhole is the wrong term / conjures
up the wrong image, and universal blackhole would be better.
What we are aiming for / proposing is a toss this as soon as
possible, not route to a small number of sinkholes run by some
volunteers. The incentive model here is that, the more people who do
this, the more useful it is -- and so, one day when *I* need it, it
will be available. This might suffer from a tragedy of the commons
type problem - I'll just hope that other folk do it, so I don't need
to sink the badness. One nice property that this has versus something
like BGP38 / SAVE is that it is very easy to tell if your peers are
not doing it -- and so you could easily include it in peering /
provider contracts.
What would be really nice (IMO) is, if we get consensus on this, to
recommend that router's do this automagically (with a turn off knob) -
there are already a number of special prefixes that some devices
handle (127/8, 169.254.0.0/16, 240/4, etc) - having a default this
prefix/24 - discard in devices would make it so that the very first
devices seeing the traffic would dump it.


W
[*]: Actually, it's unclear if this would have worked for [0] and [1]
- you might need some more granularity than Aaargh, make this stop!


 [0] 
 http://www.forbes.com/sites/parmyolson/2014/11/20/the-largest-cyber-attack-in-history-has-been-hitting-hong-kong-sites/

 [1] 
 https://la51.icann.org/en/schedule/mon-tech/presentation-dafa888-dos-attack-13oct14-en.pdf

 --
 Robert Edmonds
 ___
 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[Warren Kumari]

... and Mark Andrews, Paul Hofmann, Paul Wouters, myself and a few others
(who I embarrassing enough have forgotten) are planning on writing a zone
signature draft (I have an initial version in an edit buffet). The 50,000
meter view is:
Sort all the records in canonical order (including glue)
Cryptographicly sign this
Stuff the signature in a record

This allows you to verify that you have the full and complete zone (.de...)
and that it didn't get corrupted in transfer.
This solves a different, but related issue.

Hope to finally get off my butt and post -00 soon.

W

On Thursday, November 27, 2014, Richard Lamb richard.l...@icann.org wrote:

 Having worked on solas at Intl maritime org, I agree with David.  There
 are many parallels to that space and domain name space.  We should learn
 from that experience.

 Rick


 Sent from my iPhone

  On Nov 27, 2014, at 11:19, David Conrad d...@virtualized.org
 javascript:; wrote:
 
  Patrik,
 
  On Nov 26, 2014, at 10:40 PM, Patrik Fältström p...@frobbit.se
 javascript:; wrote:
  FWIW, I have been working on this for a while with the Diplo
 foundation, and I am happy to answer questions (and of course listen to
 concerns).
 
  It is an interesting idea, but I don't get how it would work.  I asked
 Jovan back when he initially proposed it, but never heard back.
 
  Is the theory behind this that governments around the world would enter
 into some sort of treaty or some other formally binding vehicle that would
 make the root zone inviolable? What would be the sanctions should the
 holder of the root zone (whoever it might be) ignore the inviolability of
 the root zone and how would they be enforced? How is that going to work
 given (e.g.) the US hasn't even been able to ratify the Treaty of the Sea
 and internal domestic politics will generally override any international
 agreement at politicians' whim?
 
  Regards,
  -drc
 
  ___
  dns-operations mailing list
  dns-operations@lists.dns-oarc.net javascript:;
  https://lists.dns-oarc.net/mailman/listinfo/dns-operations
  dns-jobs mailing list
  https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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



-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[Warren Kumari]

On Thursday, November 27, 2014, Paul Vixie p...@redbarn.org wrote:



   Warren Kumari javascript:_e(%7B%7D,'cvml','war...@kumari.net');
  Thursday, November 27, 2014 1:11 PM
 ... and Mark Andrews, Paul Hofmann, Paul Wouters, myself and a few others
 (who I embarrassing enough have forgotten) are planning on writing a zone
 signature draft (I have an initial version in an edit buffet). The 50,000
 meter view is:
 Sort all the records in canonical order (including glue)
 Cryptographicly sign this
 Stuff the signature in a record

 This allows you to verify that you have the full and complete zone
 (.de...) and that it didn't get corrupted in transfer.
 This solves a different, but related issue.


 would this draft change the setting of the AA bit on an secondary server's
 responses, or make it unwilling to answer under some conditions? right now
 there is no dependency, AA is always set. but if we're going to make it
 conditional, then it should be conditioned on the signatures matching all
 the way up-chain to a trust anchor, which would require an authority server
 to also contain a validator and be able to make iterative queries. so, i
 wonder about the use case for your draft.


 --
 Paul Vixie



This allows a slave (or anyone else who wants to validate a zone, e.g a
master loading from disk) to know that they have a full and correct zone.
This covers things like accidental zone truncation (which has bitten some
folk), zone file corruption, etc. if someone hands me a zone somehow (e.g
AXFR) and asks me to serve it I'd like a way to make sure it hasn't been
accidentally (or intentionally) changed. I'm assuming I'd want my name
server software to refuse to load the zone and try retransfer, throw an
error, or similar.
The signature could be (and the way I'd envisioned it) DNSSEC, so up to a
TA, or a manually configured key specific to the zone.

W


-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[Warren Kumari]

On Thursday, November 27, 2014, Francisco Obispo fobi...@uniregistry.link
wrote:

 +1

 And if someone is already serving the root zone, they can always modify
 the server to return AA.

 I'm also wondering about the use case.


See above - this has *nothing* to do with setting or not setting AA. This
simply allows the entity serving a zone to confirm that they have a
complete, uncorrupt, and untampered copy of the zone. Think of it as a
cryptographic checksum if you like.
Before serving a zone (as a master or slave) I'd like to know it is
correct...

W



 Francisco Obispo

 On Nov 27, 2014, at 1:55 PM, Paul Vixie p...@redbarn.org
 javascript:_e(%7B%7D,'cvml','p...@redbarn.org'); wrote:



  postbox-contact.jpg
  Warren Kumari javascript:_e(%7B%7D,'cvml','war...@kumari.net');
  Thursday, November 27, 2014 1:11 PM
 ... and Mark Andrews, Paul Hofmann, Paul Wouters, myself and a few others
 (who I embarrassing enough have forgotten) are planning on writing a zone
 signature draft (I have an initial version in an edit buffet). The 50,000
 meter view is:
 Sort all the records in canonical order (including glue)
 Cryptographicly sign this
 Stuff the signature in a record

 This allows you to verify that you have the full and complete zone
 (.de...) and that it didn't get corrupted in transfer.
 This solves a different, but related issue.


 would this draft change the setting of the AA bit on an secondary server's
 responses, or make it unwilling to answer under some conditions? right now
 there is no dependency, AA is always set. but if we're going to make it
 conditional, then it should be conditioned on the signatures matching all
 the way up-chain to a trust anchor, which would require an authority server
 to also contain a validator and be able to make iterative queries. so, i
 wonder about the use case for your draft.

 --
 Paul Vixie

 ___
 dns-operations mailing list
 dns-operations@lists.dns-oarc.net
 javascript:_e(%7B%7D,'cvml','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



-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
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] Looking for a public blackhole/sinkhole IP address

[Warren Kumari]

On Wed, Nov 26, 2014 at 12:46 PM, Jared Mauch ja...@puck.nether.net wrote:

 On Nov 26, 2014, at 10:13 AM, Paul Wouters p...@nohats.ca wrote:

 http://tools.ietf.org/html/rfc6598 defines 100.64.0.0/10

   Packets with Shared Address Space source or destination addresses
   MUST NOT be forwarded across Service Provider boundaries.  Service
   Providers MUST filter such packets on ingress links.  One exception
   to this paragraph's proscription is in the case of business
   relationships, such as hosted CGN services.

   When running a single DNS infrastructure, Service Providers MUST NOT
   include Shared Address Space in zone files.  When running a split DNS
   infrastructure, Service Providers MUST NOT include Shared Address
   Space in external-facing zone files.

 So you should be fine to use it :)


 That’s certainly not the intent/purpose of the block of space any more than
 hard-coding 10.0.0.1 or some other answer like 1.1.1.1 or 1.2.3.4.

N. not 1.2.3.4:
route-viewssho ip bgp 1.2.3.4
BGP routing table entry for 1.2.3.0/24, version 60
Paths: (35 available, best #27, table default)
  Not advertised to any peer
  Refresh Epoch 1
  6453 15169
66.110.0.86 from 66.110.0.86 (66.110.0.86)
  Origin IGP, localpref 100, valid, external
  rx pathid: 0, tx pathid: 0


What's wrong with 127.0.0.1? It makes it clear what the intent is, and
you don't get a much more distributed sinkhole than that...

If there really is a use case, let's try and get a block allocated,
and encourage folk to anycast - null0 for this.
I'm kinda leery of using the AS112 addresses themselves, because the
target of this is likely to be DoS attacks and:
A: AS112 folk might not really be expecting to be hit with a few
hundred gig of garbage (yet) and
B: some ISP will nail up the routes to null, and mess up the AS112 customers.
W


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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
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] Looking for a public blackhole/sinkhole IP address

[Warren Kumari]

On Wed, Nov 26, 2014 at 4:10 PM, Joe Abley jab...@hopcount.ca wrote:

 On 26 Nov 2014, at 14:06, Warren Kumari war...@kumari.net wrote:

 What's wrong with 127.0.0.1? It makes it clear what the intent is, and
 you don't get a much more distributed sinkhole than that...

 I'm always wary of using 127.0.0.1 for anything that doesn't really mean you 
 should talk to yourself. Without a comprehensive knowledge of the impact, 
 you don't know what you're blowing up.

 If there really is a use case, let's try and get a block allocated,
 and encourage folk to anycast - null0 for this.

 https://github.com/ableyjoe/draft-jabley-well-known-sinkhole


This thingie has many aspects that look a bunch like AS112 -- I'm
wondering if it makes sense to also request an AS number for this.
It's not strictly needed, but having fewer inconsistent origin routes
is always nice.

It also seems that (also like AS112), networks could do this in one of
(at least) 3 ways:
1: They can spin up this route purely within their own network  --
basically have one or more places where the route points at null0 /
discard and *not announce it to peers / customers* or
2: announce to customers only or
3: be good citizens and announce it to everyone.

1 and 2 already exist, for RTBH (like you mention in the doc), they
are just not anycasted. I wonder if we ask the IANA nicely if they'd
assign 666.666.666.0/24 to.. oh, bugger

The more people who do this, the more benefit there is - unfortunately
this argument often doesn't work on the Internets, but still worth
trying...


 Needs text. Not submitted. Co-authors welcome.

I'm making some edits, will send a pull request in a bit.
Specifically the guidance to network operators section, and I'll take
an initial stab at a privacy considerations bit. I'm guessing that we
are going to have somewhat of a fun time with the privacy / security
implications bits. It won't be long till someone hits upon the idea of
standing up a listener / server on one of these addresses. One would
hope that the traffic that would arrive at a global sinkhole would be
safe, but seeing as some of the uses for this would be to sink bad
stuff, someone will want to measure how much bad stuff domain or
malware XXX is generating - this will require looking at the bad stuff
to disambiguate this bad stuff from that bad stuff, and now you
have a bit of a mess... Perhaps this actually turns out to be a
dangerous idea.

W



 Joe



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
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] An simple observation

[Warren Kumari]

On Thu, Sep 25, 2014 at 9:26 AM, Matthew Pounsett m...@conundrum.com wrote:

 On Sep 24, 2014, at 21:27 , Davey Song songlinj...@gmail.com wrote:

 Hi everyone, I‘m recently doing a little survey on the penetration of IPv6 
 in DNS system and it's latent problems.

 I find that top websites like Google, Wikipedia,Yahoo already support IPv6 
 access, but its name servers are still IPv4-only. I'm wondering why? is 
 there any operation consideration or risk in their IPv6 deployment?

 There is additional operational complexity in running a dual-stack network, 
 which implies some risk, but in my opinion it’s not serious enough to be a 
 real blocker for most networks.  Some companies may have legacy assumptions 
 in their application that makes adding IPv6 difficult in some way, but from 
 the outside it’s impossible to identify who those networks might be.

 Some large companies simply have their own inertia to overcome.  It can take 
 a while to get large re-engineering projects moving in larger companies, and 
 they may need/want to wait until the infrastructure is in place everywhere 
 before turning it on anywhere.

 It’s a little weird to me that google’s authoritative DNS servers are not 
 addressable over v6.  Their Google Public DNS service does operate over v6, 
 so clearly they have the infrastructure in place.

Google has been focusing on IPv6 for the user first -- for example,
the Google Public DNS stuff, the web interface, etc. Obviously enough,
this involved a bunch of infrastructure work...

For the auth nameservers -- there is work underway, and, AFAIK, there
should measurement of the impact of v6 glue soon.

This is not a risk free operation -- there are name-servers out there
that believe that they have working v6, but don't, and also places
where the v6 latency differs from the v4 latency. Measuring and
understanding all the implications before flipping the big switch is
important

  I’m speculating, but perhaps there are bits of their internal CDN-like 
 behaviour that still need to be modified.

 In short, no there are no generally applicable technical reasons not to be 
 running v6 on your DNS servers.

W


 ___
 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

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

[Warren Kumari]

[ Note: I haven't had my morning coffee yet, this post likely rambling
/ incoherent... ]

What ever happened to the let's use the glue as a service address
trick? There was some drama about this a number of years ago, but it
died down, possibly as bandwidth and DNS became cheaper...

I cannot remember all the details, but basically I create a host
object (nameserver) named whatever the service I want to serve is --
so, if I have example.com, I register the nameserver as
'www.example.com', with the IP of my webserver, and now most of my
lookups are handled simply by the glue. I also run a nameserver on
that address, which has records for everything other than www (or
whatever) record.

There were some issues (other than agility) that my caffeine deprived
brain cannot bring to mind, but...

W

On Fri, Sep 12, 2014 at 8:28 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote:
 On Fri, Sep 12, 2014 at 12:46:29PM +0100,
  Tony Finch d...@dotat.at wrote
  a message of 27 lines which said:

 they have switched to a more standard EPP implementation.

 This is absolutely NOT more standard. EPP allows both models (in
 other words, you do not have to implement RFC 5732).
 ___
 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[Warren Kumari]

I'd always thought that this was kinda because of the way EPP is written --
not that it is actually required, but when reading the docs you see the
nameservers object and kinda assume...

I think at this point much of it is hysterical raisons.

W

On Thursday, September 11, 2014, Stephane Bortzmeyer bortzme...@nic.fr
wrote:

 On Thu, Sep 11, 2014 at 07:52:31AM -0700,
  Colm MacCárthaigh c...@stdlib.net javascript:; wrote
  a message of 26 lines which said:

  So why is it that name servers need to be registered? What's the
  benefit of doing it?

 As an employee of a registry which does not require name server
 registration, I wonder, too :-)
 ___
 dns-operations mailing list
 dns-operations@lists.dns-oarc.net javascript:;
 https://lists.dns-oarc.net/mailman/listinfo/dns-operations
 dns-jobs mailing list
 https://lists.dns-oarc.net/mailman/listinfo/dns-jobs



-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
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] First new gTLD using ICANN's Name Collision Occurrence Management Framework

[Warren Kumari]

On Thu, Aug 28, 2014 at 12:50 PM, SM s...@resistor.net wrote:
 Hi Chris,

 At 05:38 28-08-2014, Chris Thompson wrote:

 The gTLD otsuka, created sometime in the last 24 hours, appears to be
 the
 first to use the wildcards described at


 [snip]


 What do people think about this business? Is anyone taking specific
 precautions
 to detect attempts to connect to 127.0.53.53?


 I presume that the people who invented this stuff know what they are doing.

Mwahahahahahhah hahhhahaha teehee...

Thanks, I needed that.
W



 Regards,
 -sm
 ___
 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
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] First new gTLD using ICANN's Name Collision Occurrence Management Framework

[Warren Kumari]

On Thursday, August 28, 2014, Rod Rasmussen 
rod.rasmus...@internetidentity.com wrote:

 I note that these documents speak to many of the issues being exposed here
 (and yes, full disclosure, I wrote a small portion of the text/reviewed
 them):


Yah, me too...

W


 https://www.icann.org/en/system/files/files/sac-062-en.pdf
 https://www.icann.org/en/system/files/files/sac-066-en.pdf

 Draw your own conclusions.

 Cheers,

 Rod

 On Aug 28, 2014, at 9:50 AM, SM s...@resistor.net javascript:; wrote:

  Hi Chris,
  At 05:38 28-08-2014, Chris Thompson wrote:
  The gTLD otsuka, created sometime in the last 24 hours, appears to be
 the
  first to use the wildcards described at
 
  [snip]
 
  What do people think about this business? Is anyone taking specific
 precautions
  to detect attempts to connect to 127.0.53.53?
 
  I presume that the people who invented this stuff know what they are
 doing.
 
  Regards,
  -sm
  ___
  dns-operations mailing list
  dns-operations@lists.dns-oarc.net javascript:;
  https://lists.dns-oarc.net/mailman/listinfo/dns-operations
  dns-jobs mailing list
  https://lists.dns-oarc.net/mailman/listinfo/dns-jobs



-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] DNS load-balancing/failover using an ASR 9xxx (few questions)

[Warren Kumari]

On Thu, Aug 14, 2014 at 6:00 PM, Nat Morris n...@nuqe.net wrote:
 On 14 August 2014 18:48, Jake Zack jake.z...@cira.ca wrote:
 In the ASR 9xxx series with IOS XR, the “ipsla” that it has available
 doesn’t seem to do either TCP connections or UDP DNS queries.  It seems my
 only real option is to monitor for ICMP reachability and nothing else.

 Anyone have a better solution?  I’ve considered throwing a wrapper around
 BIND doing OSPF updates and such…but it seems unideal.

What seems unideal about it? It is a well know and understood
technique, relies only on open and tested core features. I'd suggest
doing BGP instead of OSPF, but much of that is personal preference...


 BGP sessions between the ASR 9 and each DNS server in the cluster,
 ExaBGP running on them announcing their loopback/service /32 + /128
 address(es).

Yup, this also only uses well know, well understood systems - with
anything like the Cisco solution you end up with vendor lock-in - and
are subject to their whims (like what Jake described). ipsla is not
part of their core features and so changes over releases / platforms.
I'm sure they'd be happy to sell you an ACE though :-)


 Health check scripts on each service to probe for service ability,
 retract the announcement upon failure.

 --
 Nat

 https://nat.ms
 +44 7531 750292

 ___
 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
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] A report on a DNS issue that was causing page redirections

[Warren Kumari]

On Wed, Aug 13, 2014 at 3:38 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote:
 On Tue, Aug 12, 2014 at 06:59:37PM +0200,
  Stephane Bortzmeyer bortzme...@nic.fr wrote
  a message of 14 lines which said:

 The author says your domain name registrar can introduce an error to
 the root domain database and match your domain to an incorrect DNS
 servers (this actually happened earlier in history of some domain
 registrars) but my human memory cannot find an actual documented
 case. Anyone can mention one or was it just speculation?

 One case mentioned by Tony which is not exactly that, but close:

 http://news.netcraft.com/archives/2005/01/18/lapse_at_melbourne_it_enabled_panixcom_hijacking.html

 One mentioned in ANSSI's guide on DNS:

 http://blogs.cisco.com/security/hijacking-of-dns-records-from-network-solutions/

 [If you take Network Solutions' words literally...]

 DNSSEC would have mitigated the problem if the domain had been
 properly managed, which was apparently not the case.

ObRef:
SAC044 - A Registrant's Guide to Protecting Domain Name Registration
Accounts  [https://www.icann.org/en/groups/ssac/documents/sac-044-en.pdf]
SAC040 - Measures to Protect Domain Registration Services Against
Exploitation or Misuse
[https://www.icann.org/en/groups/ssac/documents/sac-040-en.pdf (also
available in multiple languages, links here:
https://www.icann.org/resources/pages/documents-2012-02-25-en)]
SAC028 - Registrar Impersonation Phishing Attacks
[https://www.icann.org/en/groups/ssac/documents/sac-028-en.pdf]
SAC007 - Domain Name Hijacking Report (SAC007) (12 July 2005)
[https://www.icann.org/announcements/hijacking-report-12jul05.pdf]
SAC049 -  DNS Zone Risk Assessment and Management (03 June 2011)
[https://www.icann.org/en/groups/ssac/documents/sac-049-en.pdf]

Unfortunately many registrants are not adequately protecting their
domains, especially the registrar credentials. The suggestions in the
above documents[0] don't solve all domain hijacks (ask me how I know
:-)), but would cut down on a large number of them, and / or make
recovery faster / easier[1].

W
[0]: Full disclosure: Member of SSAC, contributor to a number of the
above documents.
[1]: This feels like a BCP38 type discussion. Not sure if posting
these will make any difference, but next time there is a hijack that
could have been prevented by the above, at least I can say Nah, nah,
told you so!. This is not helpful to the registrant, but might make
me feel better :-P




 Someone asked me to be more precise: if the DNS hoster does both the
 provisioning (including the signing) and the publication on its DNS
 servers, then, DNSSEC would not help (GIGO). But if the user does the
 provisioning / signing, and relies on the DNS hoster just for
 publication (the user being just a stealth master), DNSSEC would
 protect against blunders by the DNS hoster.

 ___
 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
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] Why would a recusrive caching server not resolve a CNAME?

[Warren Kumari]

On Sun, Jul 6, 2014 at 3:45 PM, Mohamed Lrhazi ml...@georgetown.edu wrote:
 Thanks Lyle, I did not mean to say that list was defunct, quite the
 opposite, I felt that I was a bit spamming it with non global operational
 DNS issue

Nah. No worries. This list traditionally has a wide range of topics.
Your mail was polite and sane, and you seem interested in learning.

Entirely appropriate (IMO) for this list.

W


 Yes, I did not debug well, went for the quick fix of clearing the cache
 That being said, end users query for the name and the IPs, always... but
 then here they were only getting the CNAME... so am trying to figure out in
 what circumstances would that occur... Would a recursive resolver that has
 the CNAME in cache, but the A records expired, fail to resolve the A
 records, return just the CNAME?

 Thanks a lot,
 Mohamed.


 On Sun, Jul 6, 2014 at 3:13 PM, Lyle Giese l...@lcrcomputer.net wrote:

 You waited less than an hour before proclaiming the list defunct?  It's
 Sunday in most of the world.  Most of us are doing other things than sitting
 on this list.

 That said, my initial thought is that your server answered your question.
 Nothing more.  Did you ask it for the A record for googlemail.l.google.com ?
 That might have told you more.

 Lyle Giese
 LCR Computer Services, Inc.


 On 07/06/14 13:38, Mohamed Lrhazi wrote:

 I am thinking this list is not appropriate for some of my questions...
 Could someone suggest a better one, maybe as active and rich, as this one,
 but more appropriate for general DNS discussions?

 Thanks a lot,
 Mohamed.


 On Sun, Jul 6, 2014 at 2:02 PM, Mohamed Lrhazi ml...@georgetown.edu
 wrote:

 We had a little mail outage which turned out to be caused by one of our
 caching DNS servers returning the bellow incomplete reply.

 Clearing the cache on the problematic server fixed the issue

 Am thinking it is now impossible for me to find the root cause in this
 instance... but wondering if you guys could hint at what could cause such a
 problem... bugs in the DNS servers involved? temporary misconfig at Google's
 servers? network issue?

 The setup is a bit convoluted:

 cache server -- resolver cache server -- Internet

 The fix was clearing at the first server. so I am guessing at some point
 the resolver gave the incomplete answer.

 Thanks a lot,
 Mohamed.

 ➜  ~  dig mail.google.com @141.161.100.201

 ;  DiG 9.9.5-3-Ubuntu  mail.google.com @141.161.100.201
 ;; global options: +cmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 20414
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5

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

 ;; ANSWER SECTION:
 mail.google.com. 10213 IN CNAME googlemail.l.google.com.

 ;; AUTHORITY SECTION:
 google.com. 96485 IN NS ns2.google.com.
 google.com. 96485 IN NS ns3.google.com.
 google.com. 96485 IN NS ns4.google.com.
 google.com. 96485 IN NS ns1.google.com.

 ;; ADDITIONAL SECTION:
 ns3.google.com. 108462 IN A 216.239.36.10
 ns4.google.com. 108462 IN A 216.239.38.10
 ns1.google.com. 108462 IN A 216.239.32.10
 ns2.google.com. 108462 IN A 216.239.34.10

 ;; Query time: 22 msec
 ;; SERVER: 141.161.100.201#53(141.161.100.201)
 ;; WHEN: Sun Jul 06 12:42:09 EDT 2014
 ;; MSG SIZE  rcvd: 207





 ___
 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 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 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 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] Forcing BIND to randomly expire records from cache ahead of time

[Warren Kumari]

On Thu, Jul 3, 2014 at 6:04 PM, Tim Wicinski tjw.i...@gmail.com wrote:

 Mark

 Unbound has this feature, but its' a % of the TTL (oh they may of changed
 this).

 You may be also interested in this idea which was floated during IETF, and
 not rejected, just a small sliver of useful customer base:

 http://tools.ietf.org/id/draft-wkumari-dnsop-hammer-00.txt

... and, almost exactly one year later, we are *finally* rev'ing that
document (I just edited it this afternoon, Suzanne is giving it the
once over as we speak, and we are planning on submitting in the next
hour (you know, just before the draft cutoff :-) - “I love deadlines.
I love the whooshing noise they make as they go by.” — Douglas Adams,
The Salmon of Doubt )

The new version mainly described the general concept, and that
OpenDNS, Unbound and BIND 10 do something like this. In a somewhat
contrived bit of writing, it also manages to keep the Stop! Hammer
time! references...

W





 On 7/3/14 5:06 PM, Mark Pettit wrote:

 Hi, folks.

 I have an issue with BIND cache timeouts, and I was hoping someone else
 might have some idea how to fix this.

 Here's the situation: we have a large number of servers that do a huge
 number of DNS lookups at the top of every minute. The TTL for the
 records they're looking up is 3600.

 What we've noticed is that on a host with a recently-restarted copy of
 BIND, we see huge spikes in DNS latency every 61 minutes. This makes
 logical sense, given the behavior of the DNS lookups.

 What is more interesting is that on hosts that have been running BIND
 for a very long time (on the order of months), the spikiness is not
 visible.

 Our speculation is that over time, due to the interaction between the
 3600 TTL and the once every minute lookup behavior, cache misses
 become randomly distributed throughout the hour, and don't cause the
 spiky behavior that is observed initially.

 One of our ideas to resolve this is to randomize the TTLs in the zone
 files, causing them to expire out of cache at different times, thus
 forcing more-rapid distribution of cache misses across the hour.

 However, this would involve some massive edits to our zone files, and
 isn't really ideal.

 What *would* be ideal would be if we could tell BIND to randomly expire
 some small percentage of cached entries ahead of the actual TTL
 expiration. This would serve the same purpose as assigning random TTLs
 to the actual records in the zone files.

 Does BIND have a config option like this? Has anyone else ever
 encountered this issue, and if so, how did you address it?

 Thanks for any advice, and I hope everyone has a fantastic Fourth of
 July weekend.

 Mark Pettit



 ___
 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 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 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] Forcing BIND to randomly expire records from cache ahead of time

[Warren Kumari]

On Friday, July 4, 2014, Warren Kumari war...@kumari.net wrote:

 On Thu, Jul 3, 2014 at 6:04 PM, Tim Wicinski tjw.i...@gmail.com
 javascript:; wrote:
 
  Mark
 
  Unbound has this feature, but its' a % of the TTL (oh they may of changed
  this).
 
  You may be also interested in this idea which was floated during IETF,
 and
  not rejected, just a small sliver of useful customer base:
 
  http://tools.ietf.org/id/draft-wkumari-dnsop-hammer-00.txt

 ... and, almost exactly one year later, we are *finally* rev'ing that
 document (I just edited it this afternoon, Suzanne is giving it the
 once over as we speak, and we are planning on submitting in the next
 hour (you know, just before the draft cutoff :-) - “I love deadlines.
 I love the whooshing noise they make as they go by.” — Douglas Adams,
 The Salmon of Doubt )

 The new version mainly described the general concept, and that
 OpenDNS, Unbound and BIND 10 do something like this. In a somewhat
 contrived bit of writing, it also manages to keep the Stop! Hammer
 time! references...


... and we managed to squeeze it in under the deadline. I did (of course)
mean BIND 9.10 in the previous mail, and not BIND 10, which is a whole
different kettle of fish. That'll teach me to write mail inna rush...

W



 W


 
 
 
  On 7/3/14 5:06 PM, Mark Pettit wrote:
 
  Hi, folks.
 
  I have an issue with BIND cache timeouts, and I was hoping someone else
  might have some idea how to fix this.
 
  Here's the situation: we have a large number of servers that do a huge
  number of DNS lookups at the top of every minute. The TTL for the
  records they're looking up is 3600.
 
  What we've noticed is that on a host with a recently-restarted copy of
  BIND, we see huge spikes in DNS latency every 61 minutes. This makes
  logical sense, given the behavior of the DNS lookups.
 
  What is more interesting is that on hosts that have been running BIND
  for a very long time (on the order of months), the spikiness is not
  visible.
 
  Our speculation is that over time, due to the interaction between the
  3600 TTL and the once every minute lookup behavior, cache misses
  become randomly distributed throughout the hour, and don't cause the
  spiky behavior that is observed initially.
 
  One of our ideas to resolve this is to randomize the TTLs in the zone
  files, causing them to expire out of cache at different times, thus
  forcing more-rapid distribution of cache misses across the hour.
 
  However, this would involve some massive edits to our zone files, and
  isn't really ideal.
 
  What *would* be ideal would be if we could tell BIND to randomly expire
  some small percentage of cached entries ahead of the actual TTL
  expiration. This would serve the same purpose as assigning random TTLs
  to the actual records in the zone files.
 
  Does BIND have a config option like this? Has anyone else ever
  encountered this issue, and if so, how did you address it?
 
  Thanks for any advice, and I hope everyone has a fantastic Fourth of
  July weekend.
 
  Mark Pettit
 
 
 
  ___
  dns-operations mailing list
  dns-operations@lists.dns-oarc.net javascript:;
  https://lists.dns-oarc.net/mailman/listinfo/dns-operations
  dns-jobs mailing list
  https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
 
  ___
  dns-operations mailing list
  dns-operations@lists.dns-oarc.net javascript:;
  https://lists.dns-oarc.net/mailman/listinfo/dns-operations
  dns-jobs mailing list
  https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

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

[Warren Kumari]

On Wed, Jul 2, 2014 at 8:19 AM, Tony Finch d...@dotat.at wrote:
 Mohamed Lrhazi ml...@georgetown.edu wrote:

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

 Surely it has an interlock to prevent a KSK rollover going ahead without a
 DS change?!

Obligatory pointer at document that *should* automate this, and so
prevent bad KSK rolls (if deployed :-)):
https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/

Basically, when the signing tool rolls the key, it publishes the new
key in the zone, the parent (registrar or registry) periodically
scrapes the zone and then publishes the new DS.

Currently with the RFC Editor.

W

(FD: author).


 Tony.
 --
 f.anthony.n.finch  d...@dotat.at  http://dotat.at/
 South Utsire: Westerly 3 or 4, backing southwesterly 5 or 6 for a time. Slight
 or moderate. Rain for a time. Good, occasionally moderate.
 ___
 dns-operations mailing list
 dns-operations@lists.dns-oarc.net
 https://lists.dns-oarc.net/mailman/listinfo/dns-operations
 dns-jobs mailing list
 https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
___
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] most of root NS and com's NS fail from here

[Warren Kumari]

On Tue, Apr 29, 2014 at 2:18 PM, bert hubert bert.hub...@netherlabs.nl wrote:

 On 29 Apr 2014, at 20:55, Emmanuel Thierry m...@sekil.fr wrote:


 What we may observe from tests is that some dns servers failed without an 
 obvious connectivity problem (ping is OK). As a consequence, i think it 
 would be really interesting to test for instance with an arbitrary dns 
 server and see whether it fails or not.


 Even root-servers that are down have been known to respond as observed from 
 China. Sometimes within less milliseconds than it takes to reach the border.

 It is not internet as ‘we’ know it there.

What would be interesting to see would be nsid, hostname.bind, etc
from the NS to *do* resolve.
E.g:

dig -4 @l.root-servers.net hostname.bind CH TXT
dig -4 @l.root-servers.net . SOA +nsid

W



 Bert

 ___
 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 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] most of root NS and com's NS fail from here

[Warren Kumari]

On Tue, Apr 29, 2014 at 5:06 PM, Xun Fan xun...@isi.edu wrote:



 On Tue, Apr 29, 2014 at 1:52 PM, Warren Kumari war...@kumari.net wrote:

 On Tue, Apr 29, 2014 at 4:45 PM, Xun Fan xun...@isi.edu wrote:
  China has it's own root nodes is confirmed long ago, we published that
  in
  our paper https://ant.isi.edu/blog/?p=362

 Yup, believe me, I'm fully aware of that (and have read this, and many
 other papers, have done some of my own testing on a number of trips to
 Beijing, etc) -- unfortunately while I was there I didn't think to
 test NSID / hostname.bind /  IDENTITY.L.ROOT-SERVERS.ORG, etc
 responses to see how convincing a lie^w optimization the servers
 provide.


 Oh, sure, I totally agree NSID/hostname.bind etc. will be very helpful.

 My experience is that if these query hit a masquerading root node, you
 mostly won't get an answer, by either no ANSWER section or empty string
 in ANSWER section.


Ah, excellent. Thank you.
W


 And another thing is the masquerading node is not always there. Sometimes
 our query hit the real root node and everything is correct (NSID,
 hostname.bind, etc.).
 But we didn't collect data continuously, so we don't know the exact pattern.



 
  Just pinged H-root from CERNET of China:
  $ ping h.root-servers.net
  PING h.root-servers.net (128.63.2.53) 56(84) bytes of data.
  64 bytes from 128.63.2.53: icmp_seq=1 ttl=55 time=9.63 ms
  64 bytes from 128.63.2.53: icmp_seq=2 ttl=55 time=9.56 ms
 
  9ms is faster than the speed of light, given the two H-root sites are
  both
  in US and the ping source is in Shanghai.
 
  For the failure in China telecom, one possible explanation is that
  somehow
  the route to the Chinese H-root doesn't propagate to some server in
  China
  telecom, while the GFW has already started to drop packets from real
  H-root.


 Yup.
 W

 
 
  On Tue, Apr 29, 2014 at 12:15 PM, Warren Kumari war...@kumari.net
  wrote:
 
  On Tue, Apr 29, 2014 at 2:18 PM, bert hubert
  bert.hub...@netherlabs.nl
  wrote:
  
   On 29 Apr 2014, at 20:55, Emmanuel Thierry m...@sekil.fr wrote:
  
  
   What we may observe from tests is that some dns servers failed
   without
   an obvious connectivity problem (ping is OK). As a consequence, i
   think it
   would be really interesting to test for instance with an arbitrary
   dns
   server and see whether it fails or not.
  
  
   Even root-servers that are down have been known to respond as
   observed
   from China. Sometimes within less milliseconds than it takes to reach
   the
   border.
  
   It is not internet as ‘we’ know it there.
 
  What would be interesting to see would be nsid, hostname.bind, etc
  from the NS to *do* resolve.
  E.g:
 
  dig -4 @l.root-servers.net hostname.bind CH TXT
  dig -4 @l.root-servers.net . SOA +nsid
 
  W
 
 
  
   Bert
  
   ___
   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 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 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?

[Warren Kumari]

On Mon, Jan 13, 2014 at 10:54 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote:
 On Sat, Jan 11, 2014 at 06:32:00PM +0100,
  Peter Koch p...@denic.de wrote
  a message of 21 lines which said:

 Take a breath - or let the compliance jihad begin:

 These ICANN rules (against dotless domains) are meaningless and
 ridiculous, anyway. I agree that such a TXT or TYPE65534 does no harm
 and should not be forbidden. If it is, it means the law is wrong
 (Dickens?)

Perhaps -- but them's the laws (in *this* context).
ccTLDs are not constrained by these, new gTLDs are -- they signed a contract.

If you believe the laws are wrong (as many do!), come help change them.
I personally think that many of the USA laws are wrong, but seeing as
I don't (usefully) participate in the political process I've lost the
right to kvetch...


W
And yes, they are not laws, they are contracty bits, and participating
is hard / icky, but...

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

[Warren Kumari]

On Oct 25, 2013, at 1:33 PM, Edward Lewis ed.le...@neustar.biz wrote:

 Randy,
 
 On Oct 25, 2013, at 9:45, Randy Bush wrote:
 
 the ip address clumping would worry me if i thought they were not anycast.
 
 Anycast or not, I wouldn't think this is a problem.  Meaning, I don't see why 
 this would be a problem with unicast.  Assuming that (for v4) the /24's are 
 independently routed, it wouldn't matter if the numbers are numerically close 
 or not.

Well, it *might* -- having a wider separation of addresses (and multiple AS#) 
reduce the risk of someone accidentally misconfiguring an ACL and blocking 
access….

Lets say your space is 192.0.2.0/24 and 192.0.3.0/24 -- it's possible that 
someone intending to ACL 192.0.0.0/24 and 192.0.1.0/24 makes a booboo and ACLs 
off 192.0.0.0/22 instead of 192.0.0.0/23. While this sound alike a theoretical 
/ unlikely issue, it *does* happen -- ask me how I know…

W

 
 I ask because I might be missing something.  And assuming it's a given that 
 to an external endpoint, anycast is indistinguishable to unicast.  I can't 
 tell if that's two routes to a multi-homed LAN or two routes that diverge 
 geographically.
 
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Edward Lewis 
 NeuStarYou can leave a voice message at +1-571-434-5468
 
 There are no answers - just tradeoffs, decisions, and responses.
 
 ___
 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

--
She'd even given herself a middle initial - X - which stood for someone who 
has a cool and exciting middle name.

-- (Terry Pratchett, Maskerade)


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

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

[Warren Kumari]

On Oct 21, 2013, at 4:39 PM, Phil Regnauld regna...@nsrc.org wrote:

 Michele Neylon - Blacknight (michele) writes:
 
 Yes, I've noticed that Google is still not signing.  Maybe the
 continuing hijackings of their ccTLD domains will move them.
 
 I suspect they're more interested in getting registry lock in place rather 
 than DNSSEC.
 
   That'd be assuming most registries have the concept of lock, which is
   far from being the case.

Some do, some don't… 
In some cases the registry lock is actually just a comment in a zone file, 
saying something along  the lines of:
;  WARNING -
; Don't change this!
; Call Warren at +1-xxx-xxx- before making any changes.
;  WARNING ---

In a number of cases registries don't officially support locks, but have been 
willing to do something unusual for a beer / friend.

 
 Most of the attacks against Google have involved changing the name servers 
 completely .. 
 
   Through social engineering and sometimes through directed attacks, yes.

Sadly yes. 

W

 
   Cheers,
   Phil
 ___
 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
 

---
Tsort's Constant: 
1.67563, or precisely 1,237.98712567 times the difference between the distance 
to the sun and the weight of a small orange. 
-- Terry Pratchett, The Light Fantastic (slightly modified)

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

Re: [dns-operations] Should medium-sized companies run their own recursive resolver?

[Warren Kumari]

On Oct 16, 2013, at 10:59 AM, Jared Mauch ja...@puck.nether.net wrote:

 
 On Oct 15, 2013, at 7:28 PM, Vernon Schryver v...@rhyolite.com wrote:
 
 Folks like Comcast have large validating resolvers.  Their customers should 
 use them.  Folks here are surely going to do the right thing the majority 
 of the time.  The vast majority of others are going to set things up once 
 and it *will* be left to rot.  This isn't intentional, but it naturally 
 happens.
 
 The question had nothing to do about J. Sixpack with 37 televisions,
 phones, and other devices behind a NAT router owned by and remotely
 maintained by Comcast.  Instead the question concerned a business with
 2 IT professionals.  Relying on distant DNS servers is negligent and
 grossly incompetent for a professionally run network. 
 
 As with many things we will have to disagree.
 
 Not everyone has the same skill set as those on this list, and that curve 
 goes down rather quickly.

Yup, but this *has* been an interesting thread -- it was sufficiently 
open-ended that everyone got to interpret it in whatever way wanted, and wander 
off in random but fascinating ways…

W

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

--
Hope is not a strategy.
  --  Ben Treynor, Google


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

Re: [dns-operations] Should medium-sized companies run their own recursive resolver?

[Warren Kumari]

On Oct 14, 2013, at 9:33 PM, Carlos M. Martinez carlosm3...@gmail.com wrote:

 Agreed. However, at least in my experience, it is usually easy to
 achieve high availability figures running a linux box on relatively
 cheap hardware, while links are much less dependable. I've seen 400-day
 plus uptimes on very cheap, dubious looking, PC clones.

Yup, me too -- however, average IT talents and Linux do not go together in 
the same sentence. 
You are most definitely not an average IT person….


 
 Now that I think of it, rather than the recursive DNS function, the
 local resolution of local resources is, IMO, a more important driver for
 running your local DNS. If you cater for a 100 person office, you
 probably have some printers, maybe a file server or two, some form of
 backup servicea, VoIP telephone service and maybe a local intranet/wiki.
 Hard-coding IPs for all these services in 100 workstations seems crazy
 to me.
 
 The, if you run a DNS for local services, also configuring it for
 recursion should be straightforward.
 

Yup, once agin, Windows AD and / or Bonjour type things come to the rescue -- 
you plugs in the printer and then click browse and then something happens 
somehow and you can print. So, if AD counts as DNS then, well…

W

 regards,
 
 ~Carlos
 
 
 On 10/14/13 4:09 PM, Wiley, Glen wrote:
 While the concern about the link to the outside world is an issue, the
 same concern holds for whatever provides your connectivity.  As a matter
 of practice, when designing for availability you want to focus on the
 least reliable layers in a stack before focusing on other layers,
 otherwise your availability improvements are potentially nil.
 
 If you can run a more reliable recursive server than your provider (or
 google or whoever) then by all means, however there are probably more
 meaningful places to spend your resources if you have a small company.
 
 On the other hand, if there is a functional reason for running your own
 recursive server that is entirely different, for example filtering via
 DNS, split view zones etc.
 
 ___
 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
 

--
When it comes to glittering objects, wizards have all the taste and 
self-control of a deranged magpie.
-- Terry Pratchett




___
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] .ORG website experiences intermittent DNS failure

[Warren Kumari]

Warren Kumari
--
Please excuse typing, etc -- This was sent from a device with a tiny keyboard.

 On Sep 30, 2013, at 8:22 PM, Paul Wouters p...@nohats.ca wrote:
 
 On Mon, 30 Sep 2013, Catherine Burdon wrote:
 
 Website www.newmarketstageco.org experiencing DNS failure intermittently.  I 
 have verified the DNS zone settings for the domain and all
 are correct.  From time to time the website will not be found, then shortly 
 thereafter will appear again.
 
 Its nameservers ns1.securehost.com. and ns2.securehost.com give SERVFAIL
 for newmarketstageco.org for all record types. Unless that's some kind
 of ANYcast, I'm not sure why it would intermittently at all.
 
 

Erm...

When I was looking the NS were ns1.myviabank.com, ns2.myviabank.com...

Did you get the securehost ones from the DNS or from this mail?

W


 Paul
 ___
 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 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?

[Warren Kumari]

On Aug 23, 2013, at 11:04 AM, Carlos M. Martinez carlosm3...@gmail.com 
wrote:

 I'm _very_ torn on the issue. On one hand I fully agree with Patrik in
 the sense that documenting such practices could lead to widespread
 'holes' in validation.
 
 However, in my opinion the first knee jerk reaction of a recursive
 resolver operator will probably be 'if 1M clients of mine are unable to
 access kittenvideos.com due to a DNSSEC screewup, I will just disable
 it'. Maybe such operators, if presented with the possibility of having
 NTAs may chose to use that.
 
 Again, I'm torn. I'm not sure what will work better in the real world,
 or produce the best outcomes in the long term.

All depends on if you actually want DNSSEC to be deployed or not.

If something like NTA (or some other way to override obvious DNSSEC screwups) 
didn't exist, do you *really* think that Comcast and 8.8.8.8 would be doing 
DNSSEC validation? Do you remember the fallout from the NASA screwup?

Simply telling your customers Yes, I know that it worked fine from 
$competitor, but we do things better here, and so you cannot see fluffy kitten 
chasing ball of yarn. It's for your own good, and it also teaches 
fkittenvideos.com to not suck so much… doesn't cut it.

W
 
 regards
 
 ~Carlos
 
 On 8/23/13 11:58 AM, David Conrad wrote:
 On Aug 22, 2013, at 5:13 PM, Paul Vixie p...@redbarn.org wrote:
 Randy Bush wrote:
  from a conversation with a friend wiser than i 
 
 the problem is that we are going through a deployment phase where there
 is little penalty for sloppy server ops because so few are validating.
 
 patching over this to be more tolerant of sloppy server ops is going in
 the wrong direction.  ...
 
 +1. we're currently debating placement of first mover advantage. today
 if you sign incorrectly you lose. with NTA at scale, if you sign
 incorrectly you won't lose.
 
 Sure you will.
 
 You screw up signing and you instantly lose.
 
 NTA allows other folks to not lose with you if they decide the pain of your 
 screwing up to them is sufficiently high to justify manual intervention.
 
 Not everyone will make the same value judgement and they all won't make it 
 at the same time.
 
 Regards,
 -drc
 
 
 
 ___
 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 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
 

-- 
Outside of a dog, a book is your best friend, and inside of a dog, it's too 
dark to read 


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

[Warren Kumari]

On Aug 23, 2013, at 12:19 PM, Paul Vixie p...@redbarn.org wrote:

 
 
 David Conrad wrote:
 On Aug 22, 2013, at 3:25 PM, Paul Vixie p...@redbarn.org
  wrote:
 
 
 ... over and above the absurd engineering economics behind it, i don't like 
 NTA. if my signatures don't work because i've been attacked (for example, 
 one of my name servers has been compromised), the last thing i'd want is 
 comcast telling their customers that the data they're getting from my 
 compromised name server is ok to consume because it's unsigned.
 
 
 Exactly so.  However pragmatically speaking if someone (say NASA perhaps?) 
 screws up signing their zone, it isn't the zone-signing-screwer-upper that 
 gets the phone calls, it is the eyeball networks that are doing the 
 validation.  Without NTA, the eyeball network operators have a choice, eat 
 the cost of those calls or turn off validation _for ALL signed zones until 
 the zone-signing-screwer-upper fixes their problem_.
 
 I gather you believe eating the cost is the right answer.  ...
 
 indirectly, yes.
 
 with RPZ, we made it possible for full service resolver operators (recursive 
 name server operators) to edit zone content as a matter of local policy. NTA 
 is not different in principle, but it's different in an important way: in 
 RPZ, the content being edited is malicious and/or criminal. where my mind 
 isn't bending well at the moment is where we edit in resolvers content 
 belonging to people who aren't malicious. since we can't know the reason why 
 their signatures are failing, telling our full service resolver and its 
 downstream stubs that there are no signatures is overreach.
 
 if nasa.gov had screwed up its delegation or had allowed its public secondary 
 servers to expire the zone due to primary unreachability, i do not think the 
 phone at comcast would have rung less, but i also don't think that comcast 
 would have fixed nasa's error in local policy.

Sure, true.

The untenable position for Comcast is having it not work for them, while still 
working for everyone else. In the scenario you described it would break for 
everyone, and you avoid the but it works at Verizon, I'm moving to them issue.


 we're only talking about this because DNSSEC is new.
 

Yup. And those trying to do the right thing (enabling validation for clients) 
should get the carrot, not the stick.
Explaining to bean counters that you are going to enable something that might 
drive customers to $competitor is hard, especially if a: the customers are not 
asking for it, b: your competitors don't offer it and c: handwaving is needed 
to explain the benefits. 

Much respect to Jason and the rest of the Comcast folk to being one of the 
first major NA ISPs to turn it on.
W

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

--
What our ancestors would really be thinking, if they were alive today, is: Why 
is it so dark in here?

-- (Terry Pratchett, Pyramids)


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

[Warren Kumari]

On Aug 21, 2013, at 1:33 AM, Ralf Weber ralf.we...@nominum.com wrote:

 Moin!
 
 On 20.08.2013, at 20:14, Doug Barton do...@dougbarton.us wrote:
 Rumor has it that Nominum and Fortidns have implementations for NTAs. Any 
 truth to those rumors?
 It's not a rumor. Nominum Vantio had this feature for some time now. As 
 FortiDNS uses that for DNS resolution I guess it also has it.
 
 Anyone else have an implementation?
 AFAIK Unbound also has that feature.
 
 Any patches for BIND?
 I don't know.
 
 FWIW, I remain opposed to the idea, but trying to do due diligence.
 I still like the idea as it is the only way for big resolver providers to 
 deploy DNSSEC when there competitors have not.

+lots. Penalizing the early adopters simply leads to no deployment. 

W

 
 So long
 -Ralf
 ---
 Ralf Weber
 Senior Infrastructure Architect
 Nominum Inc.
 2000 Seaport Blvd. Suite 400 
 Redwood City, California 94063
 ralf.we...@nominum.com
 
 
 
 ___
 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
 

-- 
American Non-Sequitur Society; 
we don't make sense, but we do like pizza!


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

[Warren Kumari]

On May 31, 2013, at 11:38 AM, Joe Abley jab...@hopcount.ca wrote:

 
 On 2013-05-31, at 11:24, Dobbins, Roland rdobb...@arbor.net wrote:
 
 There's no crypto anything inherent in DNS today, heh.
 
 Well, apart from the use of TSIG to authenticate zone transfers.
 
 As I mentioned obliquely, I haven't heard of any widespread use of TSIG or 
 SIG(0) to authenticate the channel between a stub resolver and a recursive 
 resolver, but I'd hesitate to deny that there's any deployment without 
 thinking of what numbers could possibly back up that claim.

From everything that I can tell, this is no deployment of .SIG between stub 
and recursive -- this is based upon the fact that I'd really *like* to be able 
to do this, and have spent some time looking into how, but no-one seems to 
know how to actually configure something to do this…

Running 'strings' on recover libraries *seems* to make it appear that the code 
exists, and asking folk who should know elicits Oh, yeah, you add, um, 
something to /etc/resolve.conf… I think it is called 'tsig-ke..' um, no, it's 
'key-tai…' um, yeah, I *think* this is doable, but I cannot remember at the 
moment *how*. I'll get back to you…

Yes, I realize I could just go actually go read the source, spend some cycles 
looking at lwres, etc, but I'd rather simply kvetch [0]

W

[0]: AKA, it hasn't risen to the top of my annoyance pile yet...

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

--
I think perhaps the most important problem is that we are trying to understand 
the fundamental workings of the universe via a language devised for telling one 
another when the best fruit is. --Terry Prachett 


___
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] A question about changing nameservers

[Warren Kumari]

On May 28, 2013, at 6:32 AM, Michele Neylon :: Blacknight 
mich...@blacknight.com wrote:

 Obvious question, but did you create the glue records?
 
 --
 Mr Michele Neylon
 Blacknight Solutions
 Hosting  Colocation, Brand Protection
 http://www.blacknight.com/
 http://blog.blacknight.com/
 http://mneylon.tel/
 Intl. +353 (0) 59  9183072
 Locall: 1850 929 929
 Direct Dial: +353 (0)59 9183090
 Fax. +353 (0) 1 4811 763
 Twitter: http://twitter.com/mneylon
 ---
 Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
 Road,Graiguecullen,Carlow,Ireland  Company No.: 370845
 
 
 From: dns-operations-boun...@lists.dns-oarc.net 
 [dns-operations-boun...@lists.dns-oarc.net] on behalf of Feng He 
 [fen...@nsbeta.info]
 Sent: 28 May 2013 11:07
 To: DNS Operations List
 Subject: [dns-operations] A question about changing nameservers
 
 Hello,
 
 My platform DNSbed.com has cloudwebdns.com as the nameserver domain.
 The DNS of cloudwebdns.com is currently hosted by:
 dns1.registrar-servers.com.
 dns2.registrar-servers.com.
 dns3.registrar-servers.com.
 dns4.registrar-servers.com.
 dns5.registrar-servers.com.
 
 Today I changed the nameservers to our own nameservers:
 ns1.cloudwebdns.com.
 ns2.cloudwebdns.com.
 ns3.cloudwebdns.com.
 ns4.cloudwebdns.com.
 
 I have added the zone to named.conf, created zone files, and reloaded
 BIND. But when I added a record by nsupdate, it got the error:
 
 response to SOA query was unsuccessful
 
 When I dig to localhost:
 dig cloudwebdns.com soa @localhost
 
 Got the status ServFail.
 
 Can you tell me what has happened?

This question might be more appropriate for the bind-users mailing list 
(https://lists.isc.org/mailman/listinfo/bind-users) , but…

Run  named-check-zone ( e.g: `named-checkzone cloudwebdns.com cloudwebdns.com`) 
as see if it complains about some syntax error. Chances are you made some 
editing mistake.
Otherwise, are you 100% sure that you edited the *correct* named.conf? (Often 
there end up being multiple copies, one from the system install and one from 
the user installed bind).

Also, check the log files (possibly /var/log/messages, or somewhere else, 
depending on how you have configured things), looking for evidence that it is 
actually trying to read the zone file.

W


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

--
When it comes to glittering objects, wizards have all the taste and 
self-control of a deranged magpie.
-- Terry Pratchett




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

Re: [dns-operations] DNS Issue

[Warren Kumari]

On Apr 26, 2013, at 4:32 AM, Dobbins, Roland rdobb...@arbor.net wrote:

 
 On Apr 26, 2013, at 12:27 AM, Warren Kumari wrote:
 
 I think that in many cases it is not that the named version doesn't support 
 randomization, but rather that they / their firewall group believes that 
 DNS should only be allowed on port 53 (and UDP, natch).
 
 The actual problem being that the DNS servers oughtn't to be behind a 
 firewall in the first place.

Oh, yeah, *fully* agree -- I meant to mention this in my response (actually I 
was just going to cut-n-paste from an earlier rant on the subject) but forgot.

I'd probably s/firewall/firewall, load-balancer or anything else that keeps 
state/ -- I know you already mentioned statefull things further down in the 
thread, but for some reason many folk don't think of load-balancers as keeping 
state[0]...

W
[0]: Yes, yes, I know that you can configure LBs in a non-stateful / DSR mode 
(been there, done that, got the t-shirt), but many folk plug an LB in front of 
their DNS servers in some NAT / stageful manner and then get sad when it falls 
over…



 
 ;
 
 ---
 Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com
 
 Luck is the residue of opportunity and design.
 
  -- John Milton
 
 ___
 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
 

--
Consider orang-utans.
In all the worlds graced by their presence, it is suspected that they can talk 
but choose not to do so in case humans put them to work, possibly in the 
television industry. In fact they can talk. It's just that they talk in 
Orang-utan. Humans are only capable of listening in Bewilderment.
-- Terry Practhett


___
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] Capturing 8.8.8.8 Traffic

[Warren Kumari]

On Feb 25, 2013, at 12:42 PM, Lyle Giese l...@lcrcomputer.net wrote:

 On 2/25/2013 11:31 AM, Joe Provo wrote:
 On Mon, Feb 25, 2013 at 07:26:07PM +0200, Graham Beneke wrote:
 I discovered the other day that a large customer of $dayjob has decided
 that it is a good idea to outsource the LAN support for their head
 office and NOC to a mom-and-pop IT shop. While I question the wisdom in
 that, I was far more concerned by the fact that this mom-and-pop shop
 had configured Google Public DNS as the resolver for everything on their
 LAN.
 
 Now on my corner of the planet Google DNS is 190ms away. Never mind the
 mess we have with all the CDNs mapping their traffic to a different
 continent.
 
 So what are you thoughts on capturing these queries and answering them
 on local resolvers that are 10ms away?
 
 The folks at Google are certainly not going to encourage us to spoof
 responses from their servers but are there any other potential pitfalls
 with doing this to save the customers from themselves?
  I don't think *anyone* would encourage, reccomend or endorse hijacking
 someone else's resolver addresses. What ever happened to providing the
 service and educating the customer[s]?
 
 I would check to see what happens to domains that don't exist.  Esp asking 
 for the MX records for a domain that doesn't exist.
 
 I had heard stories that some public resolvers will resolve when they should 
 not.

Yup, good point -- some public resolvers do, but Google DNS (8.8.8.8) does 
*not*….

  For surfing, minor issue.  For a mail server, major issue.

Yup, and for various other services, also major issue…

ICANN SSAC has a number of documents saying similar…

W

 
 Lyle Giese
 LCR Computer Services, Inc.
 
 ___
 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
 

--
I once absend-mindedly ordered Three Mile Island dressing in a restaurant and, 
with great presence of mind, they brought Thousand Island Dressing and a bottle 
of chili sauce.
-- Terry Pratchett


___
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] Capturing 8.8.8.8 Traffic

[Warren Kumari]

On Feb 25, 2013, at 7:17 PM, Robert Edmonds edmo...@isc.org wrote:

 Noel Butler wrote:
 and putting tin foil hat on now :)  it would log those requests, and who
 knows what google does with that data, it sure as hell doesnt do it for
 the goodness of the planet, there is a commercial reason behind every
 decision and service they provide.

So, yes, there is a commercial reason -- Google makes basically all its money 
from folk using the Internet.
While things have been improving, a large number of ISPs were providing very 
poor recursive DNS services for their users -- DNS is seen simply as a cost and 
not as a revenue stream, and so they were often oversubscribed and / or not 
reliable (and / or would lie).

Poor DNS performance leads to a substantially degraded user experience 
(sometime have a look to see how many DNS resolutions something like the CNN 
main page requires) -- poor user performance leads to users using the Internet 
less, which leads to Google not making as much money.

Now I realize that lots of folk would prefer to believe that there is something 
more nefarious happening (and there is nothing really that I can say to change 
that) but I figured I should at least try explain why Google provides this...

 yes, who knows what google is doing with all that data.  they would
 never tell us that.
 
https://developers.google.com/speed/public-dns/privacy

Yup, thank you, Robert.

 
[...]
 
Google Public DNS stores two sets of logs: temporary and permanent.
The temporary logs store the full IP address of the machine you're
using. We have to do this so that we can spot potentially bad things
like DDoS attacks and so we can fix problems, such as particular
domains not showing up for specific users.
 
We delete these temporary logs within 24 to 48 hours.
 
In the permanent logs, we don't keep personally identifiable
information or IP information. We do keep some location information
(at the city/metro level) so that we can conduct debugging, analyze
abuse phenomena. After keeping this data for two weeks, we randomly
sample a small subset for permanent storage.
 
We don't correlate or combine information from our temporary or
permanent logs with any personal information that you have provided
Google for other services.
 
Finally, if you're interested in knowing what else we log when you
use Google Public DNS, here is the full list of items that are
included in our permanent logs:
 
* Request domain name, e.g. www.google.com
 
* Request type, e.g. A (which stands for IPv4 record),  (IPv6
record), NS, MX, TXT, etc.
 
* Transport protocol on which the request arrived, i.e. TCP or UDP
 
* Client's AS (autonomous system or ISP), e.g. AS15169
 
* User's geolocation information: i.e. geocode, region ID, city ID,
and metro code
 
* Response code sent, e.g. SUCCESS, SERVFAIL, NXDOMAIN, etc.
 
* Whether the request hit our frontend cache
 
* Whether the request hit a cache elsewhere in the system (but not in
the frontend)
 
* Absolute arrival time in seconds
 
* Total time taken to process the request end-to-end, in seconds
 
* Name of the Google machine that processed this request, e.g.
machine101
 
* Google target IP to which this request was addressed, e.g. one of
our anycast IP addresses (no relation to the user's IP)
 
 -- 
 Robert Edmonds
 edmo...@isc.org
 ___
 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
 

-- 
American Non-Sequitur Society; 
we don't make sense, but we do like pizza!


___
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] CloudShield advices against dDoS

[Warren Kumari]

On Feb 20, 2013, at 12:03 PM, Joe Abley jab...@hopcount.ca wrote:

 
 On 2013-02-20, at 12:46, Stephane Bortzmeyer bortzme...@nic.fr wrote:
 
 http://www.cloudshield.com/applications/dns-control-traffic-load.asp
 
 I think this particular information security professional with more than 16 
 years of experience is a bit confused. I tried hard to find something in 
 there I agreed with, but I failed.

I cannot imagine a computer, tablet, or smartphone that can generate more than 
10 qps

Giggles….

W
 
 
 Joe
 
 ___
 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
 

--
Have you got any previous convictions?

Well, I dunno... I suppose I used to believe very firmly that a penny saved is 
a penny earned--
-- Terry Pratchett



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

Re: [dns-operations] What's a suffix?

[Warren Kumari]

On Jan 21, 2013, at 6:45 AM, Jothan Frakes jot...@gmail.com wrote:

 Hi-
 
 Perhaps my suggestion was better for off-list, and I certainly don't know if 
 it would be the magic solution for .cw, but it certainly could not hurt them 
 to submit their entry to the PSL.  I do hope it contributes to the solution 
 for them.
 
 The PSL is something that the application development community uses to 
 enhance the IANA list for a variety of uses, typically for understanding what 
 might be valid on the rightmost side of addresses.  


Yup, the PSL is used by a number of browser manufacturers to scope cookies...

   Many app developers don't closely watch the IANA root list, and want to 
 know how to have a more elegant understanding and handling of the right hand 
 side of addresses that are parsed, going deeper than just the TLD itself.

Yes -- the IANA root list (unfortunately) simply doesn't contain the 
information needed to correctly determine where a cookie can be set. The PSL 
helps prevent a cookie being set at e.g: .co.uk.

W

 
 I don't have an opinion on if it is right or wrong, but it has been around 
 for some time, and a few years back I saw it was out of synch with the TLD 
 community and have put a lot of volunteer time into trying to correct that.  
 I am on temporary hiatus, but when not on exclusive projects, I volunteer 
 time and experience to the initiative as it needs tighter nexus with the DNS 
 community.  Many of you have perhaps seen me presenting it at ICANN meetings 
 within the CCNSO tech day or other forums to help elevate awareness in the 
 past few years.  
 
 The hope and purpose is to bridge the application development world so as to 
 increase better sophistication for developers about TLDs and reduce legacy 
 problems like simple TLD tests (ie 3 chars = invalid which broke forms or 
 other functionality for info, museum, aero, mobi, travel etc. as they 
 launched) .
 
 It is a central system managed by the community, kept up to date by 
 volunteers, and used by numerous software developers, programming languages, 
 browsers (cookies), search engines, security software, and many other places.
 
 Hopefully it helps .cw as they launch, which was my initial purpose in 
 response.
 
 Definitely worth folks on this list being aware of it.  Being able to 
 positively impact how your zone operates within the application development 
 community is a valuable resource.
 
 -J
 
 Jothan Frakes
 
 
 
 On Mon, Jan 21, 2013 at 1:00 AM, Stephane Bortzmeyer bortzme...@nic.fr 
 wrote:
 On Mon, Jan 21, 2013 at 09:25:03AM +0100,
  Stephane Bortzmeyer bortzme...@nic.fr wrote
  a message of 21 lines which said:
 
  A suffix is any string ending a domain name.
 
 A reader even more nazi than I am suggested a definition closer to the
 DNS semantics:
 
 A suffix is any sequence of labels ending a domain name.
 
 
 ___
 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 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

--
The duke had a mind that ticked like a clock and, like a clock, it regularly 
went cuckoo.

-- (Terry Pratchett, Wyrd Sisters)


___
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] 10% was Re: .mm ....

[Warren Kumari]

On Jan 21, 2013, at 5:26 AM, Jaroslav Benkovský jaroslav.benkov...@nic.cz 
wrote:

 On 01/19/2013 09:28 PM, Matthäus Wander wrote:
 I think it's more like I'll tolerate an expired signature for 10% of
 the original validity period and use that extra time to let other people
 notice and fix it.
 Assuming that 1) the majority of validators do *not* tolerate expired
 signatures and 2) most DNSSEC failures are fixed within that 10%, it is
 a way to trade off reliability vs. security.
 
 That's rather reminiscent of parents who don't get their children
 vaccinated for fear of side-effects and instead rely on *other* children
 being vaccinated.
 
 Being tolerant to garbled input is what caused the sorry mess of HTML,
 with its quirk parsing modes and incompatibilities.

Hmmm…

So, the issue is folk not resigning before the expiration.

Some resolvers are loose -- they stretch the expirations.
Other, more strict implementations mark the domain as bad when it expires -- 
this causes fallout / press / messages on dns-ops, and the domain admin notices 
and resigns.

This makes the loose implementations look better -- folk running the loose 
implementations avoided having thier customers get grumpy, saved the cost of 
support calls, etc.

So, basically the loose implementations are relying on the strict 
implementations to signal the domain admin (out of band) to resign.
This negatively affects the reputation of the strict implementations and, 
eventually, we may run into an issue where the loose implementations all 
increase the slop factor to look better than their competitors…

So, basically what is needed is a strong, out of band signal to the operators 
to resign… It seems that the only reliable way to do this is for the domain to 
go dark for some (non-insignificant) portion of users -- this triggers Where 
the hell did my traffic go? questions from the web server operators, news 
articles and eventually the pointy-haired boss types waking down the stairs and 
shouting….

So, obviously what is needed is a way to trigger these  sorts of responses, but 
without creating as much of an incentive for loose implementations  and slop 
factors…
So, here is my proposal:

1: Everyone does strict implementations.

2: When the signature expires everyone does the following:
A: You calculate by how much the zone has expired, normalize it, then multiply 
by 255 and call this EXPIRED-AMNT.
B: You take the primary IP of your recursive server, hash it, take the last 
octet of the hash and call it REF-HASH.
C: You hash the label of the zone apex, take the last octet and call it  
ZA-HASH.

Now, if REF-HASH - ZA-HASH  EXPIRED-AMNT you can still answer the query. This 
means that initially only 1/255 resolvers will view the zone as bogus, but as 
time goes by (up to double the validity interval) more and more resolvers will 
mark it bad. This allows for increasingly strong signals to the operator, but 
doesn't favor any one implementation….

You're welcome…
W

(Mumbles something about job security, then runs off, giggling madly…)





 
 It's not cool to be one of the few resolvers suffering from DNSSEC
 configuration errors that other people caused, while all the
 non-validating resolvers seem to work fine. The security benefit is
 hardly noticed by users outside of the DNS community as long as
 applications are not showing green DNSSEC icons or other gizmos.
 
 I used to work for the first major ISP here that switched DNSSEC
 validation on, so I can only commiserate with you :).
 
 
 Jarda Benkovsky
 
 ___
 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
 

-- 
Do not meddle in the affairs of wizards, for they are subtle and quick to 
anger.  
-- J.R.R. Tolkien


___
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] Monday rant againt the uses of the Public Suffix List

[Warren Kumari]

On Jan 21, 2013, at 5:32 PM, Andrew Sullivan a...@anvilwalrusden.com wrote:

 On Mon, Jan 21, 2013 at 03:29:28PM -0500, Warren Kumari wrote:
 Please sir, if I run www.images.example.co.uk, can I set a cookie at 
 images.example.co.uk? How about example.co.uk? Fine… Now .co.uk? Hmm…
 
 There is no DNS query that will (or should) tell me that...
 
 I strongly disagree, and have written a draft that would provide,
 among other things, what I believe to be such a mechanism

Oh…. Huh. Well, there's a thing…

(Obviously) I haven't had a chance to actually read this properly yet, but from 
a quick skim it looks like a grand idea…

I guess I'll modify my earlier to There is no DNS query that will (or should) 
currently tell me that, but maybe in the not too distant future there will be… 
Go read: blah

:-)

W



 (though some
 people on the W3C websec list seem to disagree, because they want
 assurances that are not currently provided by the public suffix list).
 The draft has heard some support from various reviewers, but I'm still
 not sure where next to go with it, so I haven't been flogging it.
 Review is welcome, however.
 
 http://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02
 
 Best regards,
 
 A
 
 -- 
 Andrew Sullivan
 a...@anvilwalrusden.com
 ___
 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

--
Life is a concentration camp.  You're stuck here and there's no way out and you 
can only rage impotently against your persecutors.
-- Woody Allen




___
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] Enom's name server broken?

[Warren Kumari]

On Jan 15, 2013, at 11:45 AM, Paul Vixie p...@redbarn.org wrote:

 
 
 Stephane Bortzmeyer wrote:
 ...
 dns1.name-services.com is not supposed to be recursive (it does not
 set the RA bit) but it is:
 
 % dig @dns1.name-services.com 
 www.dns-oarc.net
 
 
 ...
 ;; ANSWER SECTION:
 
 www.dns-oarc.net
 .3600IN  A   69.64.147.243
 
 ;; Query time: 158 msec
 
 
 
 since the ttl isn't ticking down on repeated queries, i think it's not 
 recursive, it's got a wildcard of some kind. try this:
 
 dig @dns1.name-services.com lihdsiuhswluswf.com soa

Every time I see an email like this I'm tempted to run off and register e.g 
lihdsiuhswluswf.com, just to be difficult. I manage to resist, but...

Am I just a bastard or do others suffer from this compulsion as well?

W

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

-- 
Militant Agnostic -- I don't know and you don't either...



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

Re: [dns-operations] DNS and Email

[Warren Kumari]

On Jan 10, 2013, at 11:57 PM, Brett Watson br...@the-watsons.org wrote:

 
 On Jan 10, 2013, at 9:25 PM, Noel Butler wrote:
 
 On Fri, 2013-01-11 at 10:43 +0800, Feng He wrote:
 
 And I have a question that, what is the good username for showing in the 
 whois info for domain contact email?
 
 
 dnsad...@domain.com
 hostmas...@domain.com
 
 Either of these, I think the latter is probably more common of the two.
 
 Or follow this:
 
 http://www.ietf.org/rfc/rfc2142.txt

Or the advice (full disclosure: co-author ) in SSAC SAC44 ( 
http://www.icann.org/en/committees/security/sac044.pdf ) and SAC 40 ( 
http://www.icann.org/en/groups/ssac/documents/sac-040-en.pdf ) which recommend 
(amongst other things):

Registrants should consider the benefits of using mail domains for contact 
emails that are managed separately from the domains that can be accessed from 
an individual domain registration account so that an attacker cannot interfere 
with a registrar's ability to contact the registrant. Registrants should also 
consider other measures to mitigate this threat. For example, a registrant 
could distribute its domain name registrations across multiple domain name 
registration accounts (and possibly across different registrars). Example 
Networks, Inc. could manage example.com using account “examplenetworks1” and 
example.net using account “examplenetworks2”. Email addresses for points of 
contact for example.com could then be assigned from a mail domain operated 
under example.net. Similarly, email addresses for points of contact for 
example.net could be assigned from a mail domain operated under example.com.


It is, er, [ sad | hilarious ] when your domain malfunctions and no-one can 
contact you to let you know that this has happened because the contact is 
within the busticated domain… 

W


 ___
 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

-- 
American Non-Sequitur Society; 
we don't make sense, but we do like pizza!


___
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] note for the peanut gallery Re: underline in TXT's host

[Warren Kumari]

On Dec 17, 2012, at 11:55 AM, Mike Hoskins (michoski) micho...@cisco.com 
wrote:

 -Original Message-
 
 From: Feng He fen...@nsbeta.info
 Date: Monday, December 17, 2012 3:31 AM
 To: dns-operations@lists.dns-oarc.net dns-operations@lists.dns-oarc.net
 Subject: Re: [dns-operations] note for the peanut gallery Re: underline in
 TXT's host
 
 于 2012-12-15 2:37, Fred Morris 写道:
 So therefore let me state that I suggest that the unwary reader SHOULD
 NOT
 paste this into a shell to find out. I'll spoil the fun and tell you
 that
 it would delete everything in whatever directory you were in, and all of
 the directories below it.
 
 He is kind enough to not saying `rm -rf /`  :)
 
 It's been a long time since I was bored enough to try something like this
 for fun, but from what I remember on an old Solaris box / might be
 kinder -- if often fails quickly due to permissions, /dev being processed
 early, etc.
 
 If nothing else, this thread was a great advertisement for backups.

My favorite is noticing that emacs, mutt, whatever is not working right. So I 
do 'ls -al' and notice that .emacs.d, .mutt, whatever is owned by root…
Now, obviously, chown'ing each directory is too hard / annoying, so I run:
sudo chown -R $USER .*

Yup, .* helpfully expands to '.' and '..' before '.emacs.d', and so chown walks 
up and then back down the fielsystem, chowning *everything* to $USER….

It usually[0] runs for 5 - 10 seconds before I wonder why it's all taking so 
long and realize the issue….

This biggest problem with this is that I always think that I can recover from 
this by copying permissions from another machine by doing 'ls -alR /', and then 
massaging the output with sed and awk and passing that back to chown….
This never results in a reasonable end state…

W

[0]: Yes, I have in fact done this more than once :-P
[1]: Whenever faced with a problem, some people say `Lets use AWK.'
 Now, they have two problems. -- D. Tilbrook


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

--
Real children don't go hoppity-skip unless they are on drugs.

-- Susan, the ultimate sensible governess (Terry Pratchett, Hogfather)




___
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] Massive DNS poisoning attacks in Brazil

[Warren Kumari]

On Oct 2, 2012, at 7:59 AM, Rubens Kuhl rube...@nic.br wrote:

 
 Much better and very detailed analysis (by the same author!) So, it
 was not DNS poisoning at all but a change in the DNS settings of the
 router, after the box was cracked. (DNSchanger-style)
 
 http://www.securelist.com/en/blog/208193852/The_tale_of_one_thousand_and_one_DSL_modems
 __
 
 
 DNSSEC alone wouldn't have provided much relief on this, but DNSSEC+DANE+HSTS 
 could. Most of it due to HSTS, but we need to cover the rogue CA 
 attack-vector.

DNSSEC on the *host / stub* would have though.

W


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

[Warren Kumari]

On Sep 21, 2012, at 4:12 AM, Phil Regnauld regna...@nsrc.org wrote:

 Paul Vixie (paul) writes:
 gentlefolk, i call your attention to this:
 
 http://www.icann.org/en/news/public-comment/sac053-dotless-domains-24aug12-en.htm
 
 i've already explained as best i can:
 
 http://www.circleid.com/posts/20110620_domain_names_without_dots/
 
 but the icann call for comments remains open, and i urge you to let your
 voices be heard there.
 
   Surprised no one's brought up http://dk/ as an already existing scenario
   that doesn't work (try it in various browsers).


I'd like to point at a comment submitted by Dmitry Kohmanyuk, one of the  
admins for the .UA ccTLD, and his dot less experience….

http://forum.icann.org/lists/sac053-dotless-domains/msg2.html

W

 
   Phil
   
 ___
 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 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] Pinging the root name servers to check my connectivity?

[Warren Kumari]

On Sep 11, 2012, at 9:27 AM, wbr...@e1b.org wrote:

 Jeroen Massar jer...@unfix.org wrote on 09/11/2012 09:06:55 AM:
 
 
 Or should be building into a product... 
 
 Given the slight odds of them getting it correct, I'd agree with that.

Obligatory reference to what happens when CPE vendors decide to use a public 
resource instead of running their own / being responsible:
http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse


W
 
 
 
 
 Confidentiality Notice: 
 This electronic message and any attachments may contain confidential or 
 privileged information, and is intended only for the individual or entity 
 identified above as the addressee. If you are not the addressee (or the 
 employee or agent responsible to deliver it to the addressee), or if this 
 message has been addressed to you in error, you are hereby notified that 
 you may not copy, forward, disclose or use any part of this message or any 
 attachments. Please notify the sender immediately by return e-mail or 
 telephone and delete this message from your system.
 ___
 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
 

--
I once absend-mindedly ordered Three Mile Island dressing in a restaurant and, 
with great presence of mind, they brought Thousand Island Dressing and a bottle 
of chili sauce.
-- Terry Pratchett


___
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] thoughts on DNSSEC

[Warren Kumari]

On Jul 25, 2012, at 3:36 AM, Francis Dupont wrote:

 In your previous mail you wrote:
 
 What about always using both types of DS record?  Why does everyone
 publish both SHA-1 and SHA-256 digests?  RFC 4509 is more than 6
 years old.
 
 = in fact perhaps it is the right time to jump to SHA-256 only?

Somewhat related: http://tools.ietf.org/html/draft-crocker-dnssec-algo-signal-07

Wouldn't it be nice to know who supports what, so these questions are easier to 
answer in the future?!

W


 
 Regards
 
 francis.dup...@fdupont.fr
 ___
 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
 

-- 
American Non-Sequitur Society; 
we don't make sense, but we do like pizza!


___
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] No to port blocking! (Was: Why would an MTA issue an ANY query instead of an MX query?

[Warren Kumari]

On Jun 12, 2012, at 4:14 AM, Stephane Bortzmeyer wrote:

 On Tue, Jun 12, 2012 at 03:32:56AM +,
 Vernon Schryver v...@rhyolite.com wrote 
 a message of 76 lines which said:
 
 Joe and Joan should be using their ISP's validating, load balancing,
 well (or at least somewhat) maintained DNS servers, just as they
 should be using their ISP's SMTP systems.
 
 A strong NO here.

+lots.

 Politically, it would be a big nail in Net
 Neutrality's coffin. Also, many ISP have lying resolvers and customers
 should NOT use them. From a security perspective, it would be
 catastrophic since the last mile is not secured, so the only safe way
 to run DNSSEC is to validate locally (which requires access to port 53
 if the ISP resolver is lying).
 

And it seems that the huge majority of lying is being performed at the ISP 
resolvers.

See the numerous papers on NXDOMAIN rewriting, Paxfire / Xerocole / 
Barefruit, etc, one of the better of which is 
 Christian,  Nicholas and Vern's Redirecting DNS for Ads and Profit ( 
http://www.icir.org/christian/publications/2011-foci-dns.pdf )

There are also a huge number of really poorly run (and slow!) ISP recursive 
resolvers.

Having the ability to run your own validating recursive is critical…

W


 I leave these proposals to MAAWG and the Chinese government.
 
 ___
 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
 

--
Go on, prove me wrong. Destroy the fabric of the universe. See if I care.  -- 
Terry Prachett 


___
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