Re: [dns-operations] New addresses for b.root-servers.net

[Mukund Sivaraman]

On Tue, May 30, 2023 at 12:16:28PM -0400, Robert Story wrote:
> USC/ISI is renumbering both its IPv4 and IPv6 addresses for
> b.root-servers.net on 2023-11-27. Our new IPv4 address will be
> 170.247.170.2 and our new IPv6 address will be 2801:1b8:10::b.

FWIW, I suggest that implementors/operators download the new version of
the root hints after 2023-11-27 from IANA using an authenticated
transport such as HTTPS instead of using addresses from an
unauthenticated email message/sender.

When we created internal tickets to track this B renumbering, Jinmei
pointed out that though there are defences against cases such as
poisoning from an address in rogue hands, for serious operation it's
important for safety to keep the builtin/installed static hints current
regardless of whether a resolver does priming.

Mukund


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

[dns-operations] Cisco OpenDNS contact

[Mukund Sivaraman]

Would someone from Cisco OpenDNS please contact me off-list to discuss
an issue with an NS? (preferrably from your work email) Thank you.

Mukund


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

Re: [dns-operations] Program/library/framework for testing robustness of servers

[Mukund Sivaraman]

On Mon, Jun 20, 2022 at 03:01:05PM +0530, Mukund Sivaraman wrote:
> As an example of a fuzzer, AFL is very good for detecting illegal
> malformed inputs:

Re-reading, that doesn't sound very correct. AFL is very good for
*preparing* illegal malformed inputs, and how a process "watched" by it
reacts to such input. It finds ways into different execution paths
within a process by manipulating the input.

Mukund


