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

[Edward Lewis]

From: dns-operations  on behalf of Joe 
Abley 
Date: Saturday, April 27, 2024 at 02:50
To: Warren Kumari 
Cc: "dns-operations@lists.dns-oarc.net Operations" 

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

>It's a big Internet. There is a lot of surprising stuff in it. I find it's 
>usually a mistake to imagine that anybody knows
>how all of it works just because they know how some of it works. Thinking the 
>opposite and turning over rocks
>can reveal some interesting things.

(Apparently, this became a run-on email as I thought about Joe’s message.)

That last point is why I’m asking.

I’m facing a dilemma.

On the one hand, accommodating and enabling a diverse set of possible 
operational models is a noble goal.  Avoiding “one way of addressing something” 
leads to a more resilient and vibrant system.  Resisting a natural progression 
of “economies of scale” to be uniform in manner potentially pays off in the 
long run if the uniform approach caves in under its own weight.  Coincidently, 
I am reading through an article on “rewilding the Internet” on this, the URL 
appeared in RIPE mailing list, reinforcing that notion.

On the other hand, securing an operational platform is greatly challenged when 
the requirements are wide open, when the set of permissible actions is large.  
Deciding whether a state of the system is “safe” or “at risk” or “in abuse” is 
increasingly difficult as the number of states grows.  This encourages 
monoculture, which is seen as root cause of many historic collapses, but is 
driven by some operational experiences I’ve come across.

I’ve been reeling from a comment made to me a few months ago by a long-time 
operator of a ccTLD.  “Complexity causes consolidation.” This was said in the 
context that the more complex a protocol is, the fewer experts there will be 
who can deploy and operate it, which results in consolidation.  As an example, 
the world of email, it’s gotten so hard to run that relying on a commercial 
email provider is recommended.

Another “bon mot” I heard from a management figure in the past is “I don’t want 
any more Swiss army knives” while addressing a development team.  The issue was 
that the team had been spending time on general solutions to what they thought 
were problems while the operational staff needed specific solutions to tasks at 
hand, resulting in wasted efforts and mishaps at the operational terminals.  My 
takeaway from that is that, to support operations, protocols, and the tools to 
deploy them, need to get simpler, more specific.

This is a bit of the division of macroeconomics vs. microeconomics at play.  
Sometimes what’s best for a society is not the same thing as what’s best for a 
specific player.  “Grazing of the commons” is probably an embodiment of this 
friction.

Along a different dimension is the distinction between vulnerabilities 
discovered “via packets” - that is an active attack detected by looking at 
server logs and activity - versus a vulnerability discovered by a study of a 
system’s design.  The former represents a current event, one needing attention 
as harm is being done.  The latter represents a threat that hasn’t 
materialized.  It’s clear that the former needs action, there would be an 
immediate payoff, the latter may or may not deserve action as it is not known 
whether a malicious actor has been aware of the possibility or has been aware 
and decided there was no reason to exploit it.

This is different, it’s not “Swiss army knives” and “consolidation” but knowing 
where to work.  It’s certainly more important to address issues that will have 
a tangible benefit versus issues that may be purely theoretical.  Sometimes you 
need to let a situation become a “festering wound” before treating it if only 
because at that point it will be clearer what the treatment ought to be.  (I 
learned that very early in my career.)

I realize that conceptually trust anchors can play a role and in cases just as 
Joe listed in his email.  The question is whether these situations were playing 
out anywhere or perceived to be a future threat.  My hypothesis is that if 
trust anchors only matter for the root of a DNS namespace (“a namespace” as a 
nod to networks that are separate from the global public Internet) then how 
they are defined, implemented, managed, and deployed could be much simpler than 
the general-purpose solutions we now have.  So, for now, I’m looking for any 
case where trust anchors are in use (outside of the root zone).

…with a parting shot at that old DLV service…while it was in place, it got very 
little love, less that it deserved in my book…
(https://kb.isc.org/docs/iscs-dnssec-look-aside-validation-registry)
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] A request for "data"

[Edward Lewis]

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?

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

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

Re: [dns-operations] [Ext] Re: Evaluation of NSEC3-encloser attack

[Edward Lewis]

On 3/27/24, 17:34, "dns-operations on behalf of Jim Reid" 
 wrote:

>IMO, there’s no added value in using NSEC3.

NSEC3 has opt-out, which is important for large, delegation-centric zones.  
Noting, I'm no fan of NSEC3, but it does have that going for it.


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

Re: [dns-operations] Upcoming Registry Service Provider Evaluation Program

[Edward Lewis]

I have some data on this.  Trying to convey this in email is hard, so here’s a 
link to slides from Nov 2022 explaining the data:

https://www.icann.org/en/system/files/files/presentation-consolidation-amongst-top-level-domains-15nov22-en.pdf

Below is a chart (pulled from debug output) for 18 Feb 2024 (a few days ago), 
if you want more current observations.

This supports the notion that most gTLDs are hosted on some large platforms, 
ccTLDs generally are separate.  There are some crossovers, of course.  Revmap 
refers to the RIR managed top-level IPv4 and IPv6 zones.  I think there is only 
one platform serving all three, thanks to Japan’s NIR function.

Note - you may see separate organizations in one line.  This is an artefact of 
how the groupings are made.  While zones are transferring, it might make it 
look like two organizations have merged, which is not the case.  It’s more a 
matter of transitioning the DNS zone management (SOA resource record) and 
updating the root zone database.  Once transfers finalize, this data will 
separate the two organizations again.

DNS in_all:461 in_gtld:448 in_cctld: 13 in_revmap:  0 
dns='hostmaster.donuts.email.'
DNS in_all:268 in_gtld:263 in_cctld:  5 in_revmap:  0 
dns='admin.tldns.godaddy./dnsmaster.knipp.de./info.verisign-grs.com./nstld.verisign-grs.com.'
DNS in_all:135 in_gtld:128 in_cctld:  7 in_revmap:  0 
dns='hostmaster.centralnic.net./ops.uniregistry.net./regops.uniregistry.link.'
DNS in_all:105 in_gtld:  0 in_cctld:  0 in_revmap:105 dns='dns-ops.arin.net.'
DNS in_all: 74 in_gtld: 72 in_cctld:  2 in_revmap:  0 
dns='hostmaster.nic.uk./hostmaster.nominet.org.uk.'
DNS in_all: 65 in_gtld:  0 in_cctld:  0 in_revmap: 65 dns='dns.ripe.net.'
DNS in_all: 62 in_gtld:  0 in_cctld:  0 in_revmap: 62 
dns='read-txt-record-of-zone-first-dns-admin.apnic.net.'
DNS in_all: 47 in_gtld: 47 in_cctld:  0 in_revmap:  0 dns='noc.gmoregistry.net.'
DNS in_all: 46 in_gtld: 46 in_cctld:  0 in_revmap:  0 
dns='cloud-dns-hostmaster.google.com.'
DNS in_all: 23 in_gtld: 23 in_cctld:  0 in_revmap:  0 dns='td_dns_gtld.knet.cn.'
DNS in_all: 21 in_gtld: 13 in_cctld:  8 in_revmap:  0 dns='dnsmaster.afnic.fr.'
DNS in_all: 20 in_gtld: 20 in_cctld:  0 in_revmap:  0 
dns='dnsmaster.corenic.org.'
DNS in_all: 17 in_gtld:  1 in_cctld:  0 in_revmap: 16 dns='noc.dns.icann.org.'
DNS in_all: 16 in_gtld:  0 in_cctld: 16 in_revmap:  0 dns='dns.registry.in.'
DNS in_all: 13 in_gtld:  0 in_cctld:  0 in_revmap: 13 
dns='hostmaster.lacnic.net.'
DNS in_all: 11 in_gtld:  6 in_cctld:  5 in_revmap:  0 
dns='hostmaster.coccaregistry.org.'
DNS in_all: 10 in_gtld: 10 in_cctld:  0 in_revmap:  0 dns='ops.teleinfo.cn.'
DNS in_all:  9 in_gtld:  0 in_cctld:  0 in_revmap:  9 
dns='dns-admin.afrinic.net.'
DNS in_all:  7 in_gtld:  7 in_cctld:  0 in_revmap:  0 
dns='dnsmaster.irondns.net.'
DNS in_all:  7 in_gtld:  6 in_cctld:  1 in_revmap:  0 
dns='hostmaster.registro.br.'
DNS in_all:  7 in_gtld:  4 in_cctld:  3 in_revmap:  0 
dns='root.cnnic.cn./sysmgr.cnnic.cn.'
DNS in_all:  6 in_gtld:  4 in_cctld:  2 in_revmap:  0 dns='admin-dns.cira.ca.'
DNS in_all:  5 in_gtld:  5 in_cctld:  0 in_revmap:  0 dns='gtldsupport.aeda.ae.'
DNS in_all:  5 in_gtld:  3 in_cctld:  1 in_revmap:  1 
dns='root.dns.jp./root.nic.jprs./root.nic.ntt./root.nic.sakura.'
DNS in_all:  5 in_gtld:  1 in_cctld:  4 in_revmap:  0 
dns='hostmaster.nic.kn./snw.twnic.net.tw.'
DNS in_all:  5 in_gtld:  2 in_cctld:  3 in_revmap:  0 dns='hostmaster.ripn.net.'
DNS in_all:  4 in_gtld:  4 in_cctld:  0 in_revmap:  0 
dns='support.registry.net.za.'
DNS in_all:  4 in_gtld:  4 in_cctld:  0 in_revmap:  0 
dns='hostmaster.tld-box.at.'
DNS in_all:  4 in_gtld:  4 in_cctld:  0 in_revmap:  0 
dns='support.ryce-rsp.com.'
… for 3,2,1…

From: Rubens Kuhl 
Date: Thursday, February 22, 2024 at 12:01
To: 
Subject: Re: [dns-operations] Upcoming Registry Service Provider Evaluation 
Program



I did some of the technical evaluations in the previous round, and we
saw that the vast majority of applications used about five back end
providers. Prequalifying those providers would have made the whole
process much faster.

R's,
John

[cid:image001.png@01DA658F.3B7D5850]

new gTLD Statistics by Backends
ntldstats.com


 lists 37 back-ends for gTLDs. I don’t think there is a readily available list 
for c


Rubens


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

Re: [dns-operations] [Ext] Re: .RU zone failed ZSK rotation

[Edward Lewis]

On 2/8/24, 10:40, "dns-operations on behalf of Viktor Dukhovni" 
 wrote:

The chances of a remotely possibly event happening is 100% once it happens. __

So long as a hash is shorter than the data it covers, there's a chance there 
will be a collision.  Just a general statement.

>There is no issue with DS record confusion.

I think you are underestimating how an operational step may go wrong.  In a 
previous gig, the crew that had terminal access to the DNS machinery were on a 
different floor than the crew that was in charge with contacting IANA.  There 
was a time when all of the first crew members assumed that one of the others in 
their crew told someone in the other crew to change the DS record.  Oops.

What I can see happening is ... having an old KSK tagged 11211 in the DS. The 
new KSK is also tagged 11211 and is added to the DS set.  No issue there.  A 
few weeks later, when the old key is to be retired, someone says "pull 11211" 
because that's easier than reading out the hash value.

>  And even if two keys  produced the same DS record, that'd be fine too, just 
> publish one DS
>record in support of both!  The only theoretical risk is erroneously
>publishing two identical RRs in the DS RRset, which is not allowed,
>and validators may balk...  In practice, this won't happen.

The protocol doesn't care.  It’s those who are doing the key management may mix 
them up.  The convenience of 5 digit tags engenders laziness when it comes to 
automation - you'd have to script up something that checks hashes or fill keys, 
but you might not script up something that is only 5 digits long.

I've seen that in action...at a root cause analysis meeting...when the issue 
was caused by the tech typing something in hex as opposed to using a fancy GUI 
because the budget didn't include the GUI update this time around.


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

[dns-operations] A follow upRe: [Ext] Re: .RU zone failed ZSK rotation

[Edward Lewis]

In my data, I don't see the colliding key tags involved, but historically, RU 
had two other keys share a key tag value - but not at the same time.  Here are 
parts of the data I have - the last shown field is the start of the public 
key's bits (which show these are different keys).

"RU.","DNSKEY","2019-11-20","2020-02-21" 
,"ZONE","DNSSEC","RSASHA256","1024","52263","LARGE","AwEAAc1yxFp79bw...
"RU.","DNSKEY","2024-01-26","2024-02-07","ZONE","DNSSEC","RSASHA256","1024","52263","LARGE","AwEAAbjj3GP0TUw...

Key tags do collide, but rarely (so far) at the same time.  I haven't 
quantified this, I just happened to look to see if my data included the two 
keys that caused the problem but only ran across this example.

On 2/8/24, 07:24, "Edward Lewis"  wrote:

Very interesting.

There have been two cases since 2011 of a TLD having two published DNSKEY 
resource records sharing the same key_tag.

The first in 2018/2019 involved a TLD having a KSK and ZSK share.  I didn't 
notice while it was happening, but found it when testing some code I have to 
visualize (make charts of) key lifetimes.  As the testing was during the 
pandemic, I never had the chance to track down the TLD operators to get the 
story.  Noting that "no one noticed" it was apparent in my data that they 
realized it and addressed the situation (because they retired one of the keys 
earlier than their pattern).

The second time was in January 2024 (last month), when another TLD had two 
ZSK's with the same DNS Security Algorithm but different lengths (RSA).  I saw 
this while it was happening and slipped a note to a potential contact, didn't 
get feedback, and the conflict went away ahead of a patterned change.  I was 
told that the TLD is in transition, which may or may not be a factor (in the 
key_tag collision or "fix").  Again, in this situation, I'll note that "no one 
noticed" except a researcher looking for this (me) and the staff there.

Colliding key tags are not an issue for the validation code, at least they 
shouldn't be.  Protocol developers have known that key tags, being 16-bits, 
cannot be assumed to be unique, they are just hints.  Back in the day, 
colliding key tags were discussed at 950 Charter in Redwood City (the old BIND 
building) and "fixed" by the writer of dnssec-keygen (at the time the only 
DNSKEY resource record generating code available) telling us he's add a clause 
in the code - if a new key shared a key tag with another key "in the directory 
of keys", the new key would be deleted, and key generation started again.  This 
rule was never documented so hearing colliding keys now that we have more code 
bases could (should?) be expected.

The problem with colliding key tags is in key management.  I said this 
yesterday in a side conversation, not yet knowing of the .RU situation.  I 
imagined someone saying "pull key 11211" and the at-the-keyboard tech pulling 
the wrong one.  Looks like this happened (although probably automated in code).

The upshot - when DNSSEC code pulls keys based on key tag, it should expect 
to get a set of keys, not a single key.

Between non-unique key tags and the possibility of hash collisions, it's 
possible two DS resource records could share either a key  tag or a hash 
representing different keys.  From this, I wish we hadn't defined the key tag 
field - and maybe stuck with the entire key in the DS resource record.  Over 
the long term, ... I see things differently.

On 2/8/24, 04:02, "dns-operations on behalf of Stephane Bortzmeyer" 
 wrote:

On Wed, Jan 31, 2024 at 04:37:02PM +0200,
 Phil Kulin  wrote 
 a message of 56 lines which said:

> Done. New serial number 4058860. New active ZSK
> https://dnsviz.net/d/ru/ZbpWZg/dnssec/

There is now a detailed technical post-mortem. These official
explanations fit the facts that we observed. Nice bug.


https://www.rbc.ru/technology_and_media/07/02/2024/65c38fea9a794752176bd3a0
___
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] [Ext] Re: .RU zone failed ZSK rotation

[Edward Lewis]

Very interesting.

There have been two cases since 2011 of a TLD having two published DNSKEY 
resource records sharing the same key_tag.

The first in 2018/2019 involved a TLD having a KSK and ZSK share.  I didn't 
notice while it was happening, but found it when testing some code I have to 
visualize (make charts of) key lifetimes.  As the testing was during the 
pandemic, I never had the chance to track down the TLD operators to get the 
story.  Noting that "no one noticed" it was apparent in my data that they 
realized it and addressed the situation (because they retired one of the keys 
earlier than their pattern).

The second time was in January 2024 (last month), when another TLD had two 
ZSK's with the same DNS Security Algorithm but different lengths (RSA).  I saw 
this while it was happening and slipped a note to a potential contact, didn't 
get feedback, and the conflict went away ahead of a patterned change.  I was 
told that the TLD is in transition, which may or may not be a factor (in the 
key_tag collision or "fix").  Again, in this situation, I'll note that "no one 
noticed" except a researcher looking for this (me) and the staff there.

Colliding key tags are not an issue for the validation code, at least they 
shouldn't be.  Protocol developers have known that key tags, being 16-bits, 
cannot be assumed to be unique, they are just hints.  Back in the day, 
colliding key tags were discussed at 950 Charter in Redwood City (the old BIND 
building) and "fixed" by the writer of dnssec-keygen (at the time the only 
DNSKEY resource record generating code available) telling us he's add a clause 
in the code - if a new key shared a key tag with another key "in the directory 
of keys", the new key would be deleted, and key generation started again.  This 
rule was never documented so hearing colliding keys now that we have more code 
bases could (should?) be expected.

The problem with colliding key tags is in key management.  I said this 
yesterday in a side conversation, not yet knowing of the .RU situation.  I 
imagined someone saying "pull key 11211" and the at-the-keyboard tech pulling 
the wrong one.  Looks like this happened (although probably automated in code).

The upshot - when DNSSEC code pulls keys based on key tag, it should expect to 
get a set of keys, not a single key.

Between non-unique key tags and the possibility of hash collisions, it's 
possible two DS resource records could share either a key  tag or a hash 
representing different keys.  From this, I wish we hadn't defined the key tag 
field - and maybe stuck with the entire key in the DS resource record.  Over 
the long term, ... I see things differently.

On 2/8/24, 04:02, "dns-operations on behalf of Stephane Bortzmeyer" 
 wrote:

On Wed, Jan 31, 2024 at 04:37:02PM +0200,
 Phil Kulin  wrote 
 a message of 56 lines which said:

> Done. New serial number 4058860. New active ZSK
> https://dnsviz.net/d/ru/ZbpWZg/dnssec/

There is now a detailed technical post-mortem. These official
explanations fit the facts that we observed. Nice bug.

https://www.rbc.ru/technology_and_media/07/02/2024/65c38fea9a794752176bd3a0
___
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] [Ext] Re: Cloudflare TYPE65283

[Edward Lewis]

From: "p...@redbarn.org" 
Date: Tuesday, April 11, 2023 at 11:11 AM
To: "dns-operati...@dns-oarc.net" , Edward Lewis 

Subject: Re: [dns-operations] [Ext] Re: Cloudflare TYPE65283

>Well, we are overdue for starting over on dnssec, which we used to do every 
>two years or so. But does the next generation have the will to do so?

Good point – and something that I keep in mind all the time…

At some point the operational burden (pain) might justify some re-engineering.

The important word there is “might”.



I make this statement upon hearing more and more discussions about how to dance 
around the DNSSEC definition, with the background that DNSSEC was designed in 
an era prior to the current DNS operational environment.  It’s simple to say 
that operational assumptions made about the DNS were incorrect in the early 
days of DNSSEC, more accurately, the field of operations as we know it today 
hadn’t begun.

One of my smoldering interests is “why aren’t new technologies adopted?”  It’s 
been 25 years since the first meeting to motivate DNSSEC adoption (April 1, 
1998, at a lunch during IETF 41, involving DARPA, ISC, and TISlabs).  I’ve seen 
the approaches of “more free tools”, “more education of operators”, “build a 
business case” all fail to achieve their mark.  My concern now, especially 
after hearing Shumon Huque’s DNS-OARC 40 presentation, along with some 1:1’s 
with operators in recent years, that the obstacles to deployment lie in the 
nature of how DNSSEC came to be.

I think there’s an overall desire to see DNSSEC succeed (omitting what 
‘success’ is for the moment) but there remain technical impediments in the way, 
some only identified as the field of DNS operations evolves.  There are things 
that can be fixed, but there needs to be a will to take on the ‘capital 
investment’ to do the work.  We do know more now that we did a quarter of a 
century ago.

And, for what it matters, I have some specific ideas I hope to have time to 
document and propose, this isn’t just a purely philosophical rant.  Well, it 
could be just a rant, if there’s no will to change.


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

Re: [dns-operations] [Ext] Re: Cloudflare TYPE65283

[Edward Lewis]

On 3/27/23, 9:08 PM, "dns-operations on behalf of Viktor Dukhovni" 
 wrote:
>Perhaps, but until the mythical post-quantum DNSSEC is needed, online
>signers will use ECDSA, for which denial of existence is already
>sufficiently compact, even with 4 RRSIGs (SOA + 3 NSEC3).

Idle muttering (note, idle muttering) - if you are doing on-line signing, why 
stick with NSEC or NSEC3 for denial?  They were designed in an era when host 
security was so poor that having private key material on an internet-connected 
host was considered a very bad idea.

NSEC and NSEC3 work on the principle that "I don't know what the query asks in 
advance but I need to precompute something(*) to sign (where the private key 
is).  The approach is to reveal what I do have and let the requestor figure out 
that what they asked for isn't here."  That entire premise is blown away by 
on-line signing, calling into question all the energy we put into the size of 
the multi-NSEC(3) responses for negative answers and all the energy we put into 
mitigating zone walking.

(*) - prior to "Negative Caching of DNS Queries (DNS NCACHE)" [RFC 2308], a 
response with a return code of "Name Error" (that RFC defined the term 
NXDOMAIN) and 0 answer records, 0 authority records, and 0 additional records, 
was a legal way to indicate the queried name does not exist.  I.e., there was 
nothing (0 bytes) that a digital signature could cover.  The NSEC record (and 
then the NSE3) were created partly to have something to sign.

Sure, the cost of replacing NSEC and NSEC3 would be another resource record 
type code roll (such as 5->8, RSA-SHA1 vs RSA-SHA1-NSEC3).  But a new 
on-the-fly denial of existence might prove to be worth it in operations.


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

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

[Edward Lewis]

I think there is still something broken.

Using edu.bs, which seems to be working, the name ub.edu.bs can be resolved.  
If one queries for the SOA at edu.bs, the negative answer is the right answer – 
showing the SOA record owned by bs.

Asking for the SOA for com.bs., the responses I see, from all three servers for 
bs., have an authority section pointing towards the NS set for com.bs.  This 
makes little sense as, if there is no soa record for com.bs, It can’t have an 
ns set.

It’s hard to tell remotely, but, you probably want to set up com.bs just like 
edu.bs.  But that’s not very reliable advice, based on not knowing the full 
intentions nor the contents of the zone file.

From: dns-operations  on behalf of BS 
Domain Administrator 
Date: Tuesday, September 27, 2022 at 2:32 PM
To: "dns-operati...@dns-oarc.net" 
Subject: [Ext] Re: [dns-operations] ENT NXDOMAIN problem at .BS nameserver 
ns36.cdns.net

Thank you for your email.
Please test again and let us know if the problem still occurs.

Best regards,

BSNIC
Office of Information Technology
University of The Bahamas
University Drive
PO Box N4912
Nassau, NP
The Bahamas
www.register.bs

From: Viktor Dukhovni 
Sent: Tuesday, September 20, 2022 8:33 PM
To: dns-operati...@dns-oarc.net 
Cc: BS Domain Technical Contact ; BS Domain Administrator 

Subject: ENT NXDOMAIN problem at .BS nameserver ns36.cdns.net

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::24ns36.cdns.net
194.0.1.36ns36.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] Follow up to the talk - Beta availability of Two Data Sets

[Edward Lewis]

(This isn't operational, but it relates to the DNS-OARC workshop held last 
week.  Which raised a side question: Ought there be a 
dns-resea...@lists.dns-oarc.net?) 

As a follow up comments that JSON is necessary  I've added a JSON version 
for each CSV file on the DNS Core Census website.  Even a JSON version of the 
catalog.  The catalog.csv lists only CSV files.  The catalog.json lists only 
JSON files.  I figure that is appropriate.

For those who didn't attend, the slides for the talk are here: 
https://indico.dns-oarc.net/event/42/contributions/903/attachments/872/1594/Beta%20Availability%20of%20two%20TLD%20Data%20Products.pdf

On slide 8, where it mentions CSV, there is now JSON (including csv.gz -> 
json.gz)

Uncompressed, JSON is 2-3 times the size of CSV, compressed JSON is about 1/2 
the size of CSV.  I'd never expected that.

In addition, in the code directory there are now these two scripts 
demonstrating how to download the census:

get_dns_core_census_from_web_via_csv.py
get_dns_core_census_from_web_via_json.py

The diff between the two are, showing how "easy" pandas makes this in python 
(;)) and why I was wondering why JSON was preferred.

47c47 --> change the catalog
<   catalog_url = 
'https://observatory.research.icann.org/dns-core-census/v010/table/catalog.csv'
---
>   catalog_url = 
> 'https://observatory.research.icann.org/dns-core-census/v010/table/catalog.json'
51c51 --> read the catalog in the right format
<   catalog = pd.read_csv (catalog_url,dtype=str,na_filter=False)
---
>   catalog = pd.read_json (catalog_url,dtype=str)#,na_filter=False)
83c83 --> read each table in the right format
<   dataframes[row['TABLE_TOPIC']] = pd.read_csv 
(read_file,dtype=str,na_filter=False)
---
>   dataframes[row['TABLE_TOPIC']] = pd.read_json 
> (read_file,dtype=str)#,na_filter=False)



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

Re: [dns-operations] [Ext] Re: Checking for signatures of a certain DNSKEY within a zone

[Edward Lewis]

On 7/6/21, 12:15 PM, "dns-operations on behalf of Tony Finch" 
 wrote:

>If it is one of your zones then your key management software should ensure
>that all the key IDs are different, i.e. if there is an ID collision when
>generating a key, throw it away and regenerate it. This is important for
>verification performance (and, I would guess, less risk of encountering
>bugs).

FWIW, I've seen one (emphasize just one) example of concurrent, active, 
colliding key tags among the TLDs over the past 10 years.  When it happened, it 
seemed to persist for a month, with the operator rolling one of the keys.  This 
happened in 2018, I didn't notice it until last month while trolling through 
historical data, so I bet there was never any interruption.

The protocol ought not be fooled by it, but you can never tell about the 
quality of a validator.  I.e., such code may not realize that asking for a key 
tag out of a DNSKEY set might need to be a list and not a single value.

This started out as a convention, key generation tools would not produce a key 
that key-tag-collided, but as with any other tool or environment, it might 
occur.

Where I ran across the issue is in some analytical code I'm working on, a 
collision might foul up other monitoring and visualization code, but it should 
not be operationally impacting.


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

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

[Edward Lewis]

On 6/10/21, 2:35 AM, "dns-operations on behalf of Petr Špaček" 
 wrote:

>Personally, with all the experience we have in 2021, I find the historic 
>decision to put authoritative NS RRs to the child side to be a poor 
>choice, to the point of being indefensible.
>
>As Anthony points out, the parent version of NS has to work anyway. It 
>forces me to think a better course of action would be ignoring 
>child-side NS instead of adding complex asynchronous code paths to 
>validate child NS, which is not technically needed.
>
>I mean - why waste resources on improving something which is not even 
>needed?

You need to consider that there are two states - steady and changing.

In a steady state, the two sets are redundant, and redundancy breeds a risk of 
inconsistency.  So, having both seems suboptimal.

But when the (authorized) zone admin is changing name servers, you need to be 
able to let the child take the lead.  This allows a zone admin to configure 
nameservers and bring them up before having to contact the parent admin.  In 
days of yore, contacting the parent was very manual and delay ridden.  Perhaps 
there is better automation now, but still the ability to do a local test of any 
change is important.  Or so I thimk.

On the other hand, relying on the child set of name servers risks falling into 
a trap where a hijack of the name servers "sticks" because of high TTLs.  (The 
TTL making records stick in caches even after the clean up.)

DNSSEC signs the child side (apex) servers and not the parent side (cut point) 
servers.  The parent is authoritative for the zone cut's existence, but the 
child is authoritative for how they run their portion of the name space, hence 
what name servers are in use.  This is why the NS is set in the cut point 
NSEC/NSEC3 but the NS isn't signed.

There's also another angle to consider - the aggressiveness of the querier.  A 
querier can be aggressive in time - fast answering - and/or it can be 
aggressive in getting a workable (and/or secure) answer.  Sometimes the child 
copy is better (authorized admin is changing), sometimes the parent copy is 
better (the change was unauthorized or malformed).  Relying on the parent is 
[probably] faster (fewer servers to contact), but pure speed isn't the goal.

No conclusion - just some thoughts.



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