> 
> https://lcamtuf.coredump.cx/afl/
> 
>   Mukund
> 
> 
> On Mon, Jun 20, 2022 at 06:06:41PM +1000, Mark Andrews wrote:
> > You use a fuzzing framework.  You seed the fuzzer with legal messages and 
> > let it
> > generate other inputs but modifying those seeds.
> > 
> > > On 20 Jun 2022, at 17:14, Stephane Bortzmeyer  wrote:
> > > 
> > > I maintain an experimental authoritative DNS server and I would like
> > > to test its robustness. dnsperf and flamethrower are great to test its
> > > performance, zonemaster and dnsviz are perfect to test its correctness
> > > in face of legal input but I would like to see how it reacts to
> > > *illegal*, malformed input. (An example of such input is
> > > <https://lists.dns-oarc.net/pipermail/dns-operations/2022-May/021657.html>.)
> > > 
> > > Since most DNS libraries are made to prevent the programmer for
> > > issuing illegal DNS requests, it is not obvious to write such a test.
> > > 
> > > Are you aware of libraries / programs / frameworks to exercice, in a
> > > hard way, the robustness of a server?
> > > ___
> > > dns-operations mailing list
> > > dns-operations@lists.dns-oarc.net
> > > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> > 
> > -- 
> > 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


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

Re: [dns-operations] Program/library/framework for testing robustness of servers

[Mukund Sivaraman]

As an example of a fuzzer, AFL is very good for detecting illegal
malformed inputs:

https://lcamtuf.coredump.cx/afl/

Mukund


On Mon, Jun 20, 2022 at 06:06:41PM +1000, Mark Andrews wrote:
> You use a fuzzing framework.  You seed the fuzzer with legal messages and let 
> it
> generate other inputs but modifying those seeds.
> 
> > On 20 Jun 2022, at 17:14, Stephane Bortzmeyer  wrote:
> > 
> > I maintain an experimental authoritative DNS server and I would like
> > to test its robustness. dnsperf and flamethrower are great to test its
> > performance, zonemaster and dnsviz are perfect to test its correctness
> > in face of legal input but I would like to see how it reacts to
> > *illegal*, malformed input. (An example of such input is
> > .)
> > 
> > Since most DNS libraries are made to prevent the programmer for
> > issuing illegal DNS requests, it is not obvious to write such a test.
> > 
> > Are you aware of libraries / programs / frameworks to exercice, in a
> > hard way, the robustness of a server?
> > ___
> > dns-operations mailing list
> > dns-operations@lists.dns-oarc.net
> > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> 
> -- 
> 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


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

[dns-operations] a.root-servers.net contact

[Mukund Sivaraman]

Would an operator of a.root-servers.net reply to me off-list? I want to
report a bug which appears to be specific to A.

Mukund


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

Re: [dns-operations] SHA-1 DNSSEC verification broken in RHEL 9 and CentOS 9 Stream

[Mukund Sivaraman]

On Thu, Apr 14, 2022 at 11:22:43AM +0530, Mukund Sivaraman wrote:
> On Thu, Apr 14, 2022 at 10:32:18AM +0530, Shreyas Zare wrote:
> > Hi,
> > 
> > Apart from DNSSEC validation, have you also tested DNS servers hosting
> > DNSSEC signed zones with NSEC3? This is since NSEC3 only has SHA1 specified 
> > <https://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml>
> > and this may cause the DNS server unable to update the zone to create new
> > NSEC3 records. This will mean that even if the zone is signed with ECDSA
> > algorithms but use NSEC3 then they are going to fail.
> 
> Petr's email seems limited to use of RSASHA-1 and NSEC3RSASHA1 as RRSIG
> algorithms, and possibly DS digest type.
> 
> As you point out, SHA-1 is used in NSEC3. It is also used in TSIG
> (hmac-sha1), but these are not affected in the same way currently as use
> in RRSIG and DS. Removing SHA-1 support completely would be very
> disruptive. Even removing support at the OS level for RRSIG and DS seems
> extreme - it is better to allow this to be configured in the DNS
> implementation.
> 
> NSEC3 uses SHA-1 as a one-way hash function to obfuscate the
> corresponding owner name so that a "zone walk" to enumerate all the
> names in a zone is not as straightforward as with NSEC, but it does not
> rely on cryptographic hash function properties such as second pre-image
> resistance, pre-image resistance (back to the original owner name) or

This should say "*except* back to the original owner name".

> even collision resistance. So the usage in NSEC3 would not be affected
> by the current weaknesses in SHA-1.
> 
> HMAC usage of SHA-1 is also still considered safe and "approved" for use
> (e.g., NIST SP 800-57 Part 1 Rev 5 section 5.6.1.2), which is used with
> TSIG.
> 
> TKEY still makes use of MD5 - there was a dnsop thread by Mark Andrews
> about updating it recently.
> 
>   Mukund
> 
> 
> > 
> > Regards,
> > *Shreyas Zare*
> > Technitium <https://technitium.com/>
> > 
> > On 4/13/2022 10:36 PM, Petr Menšík wrote:
> > > 
> > > Hello DNS users,
> > > 
> > > I have already created some bugs to inform some affected software
> > > packages. But I would like to notify also here with prepared plan to
> > > obsolete SHA-1 in upcoming RHEL 9.0. Final documentation is not yet
> > > created for it, but it could be tested already on centos container:
> > > 
> > > docker pull quay.io/centos/centos:stream9
> > > delv command from bind-utils or unbound-host -D from unbound can test
> > > it. delv would still fail, because it does not follow crypto-policy
> > > configuration which named consumes.
> > > 
> > > I have filled tracker bug for EPEL9 components I know on bug #2073066
> > > [1]. If your software validates DNSSEC signatures, it might start
> > > failing on domain names signed with RSASHA1 or NSEC3RSASHA1 algorithms.
> > > If you have package validating DNSSEC on EPEL9 which I have not
> > > mentioned and it is affected, please create a bug blocking this tracker
> > > bug. If  have created the bug but is not affected, please close it with
> > > NOTABUG.
> > > 
> > > Crypto-policy DEFAULT makes some openssl or gnutls methods to fail, when
> > > RSASHA-1 key is used. That includes openssl function EVP_VerifyFinal
> > > (used in bind) and EVP_DigestVerifyInit (used in unbound). Because used
> > > crypto policy DEFAULT prevents such signature verification, DNSSEC
> > > validators may start to return failures on those names.
> > > 
> > > A simple workaround would be switching to crypto policy DEFAULT:SHA1:
> > > 
> > > update-crypto-policies --set DEFAULT:SHA1
> > > 
> > > I have created list to TLD affected and attached them to the bug [2].
> > > But it includes many more names, such as icann.org, ietf.org or
> > > paypal.com.
> > > 
> > > I know it violates still active RFC 8624 [3], but because it is enforced
> > > by lower-level API, it is possible just to follow or fail. I think so
> > > far every crypto call failure results in bogus result and returns status
> > > SERVFAIL on the reply. Would it make sense to create some common cases,
> > > where the result would be fallback to insecure reply without AD bit, but
> > > no failure?
> > > 
> > > Supported bind and unbound packages will start considering those names
> > > as insecure to prevent validation failures. There has been interesting
> > > conv

Re: [dns-operations] SHA-1 DNSSEC verification broken in RHEL 9 and CentOS 9 Stream

[Mukund Sivaraman]

On Thu, Apr 14, 2022 at 11:30:55AM +0530, Shreyas Zare wrote:
> 
> On 4/14/2022 11:22 AM, Mukund Sivaraman wrote:
> > 
> > Petr's email seems limited to use of RSASHA-1 and NSEC3RSASHA1 as RRSIG
> > algorithms, and possibly DS digest type.
> 
> Petr's email was about complete removal of SHA-1 support from RHEL 9.0. So,
> this should affect any software that tries to use SHA-1 for any purpose.

If that is the case (total removal of SHA-1 in all forms), it would be
very disruptive.

Mukund


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

Re: [dns-operations] SHA-1 DNSSEC verification broken in RHEL 9 and CentOS 9 Stream

[Mukund Sivaraman]

On Thu, Apr 14, 2022 at 10:32:18AM +0530, Shreyas Zare wrote:
> Hi,
> 
> Apart from DNSSEC validation, have you also tested DNS servers hosting
> DNSSEC signed zones with NSEC3? This is since NSEC3 only has SHA1 specified 
> 
> and this may cause the DNS server unable to update the zone to create new
> NSEC3 records. This will mean that even if the zone is signed with ECDSA
> algorithms but use NSEC3 then they are going to fail.

Petr's email seems limited to use of RSASHA-1 and NSEC3RSASHA1 as RRSIG
algorithms, and possibly DS digest type.

As you point out, SHA-1 is used in NSEC3. It is also used in TSIG
(hmac-sha1), but these are not affected in the same way currently as use
in RRSIG and DS. Removing SHA-1 support completely would be very
disruptive. Even removing support at the OS level for RRSIG and DS seems
extreme - it is better to allow this to be configured in the DNS
implementation.

NSEC3 uses SHA-1 as a one-way hash function to obfuscate the
corresponding owner name so that a "zone walk" to enumerate all the
names in a zone is not as straightforward as with NSEC, but it does not
rely on cryptographic hash function properties such as second pre-image
resistance, pre-image resistance (back to the original owner name) or
even collision resistance. So the usage in NSEC3 would not be affected
by the current weaknesses in SHA-1.

HMAC usage of SHA-1 is also still considered safe and "approved" for use
(e.g., NIST SP 800-57 Part 1 Rev 5 section 5.6.1.2), which is used with
TSIG.

TKEY still makes use of MD5 - there was a dnsop thread by Mark Andrews
about updating it recently.

Mukund


> 
> Regards,
> *Shreyas Zare*
> Technitium 
> 
> On 4/13/2022 10:36 PM, Petr Menšík wrote:
> > 
> > Hello DNS users,
> > 
> > I have already created some bugs to inform some affected software
> > packages. But I would like to notify also here with prepared plan to
> > obsolete SHA-1 in upcoming RHEL 9.0. Final documentation is not yet
> > created for it, but it could be tested already on centos container:
> > 
> > docker pull quay.io/centos/centos:stream9
> > delv command from bind-utils or unbound-host -D from unbound can test
> > it. delv would still fail, because it does not follow crypto-policy
> > configuration which named consumes.
> > 
> > I have filled tracker bug for EPEL9 components I know on bug #2073066
> > [1]. If your software validates DNSSEC signatures, it might start
> > failing on domain names signed with RSASHA1 or NSEC3RSASHA1 algorithms.
> > If you have package validating DNSSEC on EPEL9 which I have not
> > mentioned and it is affected, please create a bug blocking this tracker
> > bug. If  have created the bug but is not affected, please close it with
> > NOTABUG.
> > 
> > Crypto-policy DEFAULT makes some openssl or gnutls methods to fail, when
> > RSASHA-1 key is used. That includes openssl function EVP_VerifyFinal
> > (used in bind) and EVP_DigestVerifyInit (used in unbound). Because used
> > crypto policy DEFAULT prevents such signature verification, DNSSEC
> > validators may start to return failures on those names.
> > 
> > A simple workaround would be switching to crypto policy DEFAULT:SHA1:
> > 
> > update-crypto-policies --set DEFAULT:SHA1
> > 
> > I have created list to TLD affected and attached them to the bug [2].
> > But it includes many more names, such as icann.org, ietf.org or
> > paypal.com.
> > 
> > I know it violates still active RFC 8624 [3], but because it is enforced
> > by lower-level API, it is possible just to follow or fail. I think so
> > far every crypto call failure results in bogus result and returns status
> > SERVFAIL on the reply. Would it make sense to create some common cases,
> > where the result would be fallback to insecure reply without AD bit, but
> > no failure?
> > 
> > Supported bind and unbound packages will start considering those names
> > as insecure to prevent validation failures. There has been interesting
> > conversation on mattermost Town Square [4] on this topic. Worth noting
> > might be also threads on unbound [5] and Fedora discussion about
> > implementing the same way [6].
> > 
> > Best Regards,
> > 
> > Petr
> > 
> > 1. https://bugzilla.redhat.com/show_bug.cgi?id=2073066
> > 2. https://bugzilla.redhat.com/show_bug.cgi?id=2073066#c7
> > 3. https://datatracker.ietf.org/doc/html/rfc8624#section-3.1
> > 4. https://chat.dns-oarc.net/community/channels/town-square
> > 5.
> > https://lists.nlnetlabs.nl/pipermail/unbound-users/2022-April/007709.html
> > 6. 
> > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/VVLHQAWI3IQ7NRLKMUHJ27JV3V2JAFDP/#W73IMPJVK3DNCRXS5OZXELVWJRDRT6KN
> > 
> > -- 
> > Petr Menšík
> > Software Engineer
> > Red Hat,http://www.redhat.com/
> > email:pemen...@redhat.com
> > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
> > 
> > 

Re: [dns-operations] Full-service resolver - Pending Upstream Query behaviour

[Mukund Sivaraman]

On Tue, Oct 05, 2021 at 11:04:14AM -0700, Paul Vixie wrote:
> 
> 
> Frederico A C Neves wrote on 2021-10-05 09:01:
> > ...
> > 
> > Anyway I think that even though the incident was not DNS related "We",
> > as the DNS community, could probably do better in future events.
> > 
> > I would like to start a discussion or to hear implenters and operators
> > of Full-service resolvers on what would be the best software
> > architecture or best current configuration practice to handle a
> > traffic pattern when a very popular name enters a scenario were all
> > the auth-servers are timing-out or network unreachable.

Some BIND derivatives such as ours (I don't know if ISC BIND retained
such a patch) have a holddown timer feature which caches timeouts when
contacting upstream nameservers and backs off for a bit when the server
continues to remain unreachable.

There's also a downstream servfail cache in the nameserver path of newer
versions of BIND.

Some resolvers also have implemementations of the serve-stale(TTL) RFC,
and the Unbound-like behavior of answering expired answers from cache
first even before attempting resolution. We will be checking what the
effect of this was during the Facebook outage, at least for DNS answers
from cache.

> was cache miss deduplication by q-tuple ever standardized? it is a nec'y
> part of kaminsky resistance and so ought to be part of whatever BCP corpus
> comes about. pending upstream query behaviour would be an expansion on cache
> miss dedup by q-tuple, such that a rising tide of timeouts would yield
> probabilistic prediction of servfail for cache misses aimed at the affected
> .

Due to a transient bug in NIOS BIND that unfortunately entered
operations, we found the hard way what the cost of not de-duplicating
cache miss -> resolutions was. It's not just that the resolver chokes,
but it also floods upstream nameservers and becomes a bad internet
citizen.  We fixed it and the following draft was written (section 3.1):

https://datatracker.ietf.org/doc/html/draft-muks-dnsop-dns-thundering-herd-00

IIRC, when this draft was published, a reviewer mentioned that the
de-duplication of upstream queries behavior is also recommended in some
other RFC already for different reasons.

Mukund

> 
> in 2003, i implemented this as a form of negative caching, where the
> negativity spectrum included timeouts, refuseds, and servfails -- not just
> nxdomain. this worked well but needed refinement and the implementation was
> not open-source. so, you and i with rodney joffe published "resimprove"
> containing some of these ideas, but it has taken some decades to get these
> accepted.
> 
> i hope you succeed in this rekindling, and i would join any such effort.
> when it comes to authority dns responses to cache miss transactions, recent
> nonperformance is an excellent reason to predictively fail rather than
> packing good on top of bad. distributed state can be treated as a mass-like
> quantity, so that its inertia can be conserved at design time.
> 
> vixie
> 
> -- 
> Sent from Postbox 

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


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

Re: [dns-operations] resolver cache question

[Mukund Sivaraman]

Hi Mark

On Fri, Nov 13, 2020 at 12:41:54PM -0500, Mark Allman wrote:
> 
> Folks-
> 
> I just finished reading a paper that basically tries to figure out
> if a hostname is worth caching or not [1].  This isn't the first
> paper like this I have read.  This sort of thing strikes me as a
> solution in search of a problem.  The basic idea is that there are
> lots of hostnames that are automatically generated---for various
> reasons---and only ever looked up one time.  Then there is an
> argument made that these obviously clog up resolver caches.
> Therefore, if we can train a fancy ML classifier well enough to
> predict these hostnames are ephemeral and will only be resolved the
> once---because they are automatically generated and so have some
> tells---then we can save cache space (and effort) by not caching
> these.
> 
>   - My first reaction to the notion of clogging the cache is always
> to think that surely some pretty simple LFU/LRU eviction policy
> could handle this pretty readily.  But, that aside...
> 
>   - I wonder how much this notion of caches getting clogged up
> really happens.  Could anyone help with a clue?  How often do
> resolvers evict entries before the TTL expires?  Or, how much
> over-provisioning of resolvers happens to accommodate such
> records?  I know resolver caching helps [2], but I always feel
> like I really know nothing about it when I read papers like
> this.  Can folks help?  Or, point me at handy references?

A metric that large resolver operators usually watch is the
cache-hit-rate (CHR). A high CHR suggests a resolver's cache is helping
avoid work for the resolver. For non-attack traffic, the TTL-expiry and
LRU rdataset eviction strategies usually work well and it is unusual to
have to mitigate for non-attack traffic specially.

In recent years, there has been a form of traffic called random
subdomain attack or water torture attack, which led to negative cache
entries polluting a resolver's cache, and there have been mitigations
put in place to deal with them.

If there is a proposal that accurately predicts which cache entries will
be unused and can be evicted in preference, it would certainly help in
pruning the cache optimially and keeping the CHR high. Managing cache
size and watching CHR typically are things done by larger resolver
operators - usually these aren't problems in a small LAN's resolver
where defaults work ok. At a large scale, determining cache entries that
can be evicted from public DNS traffic isn't easy. Resolvers mainly
still use TTL expiry and LRU based evition, with small hacks for some
special cases.

NSEC aggressive use (RFC 8198) also helps with some forms of random
subdomain attack traffic.

About how often resolvers evict entries before the TTL expires, and
related questions, these depend on the resolver site's traffic and it
can be temporal/fleeting, i.e., the answer to these questions can change
quickly at the same resolver site depending on changing traffic
patterns. Some of our customers' resolvers have caches at the maximum
memory limit for continuous periods (new cache entries would evict old
ones), and it is not necessarily a problem.

Large sites are provisioned to keep the CHR high and handle the expected
query rate. CHR and some other related metrics such as query rate,
average query response time, fetches in progress, receive queue lengths,
etc. are monitored, and the resolver is scaled accordingly. From my
experience, the problems due to traffic at different locations/times are
different and we diagnose problems by dumping various metrics and
comparing with traffic captures on a case by case basis. Legitimate
traffic including for names within generated sequences of hostnames does
not commonly cause problems for a properly provisioned resolver. It is
usually intended or unintended flood of various kinds of traffic
patterns that cause problems. Random subdomain queries are a pattern of
problematic traffic, but there are other patterns, intended and
unintended, that can cause problems for an implementation.

If generated hostnames were a significant problem, it would be an
ongoing concern. If someone proposes a working attack traffic idea, it
would be observed very quickly at busy public resolvers. I haven't come
across a pcap from a busy public resolver that didn't contain what
looked like the pattern of an attempted attack - resolvers receive
abusive traffic patterns daily, all the time. Good new ideas on
improving what to keep and what to evict from cache are welcome though.

Mukund


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

[dns-operations] .com delegation responses when glue addresses don't fit

[Mukund Sivaraman]

We notice the following response from .com's namesevers:

[muks@mx ~]$ dig +nord +dnssec +bufsize=512 @2001:502:1ca1::30 infoblox.com

; <<>> DiG 1.1.1.20200608151533.e8a2352e96 <<>> +nord +dnssec +bufsize=512 
@2001:502:1ca1::30 infoblox.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15448
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 11, ADDITIONAL: 1

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

;; AUTHORITY SECTION:
infoblox.com.   172800  IN  NS  ns1.infoblox.com.
infoblox.com.   172800  IN  NS  ns2.infoblox.com.
infoblox.com.   172800  IN  NS  ns3.infoblox.com.
infoblox.com.   172800  IN  NS  ns4.infoblox.com.
infoblox.com.   172800  IN  NS  ns5.infoblox.com.
infoblox.com.   172800  IN  NS  ns6.infoblox.com.
infoblox.com.   86400   IN  DS  33613 5 2 
339462CBAEB1773800EA8B688D2CA048FCAB0EB2933A97AEE2B86A9A 212F37C5
infoblox.com.   86400   IN  DS  33613 5 1 
629C2D6C060E2133CD0F4470F3ECC8834DA4FAD6
infoblox.com.   86400   IN  DS  49879 5 2 
605656DB7C9DFE4D8A453C350B3DA63039A78878DA089AD4247AB9A0 D3B43998
infoblox.com.   86400   IN  DS  49879 5 1 
C1DB78AD9A8928CB15A7E0CE9E4468D433F5C638
infoblox.com.   86400   IN  RRSIG   DS 8 2 86400 20200823050241 
20200816035241 24966 com. 
0s/TnWuxLdVzCQqY0tVauNXeCpirT5rYacvEpxaQfTxCjP2XfZkqHy4A 
SNoGyYWGZQdxTa7zXVgrKuWOoKZ2CKxC/kd++VnEJKoFw3llOoq56Wz+ 
lq65BS7E6/ZlE4Qgce8rhbBQVkE6Sk1YXkuxDbwoPYfvkHlfWaboeiNO 
6y731Xcrq3vjqdG6YZCHyH64SSnVFypUiRN26H2HPsYsSg==

;; Query time: 19 msec
;; SERVER: 2001:502:1ca1::30#53(2001:502:1ca1::30)
;; WHEN: Wed Aug 19 17:30:29 GMT 2020
;; MSG SIZE  rcvd: 512

[muks@mx ~]$


Glue address records are required in this delegation response, but none
are returned. TC=1 is not set. This causes problems with some resolvers.

Can someone at Verisign please check correctness of this response, and
set TC=1 for such responses?

It appears to be the problem statement of:
https://tools.ietf.org/html/draft-andrews-dnsop-glue-is-not-optional-01

Mukund


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

Re: [dns-operations] help with a resolution

[Mukund Sivaraman]

On Thu, Jan 09, 2020 at 12:38:05PM +0530, Mukund Sivaraman wrote:
> > > Loop's toolchain has had the default algorithms so, which it inherited. 
> > > There
> > > is a branch that changes the defaults, but it won't be merged in the first
> > > quarter of this year.
> > 
> > If there is a default, it should promptly change to 8 or 13.
> 
> I will prioritize it.

This work has been merged now in Loop, to match the recommendations of
RFC 8624:

* dnssec-keygen by default creates ECDSAP256SHA256 keys
* dnssec-dsfromkey by default generates DS with SHA-256 and SHA-384 digests
* dnssec-dsfromkey cannot be used to create DS with a SHA-1 digest
* dnssec-keygen -3 argument has been removed (redundant with -a)
* dnssec-dsfromkey -1 and -2 arguments have been removed (redundant with -a)
* Documentation and tests were updated for the above

[muks@jurassic ~/tmp-dnssec]$ dnssec-keygen example.org
Generating key pair.
Kexample.org.+013+21773
[muks@jurassic ~/tmp-dnssec]$ cat Kexample.org.+013+21773.key 
; This is a zone-signing key, keyid 21773, for example.org.
; Created: 20200110143300 (Fri Jan 10 20:03:00 2020)
; Publish: 20200110143300 (Fri Jan 10 20:03:00 2020)
; Activate: 20200110143300 (Fri Jan 10 20:03:00 2020)
example.org. IN DNSKEY 256 3 13 
X5t7zeDf1PSTfkXbZBXcEJUK0PU15GlNlANqSDt9GsTL68FkA4R2H66D 
zaz+Xeqe+wZKJikqcpSeQweDbJ7tEA==
[muks@jurassic ~/tmp-dnssec]$ dnssec-dsfromkey Kexample.org.+013+21773
example.org. IN DS 21773 13 2 
86A48213B13F14A92865CFDAB9D0F6536979609729018DA52EED4684D110A95E
example.org. IN DS 21773 13 4 
21A134504A1553844B86D01FBB4F8B383BF2924CCC82BE54D7ABD371F45C33FF5E602CA02168C9AB7915B1D14F60A201
[muks@jurassic ~/tmp-dnssec]$ 

The RSASHA1 and RSASHA1-NSEC3-SHA1 algorithms are still available for
selection during key generation using dnssec-keygen -a. We will wait for
dnsop activity before removing them. Separately, the resolver's
validator continues to support them.

The dist builder has been triggered; packages will appear in the
repositories in a few hours after the platform workers finish their
builds and tests.

It appears that the dnssec-* programs ought to be renamed so that
there's no confusion with BIND's utilities. There's already a bug
ticket. I will make a note on it.

(BTW, thank you for kindly mentioning that the default should be
promptly changed, and not being overly critical as RFC 8624 has been out
for ~7 months now. It is much appreciated.)

   Mukund


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

Re: [dns-operations] help with a resolution

[Mukund Sivaraman]

On Wed, Jan 08, 2020 at 01:45:44PM -0500, Viktor Dukhovni wrote:
> On Wed, Jan 08, 2020 at 11:34:00PM +0530, Mukund Sivaraman wrote:
> 
> > > > [muks@jurassic ~/tmp-dnssec]$ dnssec-dsfromkey Kexample.org.+005+04222
> > > > example.org. IN DS 4222 5 1 7B83C10E0220CA65139DFFE14F3F24B8D8ACAEA2
> > > > example.org. IN DS 4222 5 2 
> > > > 06B8EB5B92B64B87C75E7B0F589876067E4E31B6F34750DA853FF5D79101D831
> > > 
> > > Algorithm 5 (which signs with SHA-1) SHOULD NOT be used in new
> > > deployments.  The current best-practice choices are algorithm 8 (RSA
> > > with SHA2-256) and algorithm 13 (ECDSA with NIST curve P-256 and
> > > SHA2-256).
> >
> > You are absolutely right and algorithm 13 is best suited.
> 
> And with the latest news about SHA-1 chosen-prefix attacks, algorithm 5 now
> really needs to be avoided.
> 
> > It was really not an example to pick an algorithm, but to demonstrate
> > how to verify a zone which the poster asked. No algorithm arguments were
> > passed.
> 
> Sure, but you were also advising against the SHA-1 DS digest type (still
> reasonably safe) in an example that used algorithm 5 with its now rather
> weakened RSASHA1 signature.  I think that warranted a comment, just in
> case anyway walked away with the wrong impression.

You're right of course that algorithm 13 ought to be used in preference.

> 
> - Algorithms 5 and 7 are now seriously wounded, though perhaps not
>   yet in all use-cases dead.
> 
> - DS algorithm 1 is tarnished and not recommended, but there are
>   no known attacks.
> 
> > Loop's toolchain has had the default algorithms so, which it inherited. 
> > There
> > is a branch that changes the defaults, but it won't be merged in the first
> > quarter of this year.
> 
> If there is a default, it should promptly change to 8 or 13.

I will prioritize it.


> > > Instead, the attacks are against SHA-1 based *signature* algorithms, where
> > > the key-holder (typically parent zone) signs data that is partly under the
> > > control of potentially hostile others.  So the important thing is avoiding
> > > algorithms 5 and 7, NOT avoiding digest type 1.
> > 
> > The mail only said SHA-1 is weakening in security day by day. A better 
> > choice
> > is available and widely supported which is digest 2, which was printed by 
> > the
> > default run of dnssec-dsfromkey in the example and explained as preferrable.
> 
> See above, yes SHA-1 is tarnished, but its is as a DS digest type is not the
> reason, there are no known attacks there, the real issue is DNSKEY algorithms
> 5 and 7.
> 
> > With the chosen-prefix collision attack, a rogue actor who is in charge of
> > creating KSKs may create 2 KSKs that generate the same DS SHA-1 digest 
> > field.
> 
> If you have a rogue actor controlling your KSKs, all bets are off.

> 
> > He may then submit and deploy the 1st key at his workplace and then sell the
> > 2nd key that would lead a different paper trail than the first
> 
> I don't see the point, why not just sell the real key, what difference does it
> make.  Indeed if the second key gets discovered, then it is clear the keys
> were cooked, and who the guilty party is.  But with a leak of the single
> legitimate key, it is far less clear a-priori who leaked the key.
> 
> > MD5 also doesn't have a practical second pre-image attack, but it was not
> > added as a DS digest.
> 
> Indeed, we avoid new uses of tarnished algorithms.
> 
> > Having read many of your posts, I greatly respect your opinion. It seems
> > unnatural to me that you would use SHA-1 as a DS digest type today, or not
> > advise a friend to switch from it if you saw it being used.
> 
> I would not introduce new uses of SHA-1 in DS RRs.  Below is my complete
> DS RRset:
> 
> dukhovni.org. IN DS 34314 13 2 
> 1efe87df8925417c29df1791b0ea495550acb2ff76515cc3005863497ef6b9d2
> 
> my point is that if you do have a SHA-1 DS RR, that's not an immediate
> problem, but algorithms 5 and 7, especially in zones that sign other
> people's data, are a much more immediate probem, and because it is
> difficult to explain which use-case of 5 and 7 are still safe, and which
> are not, the priority is to deprecate these DNSKEY algorithms.
> 
> We can also discourage SHA-1 as a DS digest type, but only out of an
> abundance of caution, we now have better algorithms in which we have
> more confidence.  There's no known practical threat, the algorithm still
> offers around 160 bits of 2nd pre-image resistance and is well out of
> reach of any known attacks.
> 
> -- 
> Viktor.
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>

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

Re: [dns-operations] help with a resolution

[Mukund Sivaraman]

On Wed, Jan 08, 2020 at 08:07:22PM +, Paul Vixie wrote:
> On Wednesday, 8 January 2020 18:45:44 UTC Viktor Dukhovni wrote:
> 
> > > Loop's toolchain has had the default algorithms so, which it inherited.
> > > There is a branch that changes the defaults, but it won't be merged in
> > > the first quarter of this year.
> > 
> > If there is a default, it should promptly change to 8 or 13.
> 
> there should be a default, and it should move forward over time.

I will prioritize updating the default algorithms now.

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

Re: [dns-operations] help with a resolution

[Mukund Sivaraman]

Hi Viktor

On Wed, Jan 08, 2020 at 10:05:53AM -0500, Viktor Dukhovni wrote:
> On Wed, Jan 08, 2020 at 08:11:56PM +0530, Mukund Sivaraman wrote:
> 
> > [muks@jurassic ~/tmp-dnssec]$ dnssec-keygen -f KSK example.org
> > Generating key pair..+ .+ 
> > Kexample.org.+005+04222
> >
> > [muks@jurassic ~/tmp-dnssec]$ dnssec-dsfromkey Kexample.org.+005+04222
> > example.org. IN DS 4222 5 1 7B83C10E0220CA65139DFFE14F3F24B8D8ACAEA2
> > example.org. IN DS 4222 5 2 
> > 06B8EB5B92B64B87C75E7B0F589876067E4E31B6F34750DA853FF5D79101D831
> 
> Algorithm 5 (which signs with SHA-1) SHOULD NOT be used in new
> deployments.  The current best-practice choices are algorithm 8 (RSA
> with SHA2-256) and algorithm 13 (ECDSA with NIST curve P-256 and
> SHA2-256).
> 
> Of these two, I'd recommend algorithm 13, because it produces signatures
> that are more secure and substantially more compact.  Indeed algorithm
> 13 is now the most popular algorithm among signed domains, having
> recently surpassed 8:
> 
> https://stats.dnssec-tools.org/#parameter
> 
> Algorithm 5 is a very distant 4th.

You are absolutely right and algorithm 13 is best suited.

It was really not an example to pick an algorithm, but to demonstrate
how to verify a zone which the poster asked. No algorithm arguments were
passed.

Loop's toolchain has had the default algorithms so, which it
inherited. There is a branch that changes the defaults, but it won't be
merged in the first quarter of this year.

I think BIND's dnssec-keygen requires you to specify the algorithm now,
so the poster will likely need to provide it.

> > Also note that hash algorithm 1 (in the "5 1" RR printed above) stands
> > for SHA-1 hash which is weakening in security day by day, so you would
> > probably want to add only the "5 2" RR from above, where 2 stands for
> > SHA-256. A complete list of these is here:
> > https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml
> 
> This is wrong.  The attacks are not against the digest algorithm that's
> hashing the key.  With the DS RR digest types there are no collision
> issues, and only SHA-1 2nd-preimage resistance matters, which remains
> unbroken.
> 
> Instead, the attacks are against SHA-1 based *signature* algorithms,
> where the key-holder (typically parent zone) signs data that is partly
> under the control of potentially hostile others.  So the important
> thing is avoiding algorithms 5 and 7, NOT avoiding digest type 1.

The mail only said SHA-1 is weakening in security day by day. A better
choice is available and widely supported which is digest 2, which was
printed by the default run of dnssec-dsfromkey in the example and
explained as preferrable.



On the topic of the recent "SHA-1 is a Shambles" ePrint paper and the
dnsop thread about how it affects DNSSEC, perhaps I may have understood
what you have pictured by DS needing second pre-image resistance, but
there are different sorts of situations and once a digest's security has
weakened so much, it is basically to be avoided. With the chosen-prefix
collision attack, a rogue actor who is in charge of creating KSKs may
create 2 KSKs that generate the same DS SHA-1 digest field. He may then
submit and deploy the 1st key at his workplace and then sell the 2nd key
that would lead a different paper trail than the first - a leak of the
first KSK may not be possible by other safeguards, or be discovered from
observed rogue signatures, but the existence of the second KSK may not
be known or suspected. It may not matter to a particular use case or
line of thinking, but cryptography security is about preventing every
circumstance.

MD5 also doesn't have a practical second pre-image attack, but it was
not added as a DS digest.

Having read many of your posts, I greatly respect your opinion. It seems
unnatural to me that you would use SHA-1 as a DS digest type today, or
not advise a friend to switch from it if you saw it being used.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

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

[Mukund Sivaraman]

On Wed, Jan 08, 2020 at 08:15:50PM +0530, Mukund Sivaraman wrote:
> On Tue, Jan 07, 2020 at 12:20:01PM +, Niall O'Reilly wrote:
> > What's surprising is that an authoritative name server
> > shows both a decremented TTL value (as if it were answering
> > from cache) and the AA flag.
> 
> These days, another kind of authoritative nameservice seems to have
> arrived - the "reverse proxy" idea adapted to DNS. It may forward an
> authoritative query upstream, cache the result and return an
> authoritative answer counting down the TTL. We know this scheme well as
> a forwarder during resolution, but it appears it's being used in
> authoritative service too.

... as a CDN service where the reverse proxy (forwarder) nameserver and
the "master" nameserver are far away, and in different administration
domains.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

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

[Mukund Sivaraman]

On Tue, Jan 07, 2020 at 12:20:01PM +, Niall O'Reilly wrote:
> What's surprising is that an authoritative name server
> shows both a decremented TTL value (as if it were answering
> from cache) and the AA flag.

These days, another kind of authoritative nameservice seems to have
arrived - the "reverse proxy" idea adapted to DNS. It may forward an
authoritative query upstream, cache the result and return an
authoritative answer counting down the TTL. We know this scheme well as
a forwarder during resolution, but it appears it's being used in
authoritative service too.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] help with a resolution