[dns-operations] The 10th Registration Operations Workshop (ROW#10) | June 8th, 2020 | 13:00 - 17:00 UTC

[Edward Lewis]

The 10th Registration Operations Workshop (ROW#10) | June 8th, 2020 | 13:00 - 
17:00 UTC



ROW#10 will take place via Zoom Webinar platform on Tuesday, June 8th, 2021, 
13:00 – 17:00 UTC. Additional time zones may be checked 
here.
 Those interested in attending are required to 
register in order to receive the 
access information (meeting ID and password).



For details regarding the agenda, check out Marc Blanchet’s [Viagenie] recent 
blog 
post
 or visit https://regiops.net. If you have any questions, 
please contact us at r...@viagenie.ca.



We would like to thank our ROW Series Sponsors ICANN 
and Verisign for their continued support.



-

Here are some special tips if this is your first time using Zoom or you wish to 
get more familiar with its web conferencing capabilities:



   •Download the Zoom application to your computer or mobile phone. You can 
do it at https://zoom.us/download. You will also be prompted to download and 
install Zoom when you click the link to join. You can also run Zoom from your 
web browser by navigating to join.zoom.us and entering 
the meeting number and passcode.

   •Want to try it out before June 8th? Join a test meeting at 
https://zoom.us/test anytime to familiarize yourself with Zoom. You can also 
access Zoom tutorials here: 
https://support.zoom.us/hc/en-us/articles/201362193-How-Do-I-Join-A-Meeting-

   •As an attendee, you will be muted. For questions and comments, please 
use the Q feature. The session moderator will address them to the speakers on 
the mike as time permits. Questions that cannot be answered due to time 
constraints, will be answered directly in the Q window or by email.

   •You do not have to use the Zoom web conferencing platform with video to 
participate. There is an option to call-in only.

   •We will be recording this webinar, including the chat, and making it 
available on our website 48h after the session.

-



We look forward to seeing you online!



ROW Program Committee



Stay tuned for further updates! Follow 
@ROW_by_Viagenie

ROW website: https://regiops.net

Contact us: r...@viagenie.ca

ROW mailing list: regi...@googlegroups.com

ROW series: co-sponsored by Verisign & 
ICANN, organized by Viagenie



(cross-posting to multiple lists - sorry for any duplicates)


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

Re: [dns-operations] [Ext] Re: DNSSEC and multiple signatures

[Edward Lewis]

On 5/17/21, 8:15 PM, "dns-operations on behalf of Viktor Dukhovni" 
 wrote:

>Bottom line: make sure *all* your signatures are valid, if you sign
>with multiple algorithms...
 
I disagree with that advice.  Building a truly verifiable (following all the 
rules as well as cryptographic calculations) chain of trust is hard enough that 
having one chain is sufficient reason to accept a data set as authentic and 
complete.  (Note though that an authentic and complete data set may not be the 
latest version or even correct.)

But reading Viktor's statement over and over, perhaps I should clarify:

When signing - "don't screw up", yes, do your utmost to: make sure *all* of 
your signatures are valid, (whether or not) if you sign with multiple 
algorithms.

But when signing, data changes and you may publish a signature in one moment 
and a new data set (with a new signature) in the next moment (new zone serial 
number).

When validating - the world looks different because of that.  A validator ought 
to be satisfied with any single complete chain.

A broken signature alongside a working signature might be a case of a software 
bug in a crypto-library or signature preparation.  In a time when data sets are 
changing, it's possible that a wonky verifier might confuse an older signature 
with a newer set.  (This is what was anticipated in the days of yore when the 
protocol was assembled.)

And we anticipated this - if one wanted to DOS a data set that was DNSSEC 
signed, just add a garbage signature to the message.  If the validator tossed 
the set at the sight of a failed chain, you'd accomplish your goal.  Generating 
garbage to bring something down is much easier than forging a signature.  Ok, 
not exactly the same vulnerability, but we really can't anticipate what an 
adversary might want to do, other than disrupt a service.

There was a validator once (name withheld to protect the guilty, many will know 
the case) that failed data sets when it saw a set signed with one algorithm and 
had a valid chain, but then saw a second algorithm in the authoritative zone's 
DNSKEY set.  Although a signer must generate signatures of all algorithms in a 
zone's DNSKEY set, this rule does not apply in validation.  Why?  Because the 
validator might be getting a copy of the data set emitted before the new key 
was published in the DNSKEY set.  Validators can't assume that all the data 
sets for a zone (or even a name) are from the same zone serial number.

Morale: DNSSEC makes the DNS more brittle (by eliminating protocol states that 
are questionable).  Don't over tighten it.


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

[dns-operations] ROW#10 - Final call for proposals

[Edward Lewis]

ROW#10: Register now & submit your proposal before May 14th, 2021

The 10th Registration Operations Workshop 
[regiops.net]
 (ROW#10) is scheduled to take place via remote participation on June 8th, 
2021, 13:00 - 16:00 UTC.

IMPORTANT: Registration is required to enable participation!
Those interested in attending the virtual meeting are required to register at 
the following link in order to receive the access information for the online 
session: https://regiops.net/events/row10registration/ 
[regiops.net]

Please note that the call for presentation and panel proposals is still active. 
Proposals in the form of a short abstract shall be submitted to 
r...@viagenie.ca. Deadline is May 14th, 2021. 
Discussions of workshop topics may also take place on the 
regi...@googlegroups.com mailing list.

In keeping with the Registration Operations' focus of the ROW, possible topics 
for this session could be:
• RDAP implementation experience
• DNS abuse
• DNS privacy and encryption
• Differentiated access
• Authentication and authorization
• Credential Security/Credential Management
• DNSSEC operationalization (CSYNC, managing transfers of secured domains)
• Registration support functions (data escrow/business continuity)
• Automation
• Other innovative uses for registration and resolution technologies

Please feel free to disseminate this Call to other lists where it might be of 
interest.

We look forward to your participation! For additional event details and 
previous ROW sessions, please visit https://regiops.net 
[regiops.net].

ROW Program Committee

Stay tuned for further updates! Follow @ROW_by_Viagenie 
[twitter.com]
ROW website: https://regiops.net 
[regiops.net]
Contact us: r...@viagenie.ca
ROW mailing list: regi...@googlegroups.com
ROW series: co-sponsored by Verisign 
[verisign.com]
 & ICANN, organized by Viagenie 
[viagenie.ca]

(cross-posting to multiple lists - sorry for any duplicates)
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Registration Operations Workshop #10

[Edward Lewis]

ROW#10: Register now & submit your proposal
June 8th, 2021 | 13:00 - 16:00 UTC | Zoom Video Conference

ROW#10 will be held via remote participation on June 8th, 
2021, 13:00 - 16:00 UTC. Check additional time zones 
here.

Registration is NOW available at: https://regiops.net/events/row10registration/

ROW's Program Committee has also opened the call for presentation and panel 
proposals and is interested in:

  1.  Topic related presentation proposals.
  2.  Topic suggestions for focused panel discussions.
  3.  Suggestions for additional topics.
In the past, workshops have included discussions focused on Extensible 
Provisioning Protocol (EPP), WHOIS, Registry Lock, Registration Data Access 
Protocol (RDAP) and many more. Below is a non-exhaustive list of possible 
topics for this session.

• RDAP implementation experience
• DNS abuse
• DNS privacy and encryption
• Differentiated access
• Authentication and authorization
• Credential Security/Credential Management
• DNSSEC operationalization (CSYNC, managing transfers of secured domains)
• Registration support functions (data escrow/business continuity)
• Automation
• Other innovative uses for registration and resolution technologies

Please email a short abstract describing your proposal to 
r...@viagenie.ca

We also encourage discussions/suggestions for additional topics on ROW’s 
mailing list regi...@googlegroups.com.

Important dates:
• Deadline to submit proposals: May 14th, 2021
• Program Committee to notify selected authors by May 21st, 2021
• Speaker agreements and materials required from selected presenters by May 
31st, 2021

We hope that you can join us and request that you disseminate this Call to 
other lists where it might be of interest.

ROW Program Committee

Stay tuned for further updates! Follow 
@ROW_by_Viagenie
ROW website: http://regiops.net
Contact us: r...@viagenie.ca
ROW mailing list: regi...@googlegroups.com
ROW series: co-sponsored by Verisign & 
ICANN, organized by Viagenie

(cross-posting to multiple lists - sorry for any duplicates)
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] Historical reminiscences (was Re: nsec vs nsec3 use)

[Edward Lewis]

On 4/13/21, 7:38 PM, "dns-operations on behalf of Andrew Sullivan" 
 
wrote:


>Maybe some others have a different memory of this, though?

I agree with that re-telling.

The idea of an opt-out/in existed prior to NSEC3, it was even implemented in 
experimental code but never released because the IETF didn't approve of it.  (I 
wasn't involved in that, but I knew of it.)

When I wrote the first signer (1997 or so), COM was too large to be done, much 
larger than any other zone even then, for the equipment available to me.  I 
managed to sign it by doing it in pieces.  While developing the protocol, we 
didn't want to treat any zone or even any kind of zone ("widely-delegated") as 
a special case.  That probably (as I wasn't working on it myself) led to the 
opt-out later on.

A while back I asked some involved in the NSEC3 development if they felt all 
the effort was worth it.  The answer was yes, it got DNSSEC past the privacy 
concerns, rightly or wrongly (doesn't matter) and into operations.  The context 
of my question were the growing revelations of code to reverse engineer the 
name chain.


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

Re: [dns-operations] [Ext] Progress on algorithm 5 and 7 decommissioning

[Edward Lewis]

On 10/14/20, 2:24 PM, "dns-operations on behalf of Viktor Dukhovni" 
 wrote:

>These give a much broader picture of DNSSEC practice that what one learns by 
>looking at just the ~1500 TLD DNS/DNSKEY RRsets.

That's true.  Drawing from an old conversation on the data I've been curating 
"how (or what) you measure depends on why you measure."  My goal has been to 
characterize DNSSEC operations among the TLDs, particularly the timing of 
events.  (E.g., the passing phases of a key's lifecycle.)  For that, duration, 
consistency, and stability of the data is important.

There are plenty of other measures to make.  The data set with which I work 
focuses just on the "core" of the infrastructure, not the popular use of the 
system.  It's pretty easy to see that, while 90-91% of TLDs have DNSSEC, other 
estimates show that about 30% of resolvers and lower percentages of delegations 
are signed, that looking only at the TLDs one isn't getting a full view.


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

Re: [dns-operations] [Ext] Progress on algorithm 5 and 7 decommissioning

[Edward Lewis]

On 10/14/20, 12:29 PM, "dns-operations on behalf of Viktor Dukhovni" 
 wrote:

On Wed, Oct 14, 2020 at 03:27:35PM +0000, Edward Lewis wrote:

> This is visible in the attached chart of ccTLD "crypto-choices".  (I'm
> on the agenda for ICANN 69's Tech Day to talk about DNSSEC in the
> TLDs.  I'll have longer-term views of that chart in the slide deck,
> this just focuses on 2020.)

Is that a graph of algorithms used directly by the ccTLD to sign the
ccTLD zone, or a graph of algorithms used by child domains of the
ccTLDs?  My graphs for the latter, across all TLDs, not just ccTLDs,
though the data is admittedly only as complete as the 80% to 90% or so
of the various zones I'm able to scavenge when official feeds are not
available.

The data is for the TLD (or the one-label name delegated from the root) itself, 
i.e., what's at the apex.

I don't have (special) access to what's inside any given ccTLD.  I mean, we can 
scrounge for available ccTLD zone files, but I couldn't "source" meaningful 
data just from that set.


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

Re: [dns-operations] [Ext] Progress on algorithm 5 and 7 decommissioning

[Edward Lewis]

This is visible in the attached chart of ccTLD "crypto-choices".  (I'm on the 
agenda for ICANN 69's Tech Day to talk about DNSSEC in the TLDs.  I'll have 
longer-term views of that chart in the slide deck, this just focuses on 2020.)

On 10/12/20, 9:14 PM, "dns-operations on behalf of Viktor Dukhovni" 
mailto:dns-operations-boun...@dns-oarc.net>
 on behalf of ietf-d...@dukhovni.org> wrote:


I'm seeing continuing progress on algorithm 7 and fresh
progress on algorithm 5 decommissioning.  See the attached
graphs.

By far the largest remaining cluster (>300k) of algorithm 5
zones were under .com.br and these are should all be upgraded
to algorithm 13 over the coming ~10 days.  Thus the algorithm
5 graph is showing that count falling dramatically.

The algorithm 7 downward trend is less dramatic, but by now
clearly established as unlikely to be a fluke.

Nice to see solid progress on both fronts.  Congratulations
to all the folks doing the hard work of algorithm rollovers.

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


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

Re: [dns-operations] [Ext] Re: Stale NTA for "peek.ru" at Cloudflare?

[Edward Lewis]

Responding to two messages, perhaps with a "get off my lawn" old-guy attitude:

On 3/13/20, 4:59 PM, "dns-operations on behalf of Marek Vavruša" 
 wrote:

>the DSA-NSEC3-SHA1 has been deprecated in
>https://tools.ietf.org/html/rfc8624 so zones below DS with these keys
>are effectively treated as unsigned zones (rfc4035 5.2),
>but you raise a good point that the method of doing so is not consistent.

This lament is in line with the talk I gave last month on the different ways 
ANY was minimized.  There's a need to constrain the protocol to avoid this kind 
of confusion.

On 3/13/20, 7:52 PM, "dns-operations on behalf of Viktor Dukhovni" 
 wrote:

>In future RFCs deprecating algorithms (e.g. soon I hope RSASHA1 5 and
>RSASHA1-NSEC3-SHA1 7) we should perhaps aim to first specify "MUST NOT"
>for signing, and only some time (years) later "MUST NOT" for validation.

>Which I think ideally means updating "8624" *this year* with a "MUST NOT"
>for signing for 5 and 7, with a view to "MUST NOT" also for validation
>no earlier than 2022.
 
I've never been a fan of an RFC document defining the contents of a registry 
(in this case the DNSSEC Security Algorithm registry) also making statements on 
whether a parameter ought to be used.  I don't think this approach "works."  
The DNS protocol is used on networks that are not connected to the global 
public Internet.  (I have one example network in mind - if it still exists, I 
should add.)  Mixing protocol definition and operational guidance is the 
problem when you are solving for multiple operational environments.

A founding principle of DNSSEC is "local policy rules."  I understand that this 
was established in an era where anyone dealing with DNSSEC had a graduate 
degree in some sort of engineering, but I still think it applies in a different 
form.  I would leave it up to a validator to make a decision on whether it will 
accept data as valid.

I may be mistaken, but the IETF does not like specifying default values for 
tools.  In this instance, I believe that there ought to be document that does.  
First, I'd start with validation (as that's where the real work of DNSSEC is 
done), with an "I accept this" policy.  The "default" set of DNSSEC Security 
Algorithms could be tool-set with local operator override.

As far as signing, it's fine for a tool to warn against using an algorithm but 
realize there are two steps towards eliminating an algorithm's use.  First, old 
tools will still be around, meaning "stopping signing" won't stop signing.  
Second, tool refresh may not be followed with a configuration refresh (evident 
in BIND and the KSK rollover).  An operator may not be ready to change 
algorithms - especially if the change is not automatic.

I don't think you can expect to change signing habits first.  And I don't think 
you can change habits until tools change the default values in a way that is 
entirely transparent to the lay operator.



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

Re: [dns-operations] [Ext] Re: Is this DNS Flag Day 2020 including 'in-addr.arpa.' and 'ip6.arpa.' clean-up?

[Edward Lewis]

I think the reaction you are getting is due to the call for a "DNS Flag Day" 
and not the issues you are experiencing.  On this list (DNS-operations), DNS 
Flag Day (2019) was a significant event involving many implementations of the 
DNS protocol to adhere more closely with the specifications of the protocol.  A 
goal was to simplify the code bases involved.

You seem to be asking for some changes in the registration information 
regarding (for one here) a netblock.

On 2/19/20, 11:45 AM, "dns-operations on behalf of Pirawat WATANAPONGSE" 
 wrote:

>Well, let’s look at the real netblock, shall we? (‘cause I have nothing to 
>hide)
>You can see for yourself at https://dnsviz.net/d/108.158.in-addr.arpa/dnssec/
>
>1. There are old DS keys from .arpa to in-addr.arpa still dangling around.
>2. 158.in-addr.arpa is still using ‘Algorithm 5’
>3. Even though my http://158.108.0.0/16 netblock was ROAed, APNIC did not link 
>me to the ‘reverse’ DNSsec chain:
>3.1. Why? Because it’s a ‘Historical’ netblock, transferred from ARIN to APNIC 
>epochs ago. So, my ‘domain’ is with NIR (thank god), my ‘netblock’ Whois is 
>now with APNIC, but my ‘reverse’ is still with ARIN.
>3.2. If I want to hook into the ‘reverse’ DNSsec chain, who do I send my DS 
>key to? APNIC? ARIN?
>3.2.1. APNIC is not the SOA of 158.in-addr.arpa.
>3.2.2. I am no longer a ‘client’ of ARIN, the SOA of 158.in-addr.arpa.

As this is a DNS operations list and not an RIR list, you may be addressing the 
wrong audience.

Think of ARIN as the DNS hoster.  They produce the 158 zone.  They take data 
from the other RIRs to assemble it.  That's why the SOA RNAME has arin.net in 
it.

Think of APNIC as the registry.  Your registration interaction is with APNIC.  
... ummm ... When I wrote that I recalled you mentioning an NIR.  I am not sure 
how the TH NIR runs.  As in, the JP NIR does run 133.in-addr.arpa, but no other 
NIR runs such a zone; and only JP's NIR has a whois service that uniquely 
services their registrations.  So, I don't know if you need to find the TH NIR 
or go to APNIC directly. ... which leads me to believe you might be on the 
wrong list with this.




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

Re: [dns-operations] [Ext] Re: Is this DNS Flag Day 2020 including 'in-addr.arpa.' and 'ip6.arpa.' clean-up?

[Edward Lewis]

I've been doing some examinations of ip6.arpa and in-addr.arpa as part of other 
work and I'd say they are pretty darn clean as they are.  So I (too) am curious 
what would be needed as part of a "Flag Day" level clean up.

I'm looking at the delegation information in the two zones and the information 
at the zones they delegate.  As far as delegations from those zones to RIR run 
zones, I'd say they are perfect.  For a while there were two zones with 
misaligned NS sets, but they were "fixed" rather speedily last week.  (There's 
no glue in the zones.)

What I mean by "delegations from those zones to RIR run zones" means that there 
are a few delegations from ip6.arpa and in-addr.arpa that go to non-RIRs or are 
"special" (like 10.in-addr.arpa).  Of those, there are some hiccups but that is 
something that is best handled by addressing the individual situation.  I don't 
see a "Flag Day" level concern - thus my curiosity above.

On 2/14/20, 2:24 PM, "dns-operations on behalf of Ondřej Surý" 
mailto:dns-operations-boun...@dns-oarc.net>
 on behalf of ond...@sury.org> wrote:

Hi,

the DNS Flag Days initiative focus on protocol issues, and neither forward or 
reverse zones are in the focus.

If you have anything specific you could bring this up here. How is the .arpa 
neglected?

Ondrej
--
Ondřej Surý 


On 14 Feb 2020, at 18:22, Pirawat WATANAPONGSE  wrote:

If you think my topic is irrelevant to DNS Flag Day 2020, or if someone has 
already mentioned it, I do apologize.

My reasoning is that the campaign is lopsided; we are focusing on the ‘forward’ 
zones (because those are our children, bear our names, and we like to brag), 
but the 2 huge ‘reverse’ zones are neglected (because they are the bastard 
children).

Anyone plans to clean up the ‘in-addr.arpa.’ and ‘ip6.arpa.’ this upcoming Flag 
Day? Or it is not a priority (just yet) at this moment?

By the way, do not confuse properly scaffolding the (reverse) zones from 
populating them; from my point of view, they are separate issues. Even if you 
are ever going to put just one PTR into it, a properly secured, hierarchized, 
delegated (reverse) zone is still crucial.


My two cents’ worth,

Pirawat.

--
_/_/  _/_/ _/_/   _/_/ Assist.Prof. Pirawat WATANAPONGSE, Ph.D.
   _/_/_/_/   _/_/   _/_/ Department of Computer Engineering
  _/_/  _/_/ _/_/   _/_/ Kasetsart University, Bangkhen (Main) 
Campus
 _/_/_/_/   _/_/   _/_/ Bangkok 10900, THAILAND
_/_/_/_/   _/_/   _/_/ eMail: 
pirawa...@ku.th or 
pirawa...@ku.ac.th
   _/_/  _/_/ _/_/   _/_/ Tel: +66 2 797 0999 extension 1417
  _/_/_/_/_/_/_/_/_/_/ Fax: +66 2 579 6245
_/_/  _/_/  _/_/_/_/http://www.cpe.ku.ac.th/~pw/

___
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] [Ext] Re: any registries require DNSKEY not DS?

[Edward Lewis]

Answering a pair of messages in one reply:

On 1/23/20, 5:25 AM, "dns-operations on behalf of Paul Vixie" 
 wrote:

>On Thursday, 23 January 2020 02:51:28 UTC Warren Kumari wrote:
>> ...
>> 
>> If the parent makes the DS for me from my DNSKEY, well, then the DS
>> suddenly "feels" like it belongs more to the parent than the child,

The semantic meaning of the DS resource record is this - it's a statement by 
the parent(zone administration) about the child (zone administration).  The 
presence or absence of the DS record is the parent's signal, even if the 
contents are determined by the child or from data submitted by the child.

The same "parent for the existence, child for the contents" rule applies to the 
NS set.  That's probably where the idea came to life.

(Pauls'):
>as you see, the DS RRset is authoritative in the parent, in spite of its name 
>being the delegation point, which is otherwise authoritative only in the 
>child. so, DS really is "owned by" the delegating zone, unlike, say, NS.

Yep - Existence of the NS belongs to the parent, that's why it is in the 
parent's NSEC/NSEC3 chain.  But the targets belong to the child, that's why the 
parent doesn't sign it.

IMHO - I wish we had something like NSparent (cut/hints) and NSchild 
(apex/auth).
   
>historians please note: we should have put the DS RRset at $child._dnssec.
>$parent, so that there was no exception to the rule whereby the delegation 
>point belongs to the child. this was an unforced error; we were just careless. 
>so, example._dnssec.com rather than example.com.

I'm don't recall the decision process and "Delegation Signer (DS) Resource 
Record (RR)" (RFC 3658) doesn't discuss why the DS is at the same name.  
Underscore names were not yet a concept, although there were earlier thoughts 
of using different labels in DNSSEC or aggregating DNSSEC information (I have a 
failing recollection of Ohta's alternative).

Using the underscore idea would eliminate the precedent of a name with 
authoritative data in two zones but it might have set precedents in the 
assembly and parsing of referrals (to pick one item).  Meaning - I'm not 
certain we made a bad choice.  Any approach has it's positives and negatives, 
eminating from the original choice of placing the (same RR type) NS being at 
both parent and child.



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

Re: [dns-operations] [Ext] Re: Surprising behaviour by certain authoritative name servers

[Edward Lewis]

On 1/8/20, 7:40 AM, "dns-operations on behalf of Niall O'Reilly" 
 wrote:

On 7 Jan 2020, at 12:53, Greg Choules wrote:

> I don't think it's a protocol violation,

I think that's arguable. RFC1035, section 6.1.3:

  Both the TTL data for RRs and the timing data for refreshing activities
  depends on 32 bit timers in units of seconds.  Inside the database,
  refresh timers and TTLs for cached data conceptually "count down", while
  data in the zone stays with constant TTLs.

I'd agree that it **is not** a protocol violation based on this line of 
reasoning:

Imagine the zone being re-loaded often (more than once a second) with the 
effect that every second or wall clock results in the(/a/each) set's TTL 
lowered by one.  That's "legal" and would result in a protocol-compliant 
implementation acting as observed.

Admins are allowed to do silly things ... the protocol permits that. ;). And 
that is why remote, third-party debugging of server operations is tricky.


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

Re: [dns-operations] Verifying that a recursor is performing DNSSec validation

[Edward Lewis]

On 7/14/15, 1:08, dns-operations on behalf of Frank Bulk
dns-operations-boun...@dns-oarc.net on behalf of frnk...@iname.com wrote:

Is there an existing tool, ideally a NAGIOS-friendly one, that performs a
check against a resolver that it gets an AD back on DNSSec query for a
zone
that is properly signed, failure for one that is not properly signed, and
nothing for one that isn't signed?
http://docs.menandmice.com/display/MM/How+to+test+DNSSEC+validation

I'd rather not re-invent the wheel if it already exists.

For the positive, negative, neutral tests, there are people who have set
up testable zones.  However, if you really want to control your
environment (which I would recommend for testing that is NAGIO-friendly),
I'd set up  in-house zone-under-test subjects.  The risk mitigation load
is then shifted to making sure your test targets are always properly
configured (long-lived signatures, no key rotation, short TTL, etc., are
appropriate if you are just testing the mechanism).


smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] about anti-ddos DNS hostings

[Edward Lewis]

On 6/16/15, 16:13, Florian Weimer f...@deneb.enyo.de wrote:

* Edward Lewis:

 It's not just a matter of the rich getting richer and the poor getting
 poorer, it's a matter rooted in a technical fault in the architecture of
 the system.

It's not a technical fault.  There's little liability for forwarding
packets with forged source addresses, or designing networks with that
flaw built into them.  There's no technical solution to that.  You
can't stop pollution by creating better filters because there is
always an incentive not to filter your waste at all.

My point of view is that the approach of security additions over the past
decades has exacerbated the problem rather than alleviated it.  Practical
solutions to security start with ensuring the usefulness of the system is
paramount - availability increased via the reduction in abuse.  Our
approaches haven't met that principle.

DNS knows that UDP is unsafe.  Yet DNS relies on it.  Pointing fingers at
UDP is like sticking your head in the sand and ignoring the problem.
There's been no approach that has gained consensus enough to even begin
talking about deployment incentives.


smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] about anti-ddos DNS hostings

[Edward Lewis]

On 6/11/15, 1:30, bert hubert bert.hub...@netherlabs.nl wrote:
Quoting :
Geoff Huston's thinking on ... http://labs.apnic.net/?p=624

(CC'd Geoff in case he's not on this list.)

Can we shift our
collective focus back to the common good, and shift our focus away from
selected potential victims who can afford private protection and instead
focus on the attacker and the attacks that they carry out?

In 2013 my personal conclusion was that those that defended themselves
(through principally DNSSEC, over capacity, and anycast) had managed to
become unwitting accomplices with the attackers.  The defenders had
essentially built an attack traffic utility (like an electric utility)
capable of flooding others.  The root cause was the inability to manage
the transport layer UDP.

https://centr.org/system/files/agenda/attachment/tech28-lewis-dns_reflectio
n_attacks-20130603.pdf

It's not just a matter of the rich getting richer and the poor getting
poorer, it's a matter rooted in a technical fault in the architecture of
the system.

I think there's some progress on that line of reasoning...

https://centr.org/system/files/agenda/attachment/rd-koch_mayrhofer-news_tra
nsport_4_dns-20150603.pdf


...as an example of beginning the work on addressing this.


smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] DNSSEC issue - why?

[Edward Lewis]

On 6/9/15, 3:12, Kevin Chen kc...@mit.edu wrote:


which looks quite simple, however the KSK DNSKEY from hollington.ca is
 part of the DS set. The only notable part of the DS set is that it
 contains 4 keys, among which is an older (?) with a longer hash.

RFC 4509 says:

Implementations MUST support the use of the SHA-256 algorithm in DS
RRs.  Validator implementations SHOULD ignore DS RRs containing SHA-1
digests if DS RRs with SHA-256 digests are present in the DS RRset.

I assume the various resolvers are making different choices with regard
to SHOULD.

Hmmm, I would have never interpreted that requirement that way.  I always
had in mind per key.  FWIW, my provided recursive server (i.e., without
prodding I don't know the 'brand' of code) SERVFAILs when asked for keys.

For a long time I've been critical of how this RFC handles transitioning
from hash 1 to hash 2.  I've measured a selection of zones and their
choices, in particular whether they are hash 1, hash 2 or both.  At some
point the IETF ought to provide more guidance on whether hash 1 ought to
be abandoned by operators.


smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

[dns-operations] Downgrade attack readiness Re: DNSSEC issue - why?

[Edward Lewis]

On 6/9/15, 10:24, Casey Deccio ca...@deccio.net wrote:

 But when you consider a downgrade attack, the attacker only needs the lowest
 hanging fruit.  That means that *any* DS (regardless of DNSKEY) with the
 weaker digest type could potentially be used for falsifying a DNSKEY.

I'm just going to throw this on the mat - perhaps we've (and I mean the
loose collective of folks involved with DNSSEC over the decades) had a poor
understanding of downgrade attacks (how they happen, etc.) and have poorly
addressed them. Given that I've never seen one (downgrade attack) work (in
practice/in the field), I've never been able to reverse engineer it.  Having
an academic/theoretic understanding is often times not sufficient.

Like learning to take down a spinnaker on a sailboat on a calm day in the
dock and then expecting to execute the steps heeled over in a gale.  Or
learning to change a diaper on a doll and then expecting to do the same for
the first time in the back seat of a car. ;)  Those are two areas where
cleanroom experience didn't translate to real world experience so much.

In general - has anyone seen an actual attack thwarted by DNSSEC?  Or an
attack beat a DNSSEC defense?  Not looking to justify the investment,
looking for the opportunity to reverse engineer.




smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] DNSSEC issue - why?

[Edward Lewis]

On 6/9/15, 7:42, Mark Andrews ma...@isc.org wrote:

How could it be done per key?  keyid's don't identify a key.  They
identify a set of keys.

Perhaps but in practice that's not happened.  Some key management software
won't produce a DNSKEY RR matching an existing keyid.  And - per key
could still be done via matching within the subset.  But this is a trivial
point.

In general adding one hash of DS alg 2 is probably sufficient to say that
all the 1's are old, but then the RFC ought to have handled this better.
(Like recommending that if any DS 1's are there and a DS 2 is added, have
a DS1 and DS2 for all keys [or for the pendantic] keyid's.)

A long time opinion of mine is that RFCs ought to stick to defining
terms/protocol points in one place and then separately talk about
operational profiles - preferably in documents that can be referenced
separately (like in RFP's and contracts).  I found that trying to make
code prefer newer technologies over old by fiat seems to backfire (like
the way DNS used to prefer v6 over v4 and now seems to have reversed,
looking at some observed behavoral studies).


smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Nice to see Amazon Route 53 remove the EDNS(1) filters for *.co.uk.

[Edward Lewis]

Overall question.  Looking at the chart on that URL, it seems like things
are trending the wrong way, with the possible exception of the one
well-performing bunch - the Bottom 1000 Servers [sic].

Is that right?  Excepting the one bump up on May 20, it seems like things
are actually trending down, not up.

On 5/27/15, 6:06, Mark Andrews ma...@isc.org wrote:


The jump up on May 20 was the EDNS(1) block being removed from
the Amazon Route 53 *.co.uk servers.  Now for the other blocks
of servers to stop block EDNS(1) queries.

http://ednscomp.isc.org/compliance/ts/edns1resp.html

There are some TLD operators who could do the same.

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


smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

[dns-operations] EDNS vs DDOS scrubbing - was Re: Nice to see Amazon Route 53 remove the EDNS(1) filters for *.co.uk.

[Edward Lewis]

I'm reacting because I see a case of someone observing symptoms,
presenting eye-catchy colorful pictures and then running hard into the
land of diagnosis.

On 5/27/15, 7:10, Mark Andrews ma...@isc.org wrote:

For others is is scrubbing / DoS services which are blocking EDNS(1)
queries.

This sounds like there might be a need to analyze a trade-off.  Taking the
leap of faith that the dropping EDNS(1) figures is caused by DDoS
scrubbing services, the question is why?  Is EDNS(1) and DDoS scrubbing
incompatible?

I will offer that, from what I've seen, DDoS scrubbing seems to offer
value to the Internet.  I.e., I don't think that it's not simply going to
go away.  (I'm remaining neutral on the question of value-for-money, in
the sense that's not the topic here.)  I seriously doubt that DDoS
scrubbing services will go away because they interrupt EDNS(1) adoption.

Perhaps there isn't a conflict, it is just that the testing is throwing
packets into a hole and declaring failure.  Perhaps the lost EDNS(1)
traffic ought to be explained away as part of the flotsam that is DDoS
traffic.

I'm just skeptical that a technology or mechanism will see lowered
adoption over time - if it is a good idea. I understand falling adoption
during the phase out/retirement/etc.  You point out the new TLD operators
- but it's dropping across the board (except for the bottom 1000, which
might be related to those cellar-dwellers not being subject to DDoS load,
hence no scrubbing).

I would have expected to see a chart showing over increase in adoption
with perhaps a sector that is failing and needing attention.  I don't see
that in the chart.


smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] EDNS vs DDOS scrubbing - was Re: Nice to see Amazon Route 53 remove the EDNS(1) filters for *.co.uk.

[Edward Lewis]

On 5/27/15, 9:09, Roland Dobbins rdobb...@arbor.net wrote:

On 27 May 2015, at 19:00, Mark Andrews wrote:

 Yes, EDNS compliance issues have been traced to scrubbing services and
 firewalls.

Competent DDoS scrubbing  EDNS0 problems, FYI.  If that's happening
with some specific scrubbing service, it's because those particular
organizations are Doing It Wrong.

I can accept that ... but are so many doing it so wrong that the graphs
are headed in the wrong direction?

(Asking in the sense : what's the right way to reverse the apparent trend?
 I say apparent because it might be the measurement that is faulty.  --
Jes'sayin'.  IOW - a starting question: is there really a problem?)


smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[Edward Lewis]

On 5/4/15, 3:11, Stephane Bortzmeyer bortzme...@nic.fr wrote:

A new edition of the DNS security guide by ANSSI (French cybersecurity
agency) recommends to prefer delegations with glue because glueless
delegations may carry additional risks since they create a
dependency. Is there any other best practices text which makes such
a recommendation?

I can't read French, so no comment on the report.

I had to diagnose what appeared to be a security incident resulting from
the victim failing to remove glue at the parent when they changed
registration.  Years later, a presumably-unhappy newly-ex employee made
use of that glue in a new delegation to cause harm.  If the new delegation
had to be in bailiwick, then the stale glue couldn't hurt the victim in
this manner.

The trade-off - you (as a registrant) can either spread your eggs across
baskets (mixing glue's TLDs) and then managing all of the vendors involved
-OR- focus your eggs in one basket and then make it bullet proof by being
vigilant.  My observations indicate that the less attentive a registrant
is (as far as being a customer of registration services) the better served
they are to reduce the vendors involved - i.e., staying in bailiwick.
They risk a single point of failure (e.g., the TLD) as a result, but to
that point, glue isn't the worry, the registration is.


smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[Edward Lewis]

On 4/23/15, 2:45, Michał Kępień michal.kep...@nask.pl wrote:

 Yes, its due to bug:
 
  • Fix RCODE when secondary NSD got transfer that includes deleted
wildcard record. After deletion, NSD would serve NODATA, should be
NXDOMAIN (thanks Michal Kepien).

This is fun - I never expected this bug to be publicly noticed for a
TLD.

Bugs happen.  In past work I've done, I've seen some very detailed ones
that even the TLD operator wasn't aware was happening.  (Even big time
operators, in the class of I could call one of their engineers and they
got it right away.)  By bugs, I include unexpected yet sometimes still
very protocol-valid results.

This is an artifact of using off-the-shelf components (open source or not)
which have so many features/etc. that testing every nook-and-cranny is
impractical.  (Risk management ... don't waste resources testing things
that won't matter.)  The issue seen on this thread shows code diversity
(and why some want it), so good.

When bugs pop up I usually contact the operator off-list partly to confirm
that it is a bug and sometimes learn the make and model of what they are
running.  Usually the operator takes care of contacting the tool maker, if
not, I do.  Usually we work that out based on convenience.

Mind you - I not all bugs are serious as in operations impacting.  In
this case, the name in question doesn't 'exist' so any access to it
(WWW/SSH/FTP) is doomed anyway.  Whether it's NXDOMAIN or NODATA, there's
no  or A record to be had.  Yes, you'll trip up DNSVIZ and get your
name in the permanent record.


smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[Edward Lewis]

On 4/15/15, 7:42, George Michaelson g...@apnic.net wrote:

So on that basis: the FTP rule passes: we have open FTP, why would we
block AXFR?

It's your call, it's local policy.  I've worked in environments where the
name servers answering queries did not implement the AXFR mechanism.

Generally unwise can mean that knowledgeable operators will have a
reason to allow it.

(By the same token, why would one use NSEC3 for signed zones when the zone
is available over FTP?)


smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[Edward Lewis]

On 4/15/15, 9:01, Tony Finch d...@dotat.at wrote:

Edward Lewis edward.le...@icann.org wrote:

 (By the same token, why would one use NSEC3 for signed zones when the
zone
 is available over FTP?)

Opt-out.

I thought I was going to avoid expanding the discussion into NSEC3 by
limiting my comment to just that.

Apparently I failed.


smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[Edward Lewis]

John Crain alluded to the point I want to reinforce here.  There are many
different operational postures.  It's tempting to see a situation as it
applies to just one.  The three snips below illustrate common environments
I've run across - TLD (/registration zones), remote debugging
(/third-party management), and enterprise.

When I think of generally I assume the latter environment.  By
comparison, there are very few operations that handle TLD (and root) zone.

The remote debugging is an interesting environment.  On the one hand it is
benign, coaching and basically freely helping others.  But the technical
footprint of it is not far removed from outside surveillance (the NSA or
corporate spying), with the real difference locked into intent.  And
sometimes even benign outside help is considered an intrusion.

As far as generally unwise - I am not the kind who likes loose ends.  By
analogy, I see opening up AXFR on serves like walking with my shoes
untied.  It's convenient (to not have to bend over and tie them) but if I
step on one end I trip over.  Usually, my stance is wide enough that I
don't trip.  The other concern is getting the laces wet in puddles, so I
pull them in. (Yes, it is disturbing I've actually thought about this.)
And worse yet, when I do this, my wife will frown at me.  I.e., once I
mitigate the risks of tripping, stepping in puddles, and the scorn of my
wife, it's fine.  If I don't consider these risk, I've been unwise.

On 4/14/15, 18:58, Patrik Fältström p...@frobbit.se wrote:

I see personally quite a number of registries that are nervous about
XFR (or release of the zone in one way or another)

On 4/14/15, 19:29, Mark Andrews ma...@isc.org wrote:

I, and I know others, have been able to debug DNS problems reported
on bind-users because we could see the full zone contents which
would have been harder or perhaps impossible to solve otherwise.


On 4/14/15, 16:31, Michael Sinatra mich...@brokendns.net wrote:

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



smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[Edward Lewis]

On 4/14/15, 8:29, Mark Jeftovic mar...@easydns.com wrote:

Joke all you want. This is worse than heartbleed.

In short and if I understand this correctly, the problem isn't AXFR's
existence or use, the problem is that systems are poorly configured.

It's like blaming your aorta if a cut causes blood to spill.  The problem
isn't that there is an aorta, it's the cut.

I understand this as a problem.  Tools in common use that do not ease
management or fail to make it apparent what the user has configured is
worthy of CERT advisories (akin to smoking will kill you stickers I've
seen on cigarette boxes).  But blaming a structural element of the
protocol isn't the way to address the issue.


smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[Edward Lewis]

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


smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[Edward Lewis]

(Choosing DNS-operations.)

On 3/13/15, 18:21, Darcy Kevin (FCA) kevin.da...@fcagroup.com wrote:

IANAL, but I think this might have legal ramifications. If they are
advertising/selling DNS services and what they are delivering is not
DNS, then Truth in Advertising and/or Bait-and-Switch statutes,
regulations and/or treaty provisions may apply. ...

Having worked in the same market - that point won't win any arguments.
Whether you are substantively right or not, it won't win any arguments.

Why?  There is a class of customers that don't take the time to know what
compliant DNS is.  There is a class of customers with engineering staffs
that prefer the vendor be non-standard for their own sake.  There is a
class of customers that don't care as much about standards but more about
whether they can switch to someone else.

I've never seen a case of a customer that claimed the service was
deficient because it was counter to a standard or RFC.  I have seen the
reverse, a customer getting mad because a service was brought in line with
specifications, I've had to roll back to non-standard behavior.  This may
be an unfair response because sometimes non-standard behavior is
considered a bug and remedied.


smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[Edward Lewis]

On 3/16/15, 11:05, bert hubert bert.hub...@netherlabs.nl wrote:

Sorry? We solve implementation hardship by standards action now?

My thoughts in this thread (and I'm choosing to keep this in
dns-operations) keep circling because I've spent time at different
perspectives.

On one hand we like to say that the Internet has valued innovation at the
edges.  Innovation is generally doing something unconventional, or
against the standard.  (Yes, it can also mean exploring the unexplored.)
 When doing something against the standard one of the results is
shifting more cost on to your neighbors.

If one values adherence to standards, innovation is shackled to some
extent.  I once made this comment inside a company where there had been
intense cost reducing efforts.  When asked how should we innovate my
answer was to fatten the budget and then illustrated that if you have a
well-tuned machine, any change is going to be burden somewhere else.
Sometimes, as you shift the burden around you can raise revenue to offset
it and sometimes you can shift the burden to where it disappears.  But
during the shifts, innovation and standards often work against each other.

When writing the AXFR update/clarification RFC, one of the motivations was
to isolate AXFR from being an essential element of a DNS server.  There
are zones for which generating a roster is not practical, so it's not
good, if you will, to expect an AXFR to come form it.  Such zones may be
those with telephone numbers (ENUM) or even IPv6 reverse mappings.
Usually practical refers to the speed of updates as opposed to shear
size.

I can imagine an environment in which constructing a DNSSEC-signed
authoritative answer to an ANY query could be a real pain.  In
environments that tailor responses by query source, you'll find that A and
 records are generally from a recipe while the others types are
static, in some cases the A and , or one or the other, don't exist.
Sometimes, if the A and  records are null, you want the entire node to
own no records, whether or not ir exists for the NSEC/NSEC3 chain.  Think
this is stupid DNS tricks?  One might, but, this is something that gets
people to buy DNS hosting services.

When I studied wildcards for that update/clarifications RFC, it was
correctly pointed out to me (by DJB) that standard ways of doing something
need not be the only ways to accomplish something.  For wildcards, the
standards-defined method is compatible with AXFR.  Other means of
synthesizing an answer just wouldn't be - but if one could extend AXFR,
you could expand answer synthesis.  Or maybe this is all just stupid DNS
tricks and we shouldn't bother.

But, I do agree with the handwaving argument to date is insufficient and a
bit weak.  It is right to challenge the proposal as it stands (as I have
done too).  While I an inclined to agree to deprecate qtype=ANY as well as
other elements of the protocol I am also inclined to demand a better
rationale before accepting a document's proposal.

But yes, I do think standards actions in response to local problems can at
times be the right thing to do, if we value innovation.  I'll note that
Paul Vixie has talked about cost shifting in the past.  Saying one is
innovating isn't license to shift costs without good reason or warning
or acceptance or ...  innovation doesn't remove the need to say I'm
sorry. ;)


smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[Edward Lewis]

On 3/11/15, 16:52, Tony Finch d...@dotat.at wrote:

Edward Lewis edward.le...@icann.org wrote:

 Note that my request was not for a means to update the parent but to
 prevent the child from shooting themselves in the foot.  A much less
 involved operation.

In this immediate case the problem was caused by a change of operator for
the zone, and the registrar(s) failed to handle DNSSEC properly as part of
the transfer.

The case you are describing is different from what I have been writing
about.  Different, just as important to solve.  (This is why discussing
these in a public forum is good - it would be unwise to solve only what I
had in mind.)

I think this is a simpler situation to deal with than a botched key
rollover, assuming registrars can be persuaded to add the necessary sanity
checks to their processes. This doesn't have to be anything ambitious like
fully secure domain transfers: either stop the transfer or ask the
registrant to make the domain insecure if the nameservers are changed and
the new ones do not have a properly signed zone.

I disagree that is is simpler, starting from stating that assuming
registrars can be persuaded.  Persuading registrars to take any steps on
the grounds that the steps would improve technology has proven to be
somewhere between impossible to it happened once.  I want to avoid
besmirching registrars but they are not rewarded by being superior in
technology.  I am not saying that registrars can't listen to reason, but
history has shown that they do not take on cost willingly.

In a world where a customer (retail enterprise for example) makes a choice
for a domain name registrar and a separate choice for DNS hosting, the
dynamics are that the customer had to smartly manage having someone that
will handle registration of a name and someone that runs the technical
function of the DNS.  Smartly manage meaning they have to watch both and
have to act as a go-between.

In the short term, changes to the status quo will only happen from the
side of the DNS operator.  That's where the pain is felt.  Expecting
change from any other element of the ecosystem is not going to pay off,
partly because the DNS operator has the most to gain from changes (lowered
costs, increased opportunity to add value added features).  DNS operators
rely on tools, which is why I've been trying to press for better tooling.

I expect DNS operator have to describe what is needed in the way of tool
improvements in a manner that tool developers can understand and build
(hopefully multiple, interoperable) tools to meet.  This is kind of what
the IETF has promised to be.  What the IETF helps with is the Note Well
and wider review, but the IETF requires the participants to expend the
energy, it doesn't do the work.

So, back to this.  The new operator is the one that is going to have to
red flag the situation.  I've seen abuses of when glue records are
forgotten at a registry - stale glue doesn't stop operation but I've seen
a live example of how it can be used to disrupt an (evidently)
ex-employer's systems.  While the registration transfer is one process
where this check could happen, that would be a needed change and it isn't
clear to me whether the a change in DNS operator is visible to the
process.

(There has been some related work in this space - I haven't been following
this closely in the last year plus:
https://tools.ietf.org/html/draft-ietf-eppext-keyrelay-01.)


smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[Edward Lewis]

On 3/11/15, 14:19, Doug Barton do...@dougbarton.us wrote:

I think it would be Ok to put up a large, difficult to ignore warning
that the user is about to do something painfully stupid, sure. How much
farther than that to go is an exercise for the implementors.

To go a little deeper into what I witnessed up close.

Had we had the option of having the server log a problem or even launch an
email, we could have handled the configuration.

After the post-mortem I was talking to a colleague who said he too had
requested a safety breaking system from some tool makers and was laughed
off.  Take what I am saying here as umpteenth-hand retelling of a fib
because we never bothered to make the same request, we just rolled our own
script (because we had the staff available to do this, although they
weren't ordinarily dedicated to this function).

And the issue of non-BIND authoritative servers not doing their own
iterative queries is a red herring. I would be astonished if those
systems were not on a host that had access to a resolver.

It's not a question if this can be done.  It's a question of how can this
be packaged for operations.

To sum up something - one thing I learned during my stints in operations -
many of the assumptions held by protocol engineers and architects about
how a protocol is put to work are far from reality.  (Not that the
engineers and architects are wrong in their approach but the assumptions
are wrong.)  I don't mean that operators are using bailing wire and duct
tape to reap huge profits, but the approach to sound operational practices
sometimes runs counter to what I learned to be sound in the lab.


smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[Edward Lewis]

 On Mar 11, 2015, at 16:18, Rob Foehl r...@loonybin.net wrote:

 What about the case of bad data in the parent, regardless of where it lands 
 on the malice / stupidity scale?  Loud warnings to this effect at zone 
 (re)load time would be one thing, but refusing to load the zone entirely 
 would mean the broken DS isn't the only operational problem...
 
 -Rob

In this case it isn't that the operating state is broken, it is that the next 
state is. So failing the operation is a good thing. 

I'm not talking about hypothetical failure modes but modes that have been 
observed in TLDs and below. 

To be fine grained, this is a mater for key management and not zone management. 
 Our problem arose in part because we used a tool that combined key management 
and zone serving. It did its job, we didn't do ours. Wished the automated 
system would have saved us. 
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[Edward Lewis]

On 3/10/15, 16:45, Mark Andrews ma...@isc.org wrote:

Why don't we just implement TSIG signed updates...

In the sense of baby steps first - what I'm driving towards error
detection, ensuring that the zone-to-be is in line with it's environment.
 Getting to error correction is the next level, but complicates things.

 
 Here are some impediments:
 
 1) The entity responsible for the set up is not likely to be a
programmer.

Doesn't matter. People do username/password pairs all the time.

The point was missed - the solution to this has to rely on updating tools,
not expecting folks to modify code, write a few scripts, set up cron jobs.
 As someone familiar with coding, I could write this up for myself, but in
general operations staff aren't going to develop anything very detailed.

 2) Authoritative servers don't launch queries.

Has NEVER been true.  SOA/IXFR queries are done regularly by
authoritative servers.  For over the last decade queries for
nameserver addresses have been done for NOTIFY.

Okay, but, the queries are sent to IP addresses held in configurations or
in authoritative data, not relying on what is learned at sea.  They
certainly don't iterate.

I could quibble and say that messages sent by AXFR clients (RFC 5936),
which are called queries, aren't exactly the same as queries sent when
resolving a name - they share format and software but the trust model is
different.  And that matters here because I've held the belief that
authoritative servers do not want to base their answers (authoritative
answers) on information learned from outside their bailiwick.

 3) Authoritative servers don't know anything about the parent zone.

Discoverable.

True, unless (as mentioned later) the master is firewalled off from the
Internet (okay, lame argument).  Yet we don't have tools that do this.
Why not?

 4) The owners of the zone and the operator of the DNS are not always the
 same entity (person, company).