[Mukund Sivaraman]

On Wed, Jan 08, 2020 at 07:05:04PM +0800, William C wrote:
> Thanks all for explains.
> I am new to DNSSEC, so I have questions:
> 
> 1. how to check if a zone has a valid DNSSEC key?

The hash in the DS record in the parent zone should correspond to the
DNSKEY at the apex of your (child) zone.

So, for example, if you have generated your DNSKEY using BIND's
dnssec-keygen utility, you can use the dnssec-dsfromkey to generate DS
records for such keys.

The following is an example that prints a DNSKEY's corresponding DS
records (I'm using Loop's utilities which are similar with some small
differences):

[muks@jurassic ~/tmp-dnssec]$ dnssec-keygen -f KSK example.org
Generating key pair..+ .+ 
Kexample.org.+005+04222
[muks@jurassic ~/tmp-dnssec]$ ls
Kexample.org.+005+04222.key  Kexample.org.+005+04222.private
[muks@jurassic ~/tmp-dnssec]$ dnssec-dsfromkey Kexample.org.+005+04222
example.org. IN DS 4222 5 1 7B83C10E0220CA65139DFFE14F3F24B8D8ACAEA2
example.org. IN DS 4222 5 2 
06B8EB5B92B64B87C75E7B0F589876067E4E31B6F34750DA853FF5D79101D831
[muks@jurassic ~/tmp-dnssec]$ 