Doesn't matter.

(I don't know what you mean by doesn't matter other than you are
disagreeing.)

I raised this impediment to try to point the solution into tools (and
standards) and not relying on processes.  The world we live in has managed
to build business relationships that do not align with the needed
communications to make things work smoothly.  (This is why I called DNSSEC
clumsy at a Centr meeting in October 2013 - clumsy as in, it can be made
to work but needs more expertise than is evidently available in the labor
market.  Evident by the frequency of defects.)

I've already submitted a draft that would make this all possible.

Sending signed UPDATE messages is relatively trivial.

Which one?  Is there an implementation of this?  Any operational
experience?


smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Saga of HBONow DNSSEC Failure

[Edward Lewis]

On 3/9/15, 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).

When this first surface after the infamous NASA.GOV incident, I sent a
private apology because I (as well as others) knew this day would come -
when an ISP would get the brunt of someone's DNSSEC misfire.  (Others
include many who worked on the original design and deployment workshops.)

This time I'll offer a public apology.  Sorry, Comcast.

The only way I can make this up to you is to better my efforts at making
DNSSEC an easier to run, less clumsy protocol.  The protocol is what it is
- when something doesn't check out, it goes dark.  The mitigation is
better tools to explain this and to manage this.  The negative trust
anchor draft addresses the latter.

Oh, and, Jason, a squirrel has managed to chew through my mom's cable, can
you fix that for me?  Perhaps Comcast could install little squirrel
feeders in the neighborhood.


smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[Edward Lewis]

...to prevent another DS--DNSKEY mishap from happening again?

I'm presenting the message to the DNS Operations list of DNS-OARC.  (Being
subscribed to so many DNS lists I keep forgetting if I'm acting as an IETF
participant or talking as a past operator of DNS or as )

In short, think about when a name server loads a zone with a DNSKEY set in
it.  If, at the parent zone, there is a DS set and none of it's contents
refer to a record in the DNSKEY set, all DNSSEC validating queries will
declare everything in the zone broken.

So, why can't the name server find the DS set, run a check and barf if
there's a problem?  Barf - either refusing to load the zone or refusing to
change the zone that is already running.

Here are some impediments:

1) The entity responsible for the set up is not likely to be a programmer.
2) Authoritative servers don't launch queries.
3) Authoritative servers don't know anything about the parent zone.
4) The owners of the zone and the operator of the DNS are not always the
same entity (person, company).

#1 - The implications of this is - tools/components are needed.  One option
are management/diagnostic tools.  Another option is an embedded in the name
server component.  More tools is great when you are the jockey, more
embedded components is great when you are the customer.

#2 - Software can do what it wants - but sometimes hidden masters are
shielded with the public Internet.  (I'll assume the case is that the parent
and child zones are on separate sets of machines - when this is't true, we
don't have the problem.)  I bet though, that it wouldn't be hard to convince
the operators of hidden masters to allow them access port 53 outside the
firewall.

#3 - There's a brute force way to overcome this, come down the root to find
the cut point.  Or this can be configured somehow (but I hate pinning).  Or
maybe just doing a straight forward use of a validating recursive server
(but that's more tools, see #1).

#4 - This is a critical aspect of the problem.  Even if the customer tells
the DNS hosting company to roll keys, the customer has to be the one who
finds the registrar to ensure the DS set is correct in the registry.  That's
four participants with the most important (customer) the least capable (or
they probably wouldn't be a customer).  Failing to automate away the
customer's problem will kill the effort, certainly stall scaling.

The first step is for the operations community to cobble together a solution
to this problem.  Perhaps a proposal goes to the IETF for the proper review
and legal protection.  And if there's a need to change other policies, an
IETF document might be the greatest asset.

This is one way to make DNSSEC less clumsy.

Please - if there are more impediments, suggest them.  I may have missed
something.  If you disagree with an impediment, speak out.





smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] CloudFlare policy on ANY records changing

[Edward Lewis]

On 3/6/15, 10:05, Olafur Gudmundsson o...@ogud.com wrote:

 
 We will be depreciating support for ANY queries and return NOTIMP in the near
 future 
 https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/
 
 ID proposing this behavior will be forthcoming

I simultaneoulsy requested on on DNSOP. ;)




smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

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

[Edward Lewis]

On 1/27/15, 5:46, bert hubert bert.hub...@netherlabs.nl wrote:

Can you name me one client side application that benefits from anything
other than the answer section?

This may have been meant as a rhetorical question, but it’s pretty
interesting.

I’ve thought much over the years about a way to mathematically reduce the
DNS protocol into a state machine.  Yeah, I know you’ve heard that joke
before.  The protocol definition stated out life with a few too many
exceptional cases and over the next decades suffered a few fractures,
etc., preventing the derivation of a useable state machine.  By usable, I
mean one that can easily be documented, worked with, and explained.  The
DNS today can be described as a state machine, but describing it would be
no simpler than reading all of the lines of code in all of the
implementations in play.  (Like saying my collection of sea shells is so
large, I’ve scattered them along all of the beaches of the world.)

But for this, first, I would like to believe that applications need not
see anything that is not in the Answer Section.  (If so, DNS protocol
engineers could muck all day with the header and other sections.)  Besides
the protocol-archeological evidence that port 25 (SMTP) and port 53 are
cousins (referring to the inclusion of address records, when available, in
the Additional Section if a a mail exchanger record is in the Answer
Section) there is very little to suggest than any other application “got
it’s hooks into” the DNS protocol.  I say this having been through
discussions to break that statement.

There’s one other hook where applications use information outside the
Answer Section and that is negative answers.  The reason is that in a
negative answer, there may be an empty Answer Section (think CNAME as
counter example) with either a name error in the rcode field and maybe a
start of authority record in the Authority section.  Applications may not
necessarily care about the timing parameters (TTL) - but in the sense of
the question above, I would say that applications might use more detailed
failure information.

Ideally, though, all an application would need should be confined to the
Answer Section.  The rest is for the benefit of the DNS system itself.
(DNSSEC was designed to be consumed within the DNS system, I won’t debate
whether applications should try to be aware of it.  I know there is stated
interest that applications be aware of DNSSEC, I’m avoiding that here.)

It will still be digging through caches and creating larger packets
though.

My initial reaction - extraneous data has proven to be weaponry in traffic
flooding attack mechanisms.  (Including the upward referrals that became
to signal lame delegations.)

Don Quixote


smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] knot-dns

[Edward Lewis]

On 12/15/14, 14:40, someone wrote:

My point is that the negatives far outweigh the benefits in most
organizations.

The problem with broad generalizations is that they are always wrong.

(Meant as a joke.)

I skimmed this thread now and then and thought about my experience in
building and operating systems.  Ever since “The Cuckoo’s Egg” - as far as
I know - “genetic code diversity” has been a fad.  It got woven into a lot
of requirements.  Having spent a long time inside operators, I’ve seen
this become more of an albatross than a “good idea.

If I am operating a system supporting external customers, homogeneity is a
benefit.

If I am operating a system for my own benefit, heterogeneity is a benefit.

My recommendation for a service provider stick with one code base and
learn to run it well.  My recommendation for a customer of such a provider
use two or more service providers.



smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

[dns-operations] Wither to revive SIG(AXFR) was Re: cool idea regarding root zone inviolability

[Edward Lewis]

Caution - Basic engineering rationale philosophy argument herein.  (I.e.,
barely worth the stamp I put on the letter.)

On 11/27/14, 20:04, George Michaelson g...@apnic.net wrote:

I'd struggle to say that was a bad idea.

It isn’t just “good” or “bad” idea that needs judging, but, is it worth
doing?  For what you get, there are alternate means.  And given that tool
implementers (referring to Mark’s comment about BIND) are adding
protections beyond this this may be a better idea in theory than in
practice.  (Operative word - “may be”.  Okay, operative two words.)

The history only informs the present, it doesn't have to determine it.
The statement about 'learning from history, doomed to repeat it' is not
meant to say you cannot re-try things previously considered and rejected.
It means you need to be aware of them.

Cautionary tale – my initial message on this was just a data point, not a
forensic examination.  All it I said “we tried it, we didn’t like it”
mostly to prompt anyone else with a memory to see if they could recall
why.  On face, trying it and not liking it isn’t killer, just experience.


smime.p7s
Description: S/MIME cryptographic signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Introducing CNAME Flattening: RFC-Compliant CNAMEs at a Domain's Root

[Edward Lewis]

From: dns-operations-boun...@mail.dns-oarc.net ...
Sent: Friday, April 04, 2014 5:20 AM
To: dns-operati...@dns-oarc.net
Subject: [dns-operations] Introducing CNAME Flattening: RFC-Compliant CNAMEs   
 at a Domain's Root

http://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root

Funny idea but ...

I disagree with the assessment of the idea as being funny.

Marketing messaging fllter on (meaning, forget unsubstantiated claims, who was 
first, is this novel, how well it works), there's a very real need (a market 
demand) for the feature described.

Here's the use case.

As an owner of an enterprise and either having or building a trademark/word 
mark and a reputation I want to:
1) Buy a simple, short, catchy domain name
2) Publish the name in print, business cards, perhaps in audio/video ads that 
are not click-through, use it over the (voice) phone
3) Host content with a large scale cloud - if you will provider who in turn 
manages demand by periodically switching IP addresses.
 
I.e., the owner wants to have someone go to http://example.com; but can't have 
a persistent address.

One other factor, the enterprise owner may elect to have DNS hosted on a DNS 
provider and use a different vendor for hosting services.  And the enterprise 
owner might elect to have  CTO but not a VP of engineering, which influences 
what is out-sourced and what they can do themselves.

This is where the market has been for a couple of years now.

As far as solving this, since the direct solution isn't available (CNAME at 
apex), you have to make trade-offs which wind up approximating a perfect 
solution.  There are a number of options open, each with benefit and with 
drawbacks.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Introducing CNAME Flattening: RFC-Compliant CNAMEs at a Domain's Root

[Edward Lewis]

This all smells like something that the IETF is suited to help with.  I mean, 
operators, multiple implementations, desires for interoperability...

(Jus'sayin')


From: dns-operations-boun...@mail.dns-oarc.net 
[dns-operations-boun...@mail.dns-oarc.net] On Behalf Of David C Lawrence 
[t...@akamai.com]
Sent: Friday, April 04, 2014 11:34 AM
To: dns-operati...@mail.dns-oarc.net
Subject: Re: [dns-operations] Introducing CNAME Flattening: RFC-Compliant 
CNAMEs at a Domain's Root

Anthony Eden writes:
 Ah, I didn't know that. Have you or others from Akamai ever written up
 anything about your implementation?

I doubt anything publicly, though we do have internal documentation.
There might have been a non-technical press release back in 2003, but
this routine of writing semi-technical blog posts really wasn't as
much of a thing back then.
___
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] algorithm rollover strategies

[Edward Lewis]

On Nov 27, 2013, at 4:46, Peter Palfrader wrote:
 
 Are there any guesstimates or even hard data what percentage of
 resolvers, if any, will consider zones bogus if the algorithm rollover
 is handled in the more liberal style as a regular double-signature KSK
 rollover?


This is a good question, one that I am dealing with myself.

Ironically, in private email yesterday I sent this to someone who was involved 
when the rules that have caused the problem were written.  In the sense the 
horse has left the barn already, but:

From the end of section 2.2 in RFC 4035:

There MUST be an RRSIG for each RRset using at least one DNSKEY of
each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
itself MUST be signed by each algorithm appearing in the DS RRset
located at the delegating parent (if any).
It should be:

There MUST be an RRSIG for each RRset using at least one DNSKEY of
each algorithm in the zone apex DNSKEY RRset that is also in the DS RRset.  The 
apex DNSKEY RRset
itself MUST be signed by each algorithm appearing in the DS RRset
located at the delegating parent (if any).
The latter is what I thought had been written until I re-read the section a few 
weeks ago.

It's too late to go back and change implementations that interpreted even the 
as-is text incorrectly.  By wrong I mean interpretations of the rule that 
were not in line with the apparently incompletely stated intent of the rule 
writers.  In the rear view mirror I can see how a validator might take the 
above as a requirement, but it means that they didn't notice that section 2 was 
zone signing and 2.2 was in including RRSIGs in a zone and not in sections 
4 or 5 (resolving and validating).

The same argument has been made about the confusion over the definition of a 
domain name in STD 13 and host name in RFC 1123.  Context matters.

So - I wish we could measure the impact of what has been deployed.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis 
NeuStarYou can leave a voice message at +1-571-434-5468

Why is it that people who fear government monitoring of social media are
surprised to learn that I avoid contributing to social media?

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

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

[Edward Lewis]

My excuse is - operators limit the effort expended in fighting entropy.  
Imagine an average operations environment operating as most environments go.

One admin comes in a decides they can do a better job.  And the admin does, 
stellar talent.

Then the said stellar admin decides to move on career-wise (naturally) and is 
replaced by a less attentive (or differently attentive) admin, i.e., someone 
who's knowledge of DNS comes only from a paper book.

Eventually one day something breaks and then...  ...include here the only 
one who can fix it has left.

I mention this because I think that is more relevant than:

On Nov 26, 2013, at 21:46, Joe Abley wrote:

 The root nameservers are administered by people who have incentives to do a 
 good job. Resolvers set up by some random admin one rainy Thursday afternoon 
 to transfer the root zone from some place or places that happen to work that 
 day constitute an unmaintained critical service, and end-users will pay for 
 it when it stops working and nobody can figure out what it is supposed to be 
 doing.

I'd argue that the resolver admin is also incentivized to do a good or better 
job too.  Joe's right in general, but it's not that the admins are lazy 
(putting words in his mouth) - it's the energetic ones that can/may prove to be 
the root cause some day.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis 
NeuStarYou can leave a voice message at +1-571-434-5468

Why is it that people who fear government monitoring of social media are
surprised to learn that I avoid contributing to social media?

___
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] Opinions sought .... have I come to the right place?

[Edward Lewis]

On Nov 7, 2013, at 10:18, Wiley, Glen wrote:

 Be careful about conclusions you may draw from your data.  


That's a good point and that is why I am asking.  Data is just an indication 
of observations and nothing without outside interpretations.  

On Nov 7, 2013, at 10:24, Jelte Jansen wrote:

 On 11/07/2013 03:52 PM, Edward Lewis wrote:

 ...which would give you only the drawbacks and not the upside...

Fully aware that recursive servers are optimizing for their experience but that 
comes at the cost of predictability.  That sounds like a negative statement but 
it isn't meant to be.  The 'local' optimizations at caches are fine, they just 
make it harder for an authoritative server operator to know what to do.

And, to hark back to the first comment, they jumble up the data, making the 
data something less than an oracle of truth.


 thought), but I do have one immediate question: Did you see specific
 points at which TTLs are no longer adhered to? (e.h. do resolvers out
 there cap TTL values and if so, do they set it to said cap or reduce it
 to a fixed value, or does it appear completely random)?

I am aware that I haven't done that look.  Meaning, it's crossed my mind, I 
haven't gone back to the data though.

I can say though that there's a lot of crud in the data.  E.g., in the top 10 
hitters (meaning IP addresses that sent the most queries), some are mail 
forwarders, some are recursive servers, and some are simply monitors in labs 
measuring the Internet.  (The number 10 hitter is just that, it request the 
same set at a consistent number every day, amounting to a measurable percentage 
of the traffic.  I know the operator and we've talked about this, it's no 
mistake.  Ironically, those just measuring the Internet are also growing it 
just by measuring!)

I mention that because it's an excuse for me not to try to find other 
identifiable patterns.  E.g., it's been said one tool caps (by default) TTL to 
1 day and it would be tempting to look for that tool's use.  But it's drowned 
out by a whole gaggle of unidentifiable patterns.  So it's not like I'm just 
lazy... ;)

 TBH I don't think it's very important to the pre-fetch discussion
 itself; 

I'm citing that work as just an example of what makes it harder to optimize 
the authoritative side.  Above I've referred to it as a 'local optimization' 
and that shouldn't be taken as an insult.  But it is true it's local, and 
even so beneficial.  It adds to the fact that there's never been a reliable 
characterization of how the non-authoritative servers operate.  Like - the 
retry strategies that caused Rollover and Die situations (NANOG presentation 
in Jan 2010 or so).

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis 
NeuStarYou can leave a voice message at +1-571-434-5468

Why is it that people who fear government monitoring of social media are
surprised to learn that I avoid contributing to social media?

___
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

[Edward Lewis]

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.

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

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

[Edward Lewis]

On Oct 21, 2013, at 14:32, someone wrote:

 But who cares who got there first?  Every request
 I see for credit is recorded in my private accounting as a debit against
 the credibility of the person demanding credit, because credit demands
 suggest interests which suggest biases and so inaccuracy.



What drives the value downward of mailing lists are discussions like this.

One of the failings of the field of DNS is that there's no small set of 
libraries of documents.  As a result, most participants never do the 
literature search phase of research, instead they just go to code.  I'd call 
that experimenting, not researching.  Given the environment, crediting work to 
someone is almost impossible. But that is not something new and unique to the 
DNS or even the Internet.  Most inventions over time were just incremental 
changes to known technology but for some reason, on increment was more valuable 
than all the previous.  E.g., what Edison got right was the color of light, not 
the idea of radiating light from a wire.

As far as what Kaminsky contributed, in my estimation, the novelty was in the 
forging of UDP's sender address and flooding to perform cache poisoning.  
(Cache poisoning itself had been described in the 1990's, which is why there 
was a DARPA contract to develop DNSSEC from 1994 to 1998 or so.)  The DNSSEC 
development flotilla had long been considering how to defeat message 
insertions, that mechanism was not novel in Kaminsky's description.  His major 
contributions were first exposing how to perform an insertion attack when not 
on the path and secondly he visualized the consequences to people.

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

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

[Edward Lewis]

On Oct 21, 2013, at 11:54, Keith Mitchell wrote:
 
 Then ISC/BIND response to Kaminsky in 2008 was to burn perhaps 50% of
 the company's product-wide development and support resources over that
 year to co-ordinating, fixing, disclosing, patching, releasing and
 evangelizing the solution to the problem. While at the time it felt to
 us like great public benefit work was being done for the community, even
 by the end of that year it was becoming clear it was not a particularly
 great business decision.


Over the weekend there was a CENTR Technical Workshop (the day before RIPE 67 
and in the same location) where a panel was held on the recent DNS 
vulnerabilities as reported at DNS-OARC 7 days earlier.  One of the thoughts 
that emerged (IMHO) was to set priorities like this: design-away the 
theoretic/academic described vulnerabilities, reserving trench-warfare 
techniques to battle attacks we learn from packet captures.  Given limited 
resources, that is how I'd spend them.

So, yes, I believe this - in retrospect (referring to Keith's report) a lot of 
resources were burned to stem an attack that never really materialized.  
Possibly because of the fix, but we will never know.

Oddly, during the CENTR meeting and during the RIPE DNS WG meeting that 
followed, the quote in the long run we are all dead [0] was uttered 
independently (different speakers) to mean that it's fine to design into the 
future, but we need to eat now.  Under that banner, RRL serves an important 
purpose by staving off the apocalypse, even if (and I do mean if) it's benefit 
is temporary.

This assumes that there is someone designing away vulnerabilities into the 
future, which I fear is a bad assumption currently.  Most delivered techniques 
are triage with anything requiring major architectural rework considered to be 
too far off into the future to even being.  I don't think DNSSEC would stand 
a chance starting from scratch today, given how avenues of innovation have 
changed.

[0] 
http://en.wikipedia.org/wiki/In_the_long_run_we_are_all_dead#Macroeconomic_usages

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

Re: [dns-operations] Alert: Massive increase in type A6 queries.

[Edward Lewis]

On Oct 16, 2013, at 11:43, Roy Arends wrote:

 Hi,
 
 Since october the 12th, 2013, starting at approximately 16:00 UTC, we see a 
 massive increase in type A6 queries. This is not due to a single resolver, 
 but due to several resolver exhibiting the same behaviour. We're 
 investigating, but want to alert the TLD community while asking for help as 
 well: If anyone has more info, it would be greatly appreciated.


For those that don't recall what an A6 is (and why it was effectively killed in 
Aug 2001), the A6 was thought to be an enhanced  record.  The down side was 
that A6 records required intermediate name servers to search for parts of the 
IPv6 address and assemble the various fragments they'd be getting.

Perhaps someone is testing to see if A6 is a way to eat name server (cpu) 
resources.  That's just a shot in the dark.  And likely a poor one.

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

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

[Edward Lewis]

Unless the company's line of business makes running a recursive server a core 
competency:

+1,  see http://en.wikipedia.org/wiki/Comparative_advantage for a basis for my 
reasoning.

Did the company build their offices, manufacture their furniture, pave and 
reseal their parking lot? (I ask rhetorically/sarcastically.)

On Oct 14, 2013, at 19:54, Jared Mauch wrote:

 I'll say no. They don't have resources to deal with 98 angry users when DNS 
 fails. Using OpenDNS or the ISP is likely the best choice. Most large ISP dns 
 servers are good. 
 
 Jared Mauch
 
 On Oct 14, 2013, at 7:08 PM, Paul Hoffman paul.hoff...@vpnc.org wrote:
 
 A fictitious 100-person company has an IT staff of 2 who have average IT 
 talents. They run some local servers, and they have adequate connectivity 
 for the company's offices through an average large ISP.
 
 Should that company run its own recursive resolver for its employees, or 
 should it continue to rely on its ISP?
 
 --Paul Hoffman
 ___
 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

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

[dns-operations] DNSSEC and Re: DNS Attack over UDP fragmentation

[Edward Lewis]

 On Thu, Sep 05, 2013 at 02:54:18PM -0700,
 Paul Vixie p...@redbarn.org wrote the part i do not understand this 
 statement.:
 
 Florian Weimer wrote:
 
 Because DNSSEC does not prevent cache poisoning, it only detects it.
 
 i do not understand this statement.
 

On Sep 6, 2013, at 3:49, Stephane Bortzmeyer wrote in response to that exchange:

 The way I understand it: with Kaminsky and/or Shulman, you can still
 poison a DNS cache. The downstream validating resolver will detect it
 and send back SERVFAIL to the end user. But this end user won't be
 able to connect to his/her bank.

You don't need Kaminsky- or Shulman-described attacks to 'poison' a cache, you 
just need to create an acceptable response message.  There are other ways to do 
that.

 So, DNSSEC turned the poisoning attack from a hijacking attack to a
 DoS.

The above has a few non-sequiters.  First, yes, the cache poisoning is 
prevented, after it is detected.  What you are complaining though is that this 
means the end user is blocked from reaching the desired service - as a result 
of the poisoning being thwarted.

The comparison you should be making is not between user gets to service versus 
user is blocked by DNSSEC from accessing service but rather user is 
misdirected to malicious harbor versus user is blocked from accessing the 
malicious server.  Yes, the latter is lose-lose because we are assuming this 
choice is being made during the duress of an attack.

It's not DNSSEC's fault that the user can't get through, it' the attack's 
fault.  DNSSEC's job is first to protect the cache from having falsified data, 
not to protect the user.  The result is to keep users from the bad sites they 
would have accessed if the cache were poisoned.

Note - DNSSEC does not address 'correctness' - which is at the heart of many 
problems today.  If the provisioning interface security is subverted, incorrect 
data can get into the DNS, be armored by DNSSEC and result in caches holding 
incorrect data.  DNSSEC's role is only to make this event more transparent - 
that the fault lay upstream - DNSSEC is not in any way going to defend 
against this class of failure.

 Now, the question is: for an attacker, is it the simplest way to do a
 DoS? IMHO, no, so I'm not too worried about it and I still believe in
 DNSSEC.


DoS and DDoS are not the only forms of attack seen in the wild. (D)Dos is 
usually not the goal but the means to an end, such as a political statement.

What has gone wrong in our plan to save the Internet(TM) is that DNSSEC's armor 
against cache poisoning has being used as malicious payload in DDoS attacks via 
reflections.  But because the 'baddies are after more than DDoS, we can't just 
drop DNSSEC and be better off.  (Cur reference to talks at CENTR, DNS-OARC ... 
yadda, yadda, yadda...for further elaboration.)

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

Re: [dns-operations] Implementation of negative trust anchors?

[Edward Lewis]

 I don't think this is about a free choice, but adhering to the protocol.


At this point, I'm not sure who is saying what and what is inferred in the 
quips, but if you adhere to the protocol, you place free choice first.

This is not just from my dimming memory of the 1990's when we developed the 
concept, we even wrote this into the latest rendition of the DNSSEC 
specifications (albeit in 2004).

RFC 4033:
   ...In the final
   analysis, however, authenticating both DNS keys and data is a matter
   of local policy, which may extend or even override the protocol
   extensions defined in this document set.  See Section 5 for further
   discussion.

And this predicts NTA's (also in RFC 4033):

   Insecure: The validating resolver has a trust anchor, a chain of
  trust, and, at some delegation point, signed proof of the
  non-existence of a DS record.  This indicates that subsequent
  branches in the tree are provably insecure.  A validating resolver
  may have a local policy to mark parts of the domain space as
  insecure.
I emphasize the last sentence:

A validating resolver may have a local policy to mark parts of the domain space 
as insecure.
And I'll add in a cranky manner, the overall tenor of this list insinuating 
that operators are incompetent and should therefor not be given free will needs 
to be seriously reconsidered.  Perhaps I need to quite Star Wars to get the 
point across:

Princess Leia: The more you tighten your grip, Tarkin, the more star systems 
will slip through your fingers.

Ecologies that place heavy emphasis on security have been empirically proven 
to fail at scale (population and/or time).
 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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

Re: [dns-operations] Implementation of negative trust anchors?

[Edward Lewis]

(Just using this to launch into a tirade.)

On Aug 22, 2013, at 15:59, wbr...@e1b.org wbr...@e1b.org wrote:
 Running the DNS for 100+ school districts and 400,000+ devices I really, 
 REALLY don't want to be the one saying Sorry, you can't use the site 
 called for in your lesson plan today because they messed up the DNSSEC 
 records.  Management's response would be Just make it work!


One thing that seems to need repeating from time to time is this passage in RFC 
4033.

   ...  In the final
   analysis, however, authenticating both DNS keys and data is a matter
   of local policy, which may extend or even override the protocol
   extensions defined in this document set.  See Section 5 for further
   discussion.

A responsibility (one of many) of a caching server operator is to protect the 
integrity of the cache.  DNSSEC is just a tool to help accomplish that.  It 
carries ancillary data that a local cache administrator may use to filter out 
undesired responses.  DNSSEC is not an enforcement mechanism, it's a resource.

When I see folks voice opinions that DNSSEC's recommended operation has to 
strictly followed, my gut reaction is that these folks have forgotten the 
purpose of all of our efforts.  We don't secure protocols to make things work 
better.  We don't operate the DNS because we like to run a well run machine.  
We don't run the Internet for the fun of it.  (Some might enjoy running it, 
that's job satisfaction to some extent.)

At the end of the day all that matters is that what is being done benefits 
society.  We run the Internet to enrich society.  We prefer a well run DNS 
because it saps less resources than a poorly run DNS.  We prefer secure 
protocols so that people don't become victims (in some sense of the word).

Make it work.  Do what it takes to make it work.  Local policy rules.

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

Re: [dns-operations] Discarding bad records from an AXFR

[Edward Lewis]

On Jul 30, 2013, at 16:55, Anand Buddhdev wrote:
 
 What do you all think is the correct behaviour? Or are both correct?


There's some unwritten history here.

First, these aren't bad records in the sense that they are malformed (at 
least I think this is what you are talking about).  I.e., no 128 bit A records. 
;)  The word we have used in talking about these is occluded like when the 
moon passes in front of the sun.  These are records that might have once been 
in zone but then a delegation point is added and they fall below the cut.

From words I recall hearing from Mark Andrews, BIND took this path because 
sometimes people make mistakes.  An operator of a complex zone might add an NS 
record that occludes many lower names.  Then they undo the work.  If the 
occluded records have been expunged from the AXFR's, they need to be 
re-inserted.  Mark chose to leave them there and let the algorithm of DNS 
take care of the occlusion.

I've sided our implementation with that view, retaining occluded records.

Correct - that doesn't matter so much as interoperable - and in this case, 
what's more useful to an operator.  (MTTR is an operational consideration, not 
a protocol engineering one.)

PS - I then thought to check the RFC's. This says BIND is right.  
(Self-fulfilling though, we wrote it that way because of Mark's reasoning.)

RFC 5936DNS Zone Transfer Protocol (AXFR)  June 2010
3.5.  Occluded Names

   Dynamic Update [RFC2136] operations, and in particular their
   interaction with DNAME [RFC2672], can have a side effect of occluding
   names in a zone.  The addition of a delegation point via dynamic
   update will render all subordinate domain names to be in a limbo,
   still part of the zone but not available to the lookup process.  The
   addition of a DNAME resource record has the same impact.  The
   subordinate names are said to be occluded.

   Occluded names MUST be included in AXFR responses.  An AXFR client
   MUST be able to identify and handle occluded names.  The rationale
   for this action is based on a speedy recovery if the dynamic update
   operation was in error and is to be undone.

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

Re: [dns-operations] Clear DNS cache

[Edward Lewis]

On Jun 20, 2013, at 10:08, abang wrote:

 Am 20.06.2013 15:29, schrieb Vernon Schryver:
Quoting an earlier message:
 ..It seems your nameservers don't agree on the SOA serial number!...
 
 I wouldn't put too much stock in what http://viewdns.info/ says
 about anything...
 
 Yes of course. But in this case it is true.
 
 $ dig +short @ns1.linkedin.com linkedin.com. soa
 ns1.linkedin.com. hostmaster.linkedin.com. 2013061316 3600 600 604800 60
 $ dig +short @ns1.p43.dynect.net. linkedin.com. soa
 ns1.p43.dynect.net. hostmaster.linkedin.com. 2013061801 3600 600 604800 60


Think about the role of the SOA serial number.  It is used to manage the way 
AXFR (and Notify/IXFR) work.  We also know that AXFR is not the only way to 
move a zone between authoritative servers, for example, rsync of files.  So, 
the significance of the serial number is limited to situations that are relying 
on AXFR, and in other cases, the serial number may be interesting, but not 
important to proper protocol operation.

E.g., a cache does not know the serial number corresponding to most of the 
answers in the cache.  (Most - thinking about the cached SOA's and other 
cases like that [NCACHE].)

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

Re: [dns-operations] DNS Issue

[Edward Lewis]

On Apr 26, 2013, at 8:24, Cihan SUBASI (GARANTI TEKNOLOJI) wrote:

 Hi,
 
 Also can someone explain why tcp53 should be allowed on the firewalls if dns 
 is behind a firewall?
 

In addition to other already posted reasons, TCP isn't susceptible to 
reflection attacks.  (FWIW.)

 And why auditors do not like tcp53 open to public?


Can't read their minds, but, well, the auditor has at least been misinformed on 
how DNS works.

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

[dns-operations] Who is xn--j1amh.? Well, the general problem...

[Edward Lewis]

One of the things I have some issues with is the introduction of a new TLD, 
especially one that is a so-called IDN name.

The delegation appears in the root and then later information appears in the 
IANA WhoIs.  In this case, there is something in the WhoIs, but nothing much 
useful.

In the spirit of contacting the source first I have.  This has happened a few 
times in the past and I've send a note to IANA about this.  What I'm doing here 
is asking if others have issues with this.

What I'd expect is that before a DNS delegation is put in place, the WhoIs is 
updated as well as any other source of info (the website, I know), and, most 
operationally, contact information!

PS - And, I would like to know who that string belongs to.

PPS - Here's my whois lookup at 9am (-0500) today.

$ whois -h whois.iana.org XN--J1AMH.
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object

domain:   укр
domain-ace:   XN--J1AMH

status:   ACTIVE

created:  2011-03-01
source:   IANA

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

Re: [dns-operations] Another whitepaper on DDOS

[Edward Lewis]

On Feb 22, 2013, at 23:18, David Conrad wrote:
 
 Has there been any documented attack that would have been prevented by DNSSEC 
 that one can point to?


Well, prevented...no, nothing can ever prevent an attack.

But I realized yesterday I should answer yes to the question of whether DNSSEC 
would have stemmed a cache poisoning attack - with a public reference.  

http://blog.neustar.biz/dns-matters/a-case-where-dnssec-would-help-part-1/
http://blog.neustar.biz/dns-matters/a-case-where-dnssec-would-help-part-2/

Here's the weird thing.  I wrote the above article.  I wasn't aware it was 
publicly visible until about a month ago.  I found it via a web search engine 
myself.

Second, the quick story behind this is that this indeed is a cache poisoning 
attack, but not as described by Dan Kaminsky.  That it was an attack 
nonetheless didn't occur to me until just this week.

Third - when I was presented with the problem and I learned a few crucial 
facts, the thought gee, I wish there was DNSSEC here' did cross my mind.  Not 
that the validation was needed, but had the data been signed I would have known 
where it was coming from.  (You'd have to read the article to understand the 
context.)

So, yes, finally I can say I've seen a case that's publicly documented - up to 
the point of providing anonymity to the victims involved.  (I'm still waiting 
for the first full disclosure case, but this is what I can offer for now.)

PS - As many of you know, I do not adhere to name and shame policy and take 
strides to protect identities when I present any sort of case study.  So, the 
anonymity I hope to be supplying here (I think I've left no breadcrumbs) is not 
only because it involves a customer but the data being poisoned is not mine nor 
is the cache being poisoned mine.  I just happened to look into the problem and 
turned the results over to the others.  Because of this, I realize, it's not 
possible to very my claims and that's a regret I'll take.  So - take this as 
you will.  And finally - the event happened last summer and was ongoing when I 
wrote the blog entry in the fall.  I don't know if it is still ongoing, I don't 
expect to hear back from anyone nor is it really my business to know.

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

Re: [dns-operations] RRL specified in a stable place?

[Edward Lewis]

Why an IETF document?  In what way does Response Rate Limiting impact 
interoperability of implementations?

If this is not an independent submission, how does it fit into a working group? 
 The implementations are pretty much out there, what's to work on?

I understand that would be useful is a reference-able document describing the 
RRL.  That is, something stable and reviewed - and that could be an RFC.   But 
an RFC does not have to come through the IETF.

On Feb 4, 2013, at 14:39, Andrew Sullivan wrote:
 On Mon, Feb 04, 2013 at 10:54:36AM -0800, Paul Hoffman wrote:
 We now have two implementation of response rate limiting (RRL). In order for 
 it to be widely adopted, an Internet-Draft followed by an RFC would be 
 Really Helpful.
 What track do you expect this to go along?  Is this a DNSOP draft?

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

[dns-operations] 10% was Re: .mm ....

[Edward Lewis]

It's an acceptable idea - certainly not a bad one.

Adding security to an existing system will, inherently, make it more brittle.  
What ever can be done to soften the brittleness while retaining the basic need 
for security should be done for the sake of resilience and availability of the 
system being secured.  (Security should never be the objective, it's a 
supporting actor in achieving a higher objective.)

The posed question is whether expanding the lifetime of a signature by 10% is 
a good idea.  All that can be objectively stated is that no cache poisoning 
enabled by this ploy has ever been detected.  That's why I said it is 
acceptable and not bad, I didn't say it was a good idea in the sense we will 
never know.

Data sets that validly fall into this 10% region may fall in to this state for 
reasons other than operator sloppiness, so the assertion that this encourages 
more sloppiness is not necessarily true.  What it might do (in the sense I have 
no data to tell) is reduce support call volume, which is a significant benefit.

From reading lists, talking to folks and watching operations, I have learned of 
more failed validations caused by hardware failures, disaster recovery mishaps 
and operational mistakes than other reasons, including operator sloppiness 
and malicious activity.  So trimming failed validations by removing brittleness 
is a good place to start.

I'll define sloppiness as failure to refresh signatures in time (or not 
automate that).  There are a lot of other things that can go wrong despite 
attentive care, including clocks drifting, external events overrunning planned 
capacity, and so on.

On Jan 18, 2013, at 10:06, Chris Thompson wrote:
 
 Is fudging the expiry times like that really a good idea? If all
 all validators allowed a 10% overrun, DNS operators would just
 get 10% sloppier and we would back where we started.

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

Re: [dns-operations] 10% was Re: .mm ....

[Edward Lewis]

On Jan 18, 2013, at 12:18, Dobbins, Roland wrote:

 
 On Jan 18, 2013, at 11:05 AM, Edward Lewis wrote:
 
 Adding security to an existing system will, inherently, make it more 
 brittle. 
 
 I strongly disagree with this statement.  Increasing resilience under duress 
 should be a key goal of any security enhancement; if it doesn't do this, then 
 it hasn't been designed/implemented properly.

(Perhaps the second half of the message should be first...meaning I think the 
issue is in what I meant by adding.)

This was the proof offered to me (about the impact of bolting-on/retrofitting - 
as I meant adding) years back:

Take an existing (vulnerable) system and model it as a state machine.  States 
can be classified as safe, perilous, and unsafe.  Perilous states are 
those which are safe but have an arc into an unsafe state.

The act of adding security on to the system has the effect or preventing the 
system from entering unsafe states and perilous states, in the effort to 
prevent falling into unsafe states.

What is lost then, is any transition from a safe to perilous to safe 
states which per se is not a problem but is no longer permitted.  This is the 
brittleness I refer to.

Looking back on this proof - I suppose if there were no safe-perilous-safe 
state transitions, there's no increase in brittleness.  KInd of a degenerate 
case in the proof.

 So trimming failed validations by removing brittleness is a good place to 
 start.
 
 I agree with this statement, and most everything else you say, 100%.  Perhaps 
 'adding security' wasn't really what you meant in the first sentence?

Adding security maybe the trip up.  Maybe I should have used the term I 
normally use bolted-on security.  When I wrote adding I had in mind the 
kind of addition like DNSSEC on DNS - which is a case of bolted-on security.  
It was a discussion over that where I was given the above proof.

Adding security as an ingredient in the initial architecting of a solution 
won't make the system more brittle.  (Well, if the solution is new - it can't 
be more anything. ;) )

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

[dns-operations] BIND 9.7 was Re: what nameserver software have you been using?

[Edward Lewis]

On Dec 14, 2012, at 10:23, Jan-Piet Mens wrote:
 Time to upgrade then: 9.7 is EOL since a few days ... ;-) [1]


I bet that the omission is just an oversight.  As far as I know 9.7 is still 
alive and kicking.  (And in one case I'm concerned with, works better than 9.9!)

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

Re: [dns-operations] email address in SOA

[Edward Lewis]

On Dec 10, 2012, at 9:46, Michele Neylon :: Blacknight wrote:

 If anyone has any actual evidence of SOA data being used for spam I'd love to 
 see it .. 

Reading this thread and replying in general, no one is claiming that the RNAME 
leads to spam, it's that one (one!) of the old spouse's tales is that it does 
thus raising the fear of putting real data there.

Much of what is now done operationally in DNS is rooted in folklore, rooted 
neither in real threats nor standards. ;)

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

[dns-operations] I know I'm a curmudgeon but

[Edward Lewis]

Running dig on a newly built Linux machine I see 
the below output (and man page explaining it).


To me this just seems wrong.  Mucking with the 
bare metal here is not desirable.  The zone *is* 
xn--xkc2al3hye2a., it is not 
the native script version (which is unprintable 
on the machine I'm on).


Comments?  Should DiG's output be unchanged or is 
this good?  Should the OS vendors be asked to 
stop this?


$ dig xn--xkc2al3hye2a. ns

;  DiG 
9.7.3-P3-RedHat-9.7.3-2.el6_1.P3.3 
 xn--xkc2al3hye2a. 
ns

;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: 
QUERY, status: NOERROR, 
id: 20823
;; flags: qr rd ra; 
QUERY: 1, ANSWER: 9, 
AUTHORITY: 0, 
ADDITIONAL: 0


;; QUESTION SECTION:
;á¾ôÕï».      IN   NS

;; ANSWER SECTION:
á¾ôÕï». 86400 IN   NS   ns-d.nic.lk.
á¾ôÕï». 86400 IN   NS   ns-l.nic.lk.
á¾ôÕï». 86400 IN   NS   ns-t.nic.lk.
á¾ôÕï».	86400	IN	NS 
	lk.communitydns.net.
á¾ôÕï».	86400	IN	NS 
	nic.lk-anycast.pch.net.

á¾ôÕï». 86400 IN   NS   ns1.ac.lk.
á¾ôÕï». 86400 IN   NS   ns3.ac.lk.
á¾ôÕï». 86400 IN   NS   ns-b.nic.lk.
á¾ôÕï». 86400 IN   NS   ns-c.nic.lk.

;; Query time: 281 msec
;; SERVER: 172.16.0.23#53(172.16.0.23)
;; WHEN: Mon Jul  9 15:33:27 2012
;; MSG SIZE  rcvd: 240

It's trying to be nice (from the man page):

IDN SUPPORT
   If dig has been built with IDN (internationalized domain name)
   support, it can accept and display non-ASCII domain names.  dig
   appropriately converts character encoding of domain name before
   sending a request to DNS server or displaying a reply from the
   server. If you´d like to turn off the IDN support for some reason,
   defines the IDN_DISABLE environment variable. The IDN support is
   disabled if the variable is set when dig runs.

I like the for some reason quip.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStarYou can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!
___
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] I know I'm a curmudgeon but

[Edward Lewis]

Weird...first private reply to me, someone says 
they can't see the message.  What I did was a cut 
and past from terminal in MacOS into the Eudora 
I've been using since just before it was 
discontinued.


Below, what I see makes it look like there's more 
than one layer of IDN messing with my mind.


At 11:39 -0400 7/9/12, Edward Lewis wrote:
Running dig on a newly built Linux machine I see 
the below output (and man page explaining it).


To me this just seems wrong.  Mucking with the 
bare metal here is not desirable.  The zone *is* 
x n - - x k c 2 a l 3 h y e 2 a . , it is not 
the native script version (which is unprintable 
on the machine I'm on).


Comments?  Should DiG's output be unchanged or 
is this good?  Should the OS vendors be asked 
to stop this?


$   d i g   x n - - x k c 2 a l 3 h y e 2 a .   n s
; D i G  9 . 7 . 3 - P 3 - R e d H a 
t - 9 . 7 . 3 - 2 . e l 6 _ 1 . P 3 . 3  
x n - - x k c 2 a l 3 h y e 2 a .  n s ; ;   g l 
o b a l   o p t i o n s :   + c m d ; ;   G o t 
a n s w e r : ; ;   -   H E A D E R   -   o 
p c o d e :  Q U E R Y ,   s t a t u s :   N O E 
R R O R ,  i d :   2 0 8 2 3 ; ;   f l a g s : 
q r   r d   r a ;  Q U E R Y :   1 ,   A N S W E 
R :   9 ,  A U T H O R I T Y :   0 ,  A D D I T 
I O N A L :   0
; ;   Q U E S T I O N   S E C T I O N : 
;á¾ôÕï» . 	 	 I N 	 N S
; ;   A N S W E R   S E C T I O N : á¾ôÕï» 
. 	 8 6 4 0 0 	 I N 	 N S 	 n s - d 
. n i c . l k . á¾ôÕï» . 	 8 6 4 0 
0 	 I N 	 N S 	 n s - l . n i c . l k . 
á¾ôÕï» . 	 8 6 4 0 0 	 I N 
N S 	 n s - t . n i c . l k . á¾ôÕï» . 
	 8 6 4 0 0 	 I N 	 N S  	 l k . c 
o m m u n i t y d n s . n e t . á¾ôÕï» . 
	 8 6 4 0 0 	 I N 	 N S  	 n i c . 
l k - a n y c a s t . p c h . n e t . 
á¾ôÕï» . 	 8 6 4 0 0 	 I N 
N S 	 n s 1 . a c . l k . á¾ôÕï» . 
8 6 4 0 0 	 I N 	 N S 	 n s 3 . a c . l 
k . á¾ôÕï» . 	 8 6 4 0 0 	 I N 
N S 	 n s - b . n i c . l k . á¾ôÕï» . 
	 8 6 4 0 0 	 I N 	 N S 	 n s - c 
. n i c . l k .
; ;   Q u e r y   t i m e :   2 8 1   m s e c ; 
;   S E R V E R :   1 7 2 . 1 6 . 0 . 2 3 # 5 3 
( 1 7 2 . 1 6 . 0 . 2 3 ) ; ;   W H E N :   M o 
n   J u l 9   1 5 : 3 3 : 2 7   2 0 1 2 ; ; 
M S G   S I Z E r c v d :   2 4 0

It's trying to be nice (from the man page):

IDN SUPPORT
   If dig has been built with IDN (internationalized domain name)
   support, it can accept and display non-ASCII domain names.  dig
   appropriately converts character encoding of domain name before
   sending a request to DNS server or displaying a reply from the
   server. If you´d like to turn off the IDN support for some reason,
   defines the IDN_DISABLE environment variable. The IDN support is
   disabled if the variable is set when dig runs.

I like the for some reason quip.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStarYou can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!
___
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


--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStarYou can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!
___
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] I know I'm a curmudgeon but

[Edward Lewis]

At 10:04 -0700 7/9/12, David Conrad wrote:


Sounds like a +no-ulabel option feature request for dig ('cause dig
needs more options).  I'm sure ISC will be happy to take your money to
implement said feature :-).


I'm not sure it's a DiG/ISC issue.  Even when I tried the man page 
fix the problem didn't go away.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStarYou can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!
___
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