The DS records printed should be added to the parent zone (e.g., if your
zone's parent is a top-level zone such as com., you would typically add
these DS records using the registrar's interface).

Also note that hash algorithm 1 (in the "5 1" RR printed above) stands
for SHA-1 hash which is weakening in security day by day, so you would
probably want to add only the "5 2" RR from above, where 2 stands for
SHA-256. A complete list of these is here:
https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml

> 2. how to validate if the zone has been signed with correct key?

If you have a signed zone in master file format (such as generated by
BIND's dnssec-signzone utility), you may verify the signatures using
dnssec-verify. For example, let's create an example zone and sign it
using the KSK key above:

[muks@jurassic ~/tmp-dnssec]$ echo "example.org. 3600 IN SOA . . 1 3600 3600 
3600 3600" > example.org.zone
[muks@jurassic ~/tmp-dnssec]$ echo "example.org. NS ns1.example.com." >> 
example.org.zone
[muks@jurassic ~/tmp-dnssec]$ dnssec-signzone -z -S -o example.org 
example.org.zone 
dnssec-signzone: warning: example.org.zone:2: using RFC1035 TTL semantics
Fetching KSK/ZSK 4222/RSASHA1 from key repository.
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 0 active, 0 stand-by, 0 revoked
example.org.zone.signed
[muks@jurassic ~/tmp-dnssec]$ 

Let's verify the signed zone against the KSK:

[muks@jurassic ~/tmp-dnssec]$ dnssec-verify -x -o example.org 
example.org.zone.signed Kexample.org.+005+49357
Loading zone 'example.org' from file 'example.org.zone.signed'
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 0 active, 0 present, 0 revoked
[muks@jurassic ~/tmp-dnssec]$ 

Please read the manpages of dnssec-keygen, dnssec-signzone, and
dnssec-verify on why the arguments above were used. Typically you would
use a second DNSKEY called a ZSK in your zones, and you wouldn't have to
use the arguments above.

Finally, delv and dig +trace are useful to check what your network sees
of the public DNS data.

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

Re: [dns-operations] GPS time glitch last night

[Mukund Sivaraman]

On Wed, Jan 01, 2020 at 10:07:20PM -0600, Chris Adams wrote:
> Once upon a time, Mukund Sivaraman  said:
> > Some people are reporting a GPS time glitch list night, which seems to
> > have affected our ntpd instance too. From the logs, it appears to have
> > stopped trusting GPS clocks due to a greater than expected change in
> > $GPRMC time. A restart of the ntpd process fixed it.
> 
> Is this just with a particular clock type (or multiple types but all
> using NMEA sentences)?  I have an old Trimble Resolution T in TSIP
> binary mode rather than NMEA, and it doesn't appear to have had any
> issue.

We use the Garmin GPS 18x LVC model in NMEA mode, and they run current
firmware. Glitches have been reported with other devices on the nanog
list, and Bert's monitor seems to have picked up a spurious reading as
well. On the machine that I posted logs from in this thread, its logs
show it occurring about half hour away from another reported time. This
receiver is in Chennai, India and receives from a different set of
satellites at any time, vs. Americas, Europe, and South Africa. The
wiredata from the GPS receiver was limited to $GPRMC NMEA sentences and
PPS pulses, so there are no other logs.

Without being familiar with the firmware code, I guess that even if the
device were in binary mode, the time glitch would have still have
occurred as the mode is only a difference in encoding - the data in the
NMEA sentences, and the PPS signal, are generated by the GPS receiver.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] GPS time glitch last night

[Mukund Sivaraman]

Hi Bert

On Wed, Jan 01, 2020 at 10:32:48AM +0100, bert hubert wrote:
> On Wed, Jan 01, 2020 at 01:26:27PM +0530, Mukund Sivaraman wrote:
> > Some people are reporting a GPS time glitch list night, which seems to
> > have affected our ntpd instance too. From the logs, it appears to have
> > stopped trusting GPS clocks due to a greater than expected change in
> > $GPRMC time. A restart of the ntpd process fixed it.
> 
> Hi Muks,
> 
> Do you have some further details on the $GPRMC log lines?

During last night, the ntpd process suddenly dropped its GPS reference
clock. This is the first time we've observed this happening.  ntpq -np
showed an 'x' in the remote field where an 'o' should be. 'x' means "Out
of tolerance, do not use (discarded by intersection algorithm);"
(https://nlug.ml1.co.uk/2012/01/ntpq-p-output/831)

It was noticed in the morning. A drift is observed in
/var/log/peerstats.20191231. Corresponding to the log times of where the
drift starts, the $GPRMC sentences from /var/log/clockstats.20191231
show the following:

58848 73710.974 127.127.20.0 
$GPRMC,202830,A,.,_,_.,_,000.0,029.5,311219,001.5,W,D*__
58848 73726.974 127.127.20.0 
$GPRMC,202846,A,.,_,_.,_,000.0,029.5,311219,001.5,W,D*__
58848 73742.974 127.127.20.0 
$GPRMC,202902,A,.,_,_.,_,000.0,029.5,311219,001.5,W,D*__
58848 73758.974 127.127.20.0 
$GPRMC,202918,A,.,_,_.,_,000.0,029.5,311219,001.5,W,D*__
58848 73774.974 127.127.20.0 
$GPRMC,202934,A,.,_,_.,_,000.0,029.5,311219,001.5,W,D*__
58848 73790.974 127.127.20.0 
$GPRMC,202950,A,.,_,_.,_,000.0,029.5,311219,001.5,W,D*__
58848 73806.974 127.127.20.0 
$GPRMC,203006,A,.,_,_.,_,000.0,029.5,311219,001.5,W,D*__
58848 73822.974 127.127.20.0 
$GPRMC,203025,A,.,_,_.,_,000.0,029.5,311219,001.5,W,D*__
58848 73838.973 127.127.20.0 
$GPRMC,203041,A,.,_,_.,_,000.0,029.5,311219,001.5,W,D*__
58848 73854.973 127.127.20.0 
$GPRMC,203057,A,.,_,_.,_,000.0,029.5,311219,001.5,W,D*__
58848 73870.973 127.127.20.0 
$GPRMC,203113,A,.,_,_.,_,000.0,029.5,311219,001.5,W,D*__
58848 73886.974 127.127.20.0 
$GPRMC,203129,A,.,_,_.,_,000.0,029.5,311219,001.5,W,D*__
58848 73902.973 127.127.20.0 
$GPRMC,203145,A,.,_,_.,_,000.0,004.7,311219,001.5,W,D*__
58848 73918.973 127.127.20.0 
$GPRMC,203201,A,.,_,_.,_,000.0,004.7,311219,001.5,W,D*__
58848 73934.973 127.127.20.0 
$GPRMC,203217,A,.,_,_.,_,000.0,004.7,311219,001.5,W,D*__
58848 73950.973 127.127.20.0 
$GPRMC,203233,A,.,_,_.,_,000.0,004.7,311219,001.5,W,D*__
58848 73966.973 127.127.20.0 
$GPRMC,203249,A,.,_,_.,_,000.0,004.7,311219,001.5,W,D*__
58848 73982.973 127.127.20.0 
$GPRMC,203305,A,.,_,_.,_,000.0,004.7,311219,001.5,W,D*__
58848 73998.973 127.127.20.0 
$GPRMC,203321,A,.,_,_.,_,000.0,004.7,311219,001.5,W,A*__
58848 74014.973 127.127.20.0 
$GPRMC,203337,A,.,_,_.,_,000.0,004.7,311219,001.5,W,A*__
58848 74030.973 127.127.20.0 
$GPRMC,203350,A,.,_,_.,_,000.0,004.7,311219,001.5,W,A*__
58848 74046.973 127.127.20.0 
$GPRMC,203406,A,.,_,_.,_,000.0,004.7,311219,001.5,W,A*__
58848 74062.973 127.127.20.0 
$GPRMC,203422,A,.,_,_.,_,000.0,004.7,311219,001.5,W,A*__
58848 74078.973 127.127.20.0 
$GPRMC,203438,A,.,_,_.,_,000.0,004.7,311219,001.5,W,A*__
58848 74094.973 127.127.20.0 
$GPRMC,203454,A,.,_,_.,_,000.0,004.7,311219,001.5,W,A*__
58848 74110.973 127.127.20.0 
$GPRMC,203510,A,.,_,_.,_,000.0,004.7,311219,001.5,W,A*__
58848 74126.973 127.127.20.0 
$GPRMC,203526,A,.,_,_.,_,000.0,004.7,311219,001.5,W,D*__
58848 74142.974 127.127.20.0 
$GPRMC,203542,A,.,_,_.,_,000.0,004.7,311219,001.5,W,D*__
58848 74158.973 127.127.20.0 
$GPRMC,203558,A,.,_,_.,_,000.0,004.7,311219,001.5,W,D*__

These messages are logged once every 16 seconds. The $GPRMC time (UTC)
jumped from 203006 to 203025 (delta 19 seconds), and then corrected back
from 203337 to 203350 (delta 13 seconds). Note that these $GPRMC lines
are the (derived) output of the GPS receiver.

The GPS receiver is a Garmin GPS 18x LVC running the latest firmware.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] GPS time glitch last night

[Mukund Sivaraman]

Some people are reporting a GPS time glitch list night, which seems to
have affected our ntpd instance too. From the logs, it appears to have
stopped trusting GPS clocks due to a greater than expected change in
$GPRMC time. A restart of the ntpd process fixed it.

https://mailman.nanog.org/pipermail/nanog/2019-December/105053.html
https://twitter.com/GalileoSats/status/1212190538750996480

If you are running a validating resolver or signer with local GPS based
time sources, you may want to check synchronization.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

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

[Mukund Sivaraman]

On Tue, Nov 26, 2019 at 08:41:51AM -0500, Mark Allman wrote:
> 
> Let me try to get away from what is or is not "big" and ask two
> questions.  (These are legit questions to me.  I have studied the
> DNS a whole bunch, but I do not operate any non-trivial part of the
> DNS and so that viewpoint is valuable to me.)
> 
> (1) Setting aside history and how things have been done and why
> (which I am happy to stipulate is rational)... At this point,
> are there tangible benefits for getting information about the
> TLD nameservers to resolvers as needed via a network service?
> 
> (2) Are there fundamental problems that would arise in recursive
> resolvers if the information about TLD nameservers was no longer
> available via a network service, but instead had to come from a
> file that was snarfed periodically?

Probably not many. There are some Twitter feeds about what kinds of
changes occur to the root zone and how frequently, e.g.:

https://twitter.com/diffroot

I like how you've posed your questions, at a high-level view.

In the past few years, I've heard of several proposals for improving
root zone resilience, and how it can be made available to resolvers more
readily and robustly.

* RFC 7706 (root zone on loopback)
* Paul Vixie's idea about making one of the root letters have AS112
  style IP addresses
* Root zone mirroring with zone transfer over HTTPS
* Root zone distribution via bittorrent (IIRC I heard it from NLnet Labs
  staff)
* Root zone distribution as a blockchain
* DNS as a blockchain
* Combining zones into a look-aside megazone that is well provisioned

The root zone is another zone. Due to real-world traffic patterns, it is
perhaps more resilient to authoritative service degradation than
top-level zones such as "com." because once a TLD delegation (e.g.,
com.) is cached in a resolver, it is not going to look in the root zone,
when names in the TLD (e.g., com.) are queried, for a very long time.

DNS will always have an under-provisioning problem until there is some
policy about traffic. It will be so as long as a network-connected IP
camera is able to generate packets that saturate its 1Gbps link, and as
long as manufacturers are not liable for how their devices behave
(quality of firmware, updates, etc.).

Resilience applies to _any_ zone, not just the root zone. If an
Alexa-top-10 example.com company's authoritative DNS nameservers are
attacked by an equivalent of the Mirai botnet, or worse, a government
sponsored packet flood / DNS QUERY flood, overprovisioning to handle
such attacks increases its running costs by orders of magnitude. CDNs
with their global anycast DNS service are popular these days, but their
resiliency would depend on the specific attack circumstances. Not a year
goes by where we don't hear of a significant DNS outage due to a
DDoS. Use of such CDNs have also made DNS more centralized, which not
everybody thinks is wise for the general health of the internet.
Availability of a service doesn't depend just on resilience to DDoS
attacks.

If we use response/query percentage (response rate) as a metric for
service quality of a zone, a popular TLD zone would be more vulnerable
than the root when there is similar degradation of response rate.  The
same can be said for CDN-style global anycast authoritiative
DNS too. What would be more noticed and make the popular news - if
root-servers were to drop to 50% of their reply rate, or if Cloudflare
DNS were to drop to 50% of its reply rate?

It does not appear taking over-provisioning for granted would work
well. Borrowing a sibling reply's nomenclature, "large" will not work
robustly now or in the long term. "Clever" has to be better than root on
loopback - it has to work for other parts of DNS too (what if the root
works, but we can't resolve any new queries in the "com." TLDs?)
"Clever" has to be also about regulating, about limits imposed in
equipment by laws, and responsibility for maintaining connected
devices. The average human who installs a security camera knows nothing
about what happens on the wire and cannot realistically be expected to
be responsible.

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

Re: [dns-operations] Non-EDNS FORMERR with qdcount==0?

[Mukund Sivaraman]

Hi Viktor

On Mon, Nov 18, 2019 at 04:06:57AM -0500, Viktor Dukhovni wrote:
> EDNS(0) queries to the (protocol-violating w.r.t. to unexpected QTYPES)
> nameservers for mail.protection.outlook.com, which don't support EDNS(0),
> elicit a response which fails to include a copy of the original question
> (see below).  Is this valid?
> 
> My response validation logic checks not only the source IP and transction id,
> but also looks for a matching question, and discards the response otherwise, 
> so
> I don't see the FORMERR, and retry without EDNS(0) when the server leaves out
> the question.
> 
> MUST servers reflect the question (on error?) or can they leave it
> out?

It would depend on how much of the question was syntactically parsable.

E.g., when Loop tries to parse a client query message, it parses it in
multiple passes. In the first pass, it tries to see if the UDP
datagram/TCP "message" has enough octets for a message header. If it
doesn't, then it drops the message without any response. If it could
parse the header, it tries to parse the rest of the message. If it could
not even parse the question section in the rest of the message, it would
return a reply message with rcode=FORMERR without a question section in
the reply.

> Is FORMERR special in this regard (not being an answer to a question),
> but an error processing my query packet?

Maybe the outlook.com implementation thinks this question is
syntactically incorrect, and so it can't use it in the reply.

> FWIW, "unbound-host" handles the "empty" FORMERR response, and retries the
> query without EDNS.  Is unbound-host doing what's expected, or employing
> a work-around for known breakage?

Loop's resolver does the same too, and appears to be a workaround (the
code is from 2000 by Bob Halley written for BIND, and it describes the
same). If EDNS is not used in the query and this happens, it abandons
the query completely without trying any other nameservers because it
expects all of them would have trouble with some aspect of this query.

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

Re: [dns-operations] Trouble looking up various axc.nl TLSA RRs via Cloudflare DNS

[Mukund Sivaraman]

On Thu, Oct 03, 2019 at 01:55:04PM -0400, Viktor Dukhovni wrote:
> Probably NTAs based on such data should have a much shorter shelf-life
> than two years, and require some explicit re-confirmation.

You are probably aware that RFC 7646 recommends that NTAs should not
have a lifetime of more than 1 week.

Implementations differ in performing validation tests during NTA
lifetime, and caching entries past NTA removal vs. what's in the RFC.

It is advisable to perform SOA validation as recommended by the RFC
periodically during the lifetime of the NTA.

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

Re: [dns-operations] rndc problems

[Mukund Sivaraman]

Hi Kevin

On Wed, May 27, 2015 at 04:13:55PM +0800, Kevin C. wrote:
 Hello,
 
 Can you tell me why this rndc run failed?
 # rndc reload
 rndc: connection to remote host closed
 This may indicate that
 * the remote server is using an older version of the command protocol,
 * this host is not authorized to connect,
 * the clocks are not synchronized, or
 * the key is invalid.

This is a BIND specific question, which is better discussed on the
bind-users@ list:

https://lists.isc.org/mailman/listinfo/bind-users

As the error says, it could be any of the above reasons. Look in your
named log.

 rndc:
 Version: 9.7.3
 
 named:
 BIND 9.7.3

This is a very old version of BIND that is unsupported and likely has
several security vulnerabilities. Please upgrade to one of the current
versions in the 9.10 or 9.9 branches.

Mukund


pgp75T8OxnNu2.pgp
Description: PGP signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] DNS perf benchmarking tools

[Mukund Sivaraman]

On Thu, Apr 03, 2014 at 06:35:30PM +0530, Mukund Sivaraman wrote:
 On Thu, Apr 03, 2014 at 12:40:55PM +, Brett Carr wrote:
  Is there a standardized/most commonly used tool to benchmark
  performance of a DNS server implementation.
  
  We usually use “queryperf” which is delivered as part of the BIND
  distribution, this takes an input file of queries, sends them to a
  designated server and then reports on the performance:
 
 There is also dnsperf from Nominum and queryperf++ that Jinmei wrote on
 top of libdns++ from the BIND 10 distribution.
 
 http://nominum.com/measurement-tools/
 https://github.com/jinmei/queryperfpp

You may also be interested in CZ.NIC's benchmarking software which they
use to test Knot against various implementations:

https://gitlab.labs.nic.cz/labs/dns-benchmarking/tree/master

Mukund


pgp8nvLOeN1tS.pgp
Description: PGP signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Fwd: [AusNOG] Layer 7 - Distrusted Source (within a single AS) Distrusted Distention - Denial of Service Attack

[Mukund Sivaraman]

On Tue, Oct 15, 2013 at 03:58:10AM +, Dobbins, Roland wrote:
 What we have noticed however is all the attack traffic regardless of
 the source, distention, targeted URL or query has a common pattern
 matching signature of \50\fa\00\08\00\01\20 common to every packet
 generated from this substantial botnet which is frequently published
 on this amplification attack
 webpage. http://dnsamplificationattacks.blogspot.com.au/

We don't know where the magic string \50\fa\00\08\00\01\20 appears in
the packet. I could not quickly find it at the URL above. This sequence
may not have a bad origin. It could be the EDNS0 client-subnet
extension:

50 fa 00 08 00 01 20 SN aa bb cc dd
^ ^ ^ ^^ ^^ ^^^
  | | |   |  |   `-- client IPv4 address
  | | |   |  `-- scope netmask
  | | |   `- source netmask (0x20 = 32 bits)
  | | `- address family (0x0001 = IPv4)
  | `--- option length
  `--- old EDNS0 option code for client subnet

The option code 50fa has been changed now to 8 in
http://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-02,
but you can see this code in older patches to dig:
http://wilmer.gaa.st/edns-client-subnet/bind-9.7.1-dig-edns-client-subnet.diff

But we don't know for sure where in the packet this string came from. :)

Mukund


pgpJ8OB6_lnMW.pgp
Description: PGP signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs