From ogud at ogud.com  Sun May  1 04:18:30 2016
From: ogud at ogud.com (Olafur Gudmundsson)
Date: Sun, 1 May 2016 00:18:30 -0400
Subject: [dns-operations] Adding CNAME for the root domain issue
In-Reply-To: <Pine.LNX.4.53.1604271336350.27552@flame.m3047.net>
References: <20160427205618.52741.qmail@ary.lan> <57212C35.1080907@redbarn.org>
 <Pine.LNX.4.53.1604271336350.27552@flame.m3047.net>
Message-ID: <EBEE60E8-637E-4C1B-94C7-1F87E638B57A@ogud.com>


> On Apr 27, 2016, at 4:42 PM, Fred Morris <m3047 at m3047.net> wrote:
> 
> Top-posting, because I quoted a lot. Ok now I'm a little disturbed.
> 
> To me, this looks like a label which is CNAMED to a zone. What's laid out
> seems like the most straightforward way to accomplish this. Paul, what
> you're saying seems to be that CNAMEs can't just point to anything:
> specifically they can't point to a domain containing NS and SOA records.
> 
> Maybe I'm lazy, and I should go read RFCs...
> 
> Anyway, this line of reasoning suggests to me that once a domain is
> CNAMEd, nothing downstream (a subdomain) can ever be delegated. I'd never
> really thought of it that way before.
> 


99.95% of the requests for CNAME at existing name can be summarized as follows
?If the RR type in question does non exit here please check this other name?. 

This is the same as many people used to believe about wild cards 
i.e. they fill in the blanks 

The ?bad? news is that DNS is not designed that way and 
unless you are only using one vendor that supports features like this you are out of luck. 

   Olafur 




From randy at psg.com  Sun May  1 04:58:48 2016
From: randy at psg.com (Randy Bush)
Date: Sun, 01 May 2016 13:58:48 +0900
Subject: [dns-operations] Adding CNAME for the root domain issue
In-Reply-To: <EBEE60E8-637E-4C1B-94C7-1F87E638B57A@ogud.com>
References: <20160427205618.52741.qmail@ary.lan> <57212C35.1080907@redbarn.org>
 <Pine.LNX.4.53.1604271336350.27552@flame.m3047.net>
 <EBEE60E8-637E-4C1B-94C7-1F87E638B57A@ogud.com>
Message-ID: <m2h9eiqsqf.wl%randy@psg.com>

> 99.95% of the requests for CNAME at existing name can be summarized as
> follows ?If the RR type in question does not exit here please check
> this other name?.
> 
> This is the same as many people used to believe about wild cards
> i.e. they fill in the blanks
> 
> The ?bad? news is that DNS is not designed that way and unless you are
> only using one vendor that supports features like this you are out of
> luck.

[ emphasizing agreement ]

unless the whole world is using ...  the dns is global.  this discussion
is yet another rinse repeat.  realio truelio, if there is a cname, it
MUST be the only RR at that label.

people with other beliefs are welcome, nae encouraged, to break their
own zones.  i prefer not to communicate with them anyway.

randy



From aboling at gmail.com  Sun May  1 05:26:22 2016
From: aboling at gmail.com (Andrew Boling)
Date: Sun, 1 May 2016 01:26:22 -0400
Subject: [dns-operations] Adding CNAME for the root domain issue
In-Reply-To: <m2h9eiqsqf.wl%randy@psg.com>
References: <20160427205618.52741.qmail@ary.lan> <57212C35.1080907@redbarn.org>
 <Pine.LNX.4.53.1604271336350.27552@flame.m3047.net>
 <EBEE60E8-637E-4C1B-94C7-1F87E638B57A@ogud.com>
 <m2h9eiqsqf.wl%randy@psg.com>
Message-ID: <CAPnMbcyHWQRPRTxPhVueYTSneCzTT=VnG8+FZU6m2G6gjCLhnA@mail.gmail.com>

On Sun, May 1, 2016 at 12:58 AM, Randy Bush <randy at psg.com> wrote:

> if there is a cname, it MUST be the only RR at that label.
>
>
There are well-documented exceptions (DNSSEC related rrtypes), but
otherwise yes. </pedant>

Just trying to avoid another lap around the track.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160501/57432507/attachment.html>

From randy at psg.com  Sun May  1 05:32:14 2016
From: randy at psg.com (Randy Bush)
Date: Sun, 01 May 2016 14:32:14 +0900
Subject: [dns-operations] Adding CNAME for the root domain issue
In-Reply-To: <CAPnMbcyHWQRPRTxPhVueYTSneCzTT=VnG8+FZU6m2G6gjCLhnA@mail.gmail.com>
References: <20160427205618.52741.qmail@ary.lan> <57212C35.1080907@redbarn.org>
 <Pine.LNX.4.53.1604271336350.27552@flame.m3047.net>
 <EBEE60E8-637E-4C1B-94C7-1F87E638B57A@ogud.com>
 <m2h9eiqsqf.wl%randy@psg.com>
 <CAPnMbcyHWQRPRTxPhVueYTSneCzTT=VnG8+FZU6m2G6gjCLhnA@mail.gmail.com>
Message-ID: <m2eg9mqr6p.wl%randy@psg.com>

>> if there is a cname, it MUST be the only RR at that label.
> There are well-documented exceptions (DNSSEC related rrtypes), but
> otherwise yes. </pedant>

point


From dwessels at verisign.com  Mon May  2 21:58:58 2016
From: dwessels at verisign.com (Wessels, Duane)
Date: Mon, 2 May 2016 21:58:58 +0000
Subject: [dns-operations] CFP: DNS Track at NANOG 67
Message-ID: <979BCE56-3666-41FB-8EC8-3C32D5A09D05@verisign.com>

Greetings,

NANOG 67 takes place June 11-13 in Chicago.  I'm looking for folks willing to give brief presentations during a proposed DNS Track.  Possible topics include:

- Operational experiences
- New & interesting software features
- Protocol advancements
- Research results
- Performance & compliance testing
- Insights into DNS-related attacks

I'm expecting to have about 90 minutes to fill with presentations of about 15 minutes or less.  If you're interested in presenting please respond to me directly.

Duane W.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160502/2092eae7/attachment.sig>

From dwessels at verisign.com  Tue May  3 04:44:14 2016
From: dwessels at verisign.com (Wessels, Duane)
Date: Tue, 3 May 2016 04:44:14 +0000
Subject: [dns-operations] CFP: DNS Track at NANOG 67
In-Reply-To: <979BCE56-3666-41FB-8EC8-3C32D5A09D05@verisign.com>
References: <979BCE56-3666-41FB-8EC8-3C32D5A09D05@verisign.com>
Message-ID: <D236F495-90B9-470C-86A1-AC4A94B1991C@verisign.com>


> On May 2, 2016, at 2:58 PM, Wessels, Duane <dwessels at verisign.com> wrote:
> 
> NANOG 67 takes place June 11-13 in Chicago

Correction: June 13-15.  At least I got the city right.

DW


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160503/999e3066/attachment.sig>

From dot at dotat.at  Tue May  3 10:11:30 2016
From: dot at dotat.at (Tony Finch)
Date: Tue, 3 May 2016 11:11:30 +0100
Subject: [dns-operations] Adding CNAME for the root domain issue
In-Reply-To: <20160429203420.1159.qmail@ary.lan>
References: <20160429203420.1159.qmail@ary.lan>
Message-ID: <alpine.DEB.2.11.1605031104460.3942@grey.csi.cam.ac.uk>

John Levine <johnl at taugh.com> wrote:
>
> It would be nice to hear from people who were there at the time, but
> until then, RFC 1033 says:

It's worth looking at RFC 882 and RFC 973 for the pre-standard history.
CNAME was originally a fallback, so the canonical/target name was only
used if the queried type was missing at the alias/owner name. This was
changed because:

      The specification allows CNAME RRs to exist with other RRs at the
      same node.  This creates difficulties since the other RRs stored
      with the CNAME at the alias might not agree with the RRs stored at
      the primary name.

      If a node has a CNAME RR, it should have no other RRs.

The pre-standard logic would have worked nicely for CNAME-at-apex.

> RFC 1912 says: [...]
>
> It then describes workarounds for CNAME related bugs in BIND which I hope
> have been fixed in the intervening 20 years.

The paragraph that mentions BIND (quoted below) talks about NS records
pointing at CNAME aliases, which are still deliberately ignored by BIND.

   Having NS records pointing to a CNAME is bad and may conflict badly
   with current BIND servers.  In fact, current BIND implementations
   will ignore such records, possibly leading to a lame delegation.
   There is a certain amount of security checking done in BIND to
   prevent spoofing DNS NS records.  Also, older BIND servers reportedly
   will get caught in an infinite query loop trying to figure out the
   address for the aliased nameserver, causing a continuous stream of
   DNS requests to be sent.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
South Biscay: Variable 4, becoming easterly 5 or 6, occasionally 7 in
southwest. Moderate or rough. Mainly fair. Mainly good.


From markjr at easydns.com  Tue May  3 15:42:18 2016
From: markjr at easydns.com (Mark Jeftovic)
Date: Tue, 3 May 2016 11:42:18 -0400
Subject: [dns-operations] The Use of TTL for IPv4 and IPv6 RRs...
Message-ID: <cc9b545a-07ff-08e5-bc4b-040be378354d@easydns.com>

RFC4472 talks about this situation:

example.com.        300    IN    MX     foo.example.com.
      foo.example.com.    300    IN    A      192.0.2.1
      foo.example.com.    100    IN    AAAA   2001:db8::1

and what can happen.

My first reaction was "so keep the TTLs the same then", but that doesn't
guarantee that the A and AAAA RRs will get queried and cached by the
resolver at the same time time, does it?

So even if you do that, you can still run into the situations described
in 4.4.1 and 4.4.2

Right?

- mark

-- 
Mark Jeftovic, Founder & CEO, easyDNS Technologies Inc.
Company Website: http://easydns.com
Read my blog: http://markable.com
+1-416-535-8672 ext 225


From rharolde at umich.edu  Tue May  3 16:04:23 2016
From: rharolde at umich.edu (Bob Harold)
Date: Tue, 3 May 2016 12:04:23 -0400
Subject: [dns-operations] The Use of TTL for IPv4 and IPv6 RRs...
In-Reply-To: <cc9b545a-07ff-08e5-bc4b-040be378354d@easydns.com>
References: <cc9b545a-07ff-08e5-bc4b-040be378354d@easydns.com>
Message-ID: <CA+nkc8AZG-Ow7yycoFvAePpKOuXEFpik23TM3S07a8m2uHjEpw@mail.gmail.com>

On Tue, May 3, 2016 at 11:42 AM, Mark Jeftovic <markjr at easydns.com> wrote:

> RFC4472 talks about this situation:
>
> example.com.        300    IN    MX     foo.example.com.
>       foo.example.com.    300    IN    A      192.0.2.1
>       foo.example.com.    100    IN    AAAA   2001:db8::1
>
> and what can happen.
>
> My first reaction was "so keep the TTLs the same then", but that doesn't
> guarantee that the A and AAAA RRs will get queried and cached by the
> resolver at the same time time, does it?
>
> So even if you do that, you can still run into the situations described
> in 4.4.1 and 4.4.2
>
> Right?
>
> - mark
>
> --
> Mark Jeftovic, Founder & CEO, easyDNS Technologies Inc.
> Company Website: http://easydns.com
> Read my blog: http://markable.com
> +1-416-535-8672 ext 225
> _______________________________________________
>

It seems to me that according to 4.4.2, the data can only be received with
the NS query, so it would always be received at the same time, and thus
expire at the same time if the TTL's are the same between A and AAAA.   But
you can query the child, and if the TTL's at the child do not match the
parent, or between A and AAAA, then I can see it being an issue.

4.4.1 would still be an issue.

-- 
Bob Harold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160503/2ae5b499/attachment.html>

From paul at redbarn.org  Tue May  3 16:34:13 2016
From: paul at redbarn.org (Paul Vixie)
Date: Tue, 03 May 2016 09:34:13 -0700
Subject: [dns-operations] Adding CNAME for the root domain issue
In-Reply-To: <alpine.DEB.2.11.1605031104460.3942@grey.csi.cam.ac.uk>
References: <20160429203420.1159.qmail@ary.lan>
 <alpine.DEB.2.11.1605031104460.3942@grey.csi.cam.ac.uk>
Message-ID: <5728D305.2060801@redbarn.org>



Tony Finch wrote:
> John Levine<johnl at taugh.com>  wrote:
>> It would be nice to hear from people who were there at the time, but
>> until then, RFC 1033 says:
>
> It's worth looking at RFC 882 and RFC 973 for the pre-standard history.
> CNAME was originally a fallback, so the canonical/target name was only
> used if the queried type was missing at the alias/owner name. This was
> changed because:
>
>        The specification allows CNAME RRs to exist with other RRs at the
>        same node.  This creates difficulties since the other RRs stored
>        with the CNAME at the alias might not agree with the RRs stored at
>        the primary name.
>
>        If a node has a CNAME RR, it should have no other RRs.
>
> The pre-standard logic would have worked nicely for CNAME-at-apex.

what's missing from this text is that with cname in its present form as 
a fallback, it's uncacheable. a cache having some RRsets at a name, upon 
hearing a query for a type it doesn't have, would always have to forward 
to the authority. the cache would then hold synthesized rrsets. probably 
these would have to be sent from the authority with TTL=0.

so, i disagree with your term, "nicely".

>
>> RFC 1912 says: [...]
>>
>> It then describes workarounds for CNAME related bugs in BIND which I hope
>> have been fixed in the intervening 20 years.
>
> The paragraph that mentions BIND (quoted below) talks about NS records
> pointing at CNAME aliases, which are still deliberately ignored by BIND.

not just bind, and not just ns -- see also mx. the NSDNAME is defined as 
the canonical name, specifically and deliberately, to avoid iteration 
during delegation. this is in keeping with CNAME's purpose as 
transitional, for renaming events. only a QNAME can be an alias.

-- 
P Vixie


From dot at dotat.at  Tue May  3 16:51:04 2016
From: dot at dotat.at (Tony Finch)
Date: Tue, 3 May 2016 17:51:04 +0100
Subject: [dns-operations] Adding CNAME for the root domain issue
In-Reply-To: <5728D305.2060801@redbarn.org>
References: <20160429203420.1159.qmail@ary.lan>
 <alpine.DEB.2.11.1605031104460.3942@grey.csi.cam.ac.uk>
 <5728D305.2060801@redbarn.org>
Message-ID: <alpine.DEB.2.11.1605031737250.3942@grey.csi.cam.ac.uk>

Paul Vixie <paul at redbarn.org> wrote:
> Tony Finch wrote:
> >
> > It's worth looking at RFC 882 and RFC 973 for the pre-standard history.
> > CNAME was originally a fallback, so the canonical/target name was only
> > used if the queried type was missing at the alias/owner name. This was
> > changed because:
> >
> >        The specification allows CNAME RRs to exist with other RRs at the
> >        same node.  This creates difficulties since the other RRs stored
> >        with the CNAME at the alias might not agree with the RRs stored at
> >        the primary name.
> >
> >        If a node has a CNAME RR, it should have no other RRs.
> >
> > The pre-standard logic would have worked nicely for CNAME-at-apex.
>
> what's missing from this text is that with cname in its present form as
> a fallback, it's uncacheable. a cache having some RRsets at a name, upon
> hearing a query for a type it doesn't have, would always have to forward
> to the authority. the cache would then hold synthesized rrsets. probably
> these would have to be sent from the authority with TTL=0.
>
> so, i disagree with your term, "nicely".

I don't understand the problem.

I thought what would happen is just like the current per-type positive /
negative cacheing for non-CNAME types. When a cache gets a query for a
type it doesn't have, query the origin, and cache positively or
negatively. If it gets a negative result from the origin or the cache,
look for an old-CNAME (query for it if necessary and cache positively or
negatively per-type as usual); if it gets an old-CNAME from the origin or
the cache, re-do the query at the target.


> > The paragraph that mentions BIND (quoted below) talks about NS records
> > pointing at CNAME aliases, which are still deliberately ignored by BIND.
>
> not just bind, and not just ns -- see also mx.

The mail servers I am familiar with chase CNAME chains. There's some ugly
wording in RFC 5321 resulting from several long flamewars; it tries to say
that MX-pointing-at-CNAME is non-standard but it isn't forbidden because
that's not what running code does.

The key practical difference is that NS-pointing-at-CNAME causes horrible
problems for the DNS resolution process itself; there's no such bootstrap
difficulty for MX or SRV.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
South Utsire: Southwesterly backing southerly 3 or 4, occasionally 5 later.
Slight or moderate. Fair. Good.


From ajs at anvilwalrusden.com  Tue May  3 17:03:36 2016
From: ajs at anvilwalrusden.com (Andrew Sullivan)
Date: Tue, 3 May 2016 13:03:36 -0400
Subject: [dns-operations] Adding CNAME for the root domain issue
In-Reply-To: <alpine.DEB.2.11.1605031737250.3942@grey.csi.cam.ac.uk>
References: <20160429203420.1159.qmail@ary.lan>
 <alpine.DEB.2.11.1605031104460.3942@grey.csi.cam.ac.uk>
 <5728D305.2060801@redbarn.org>
 <alpine.DEB.2.11.1605031737250.3942@grey.csi.cam.ac.uk>
Message-ID: <20160503170336.GN71114@mx2.yitter.info>

On Tue, May 03, 2016 at 05:51:04PM +0100, Tony Finch wrote:
> 
> I thought what would happen is just like the current per-type positive /
> negative cacheing for non-CNAME types.  When a cache gets a query for a
> type it doesn't have, query the origin, and cache positively or
> negatively. If it gets a negative result from the origin or the cache,
> look for an old-CNAME (query for it if necessary and cache positively or
> negatively per-type as usual); if it gets an old-CNAME from the origin or
> the cache, re-do the query at the target.

Given the modern semantics of CNAME, however, this won't work.  If you
got a CNAME RR, it ought to evict anything else at that owner name
from the cache, because nothing else can coexist at the location of
the CNAME RR.  No?

> The mail servers I am familiar with chase CNAME chains.

Yes, most I know do too.

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com


From marka at isc.org  Tue May  3 21:45:54 2016
From: marka at isc.org (Mark Andrews)
Date: Wed, 04 May 2016 07:45:54 +1000
Subject: [dns-operations] Adding CNAME for the root domain issue
In-Reply-To: Your message of "Tue, 03 May 2016 17:51:04 +0100."
 <alpine.DEB.2.11.1605031737250.3942@grey.csi.cam.ac.uk>
References: <20160429203420.1159.qmail@ary.lan>
 <alpine.DEB.2.11.1605031104460.3942@grey.csi.cam.ac.uk>
 <5728D305.2060801@redbarn.org>
 <alpine.DEB.2.11.1605031737250.3942@grey.csi.cam.ac.uk>
Message-ID: <20160503214554.E7C3847E5860@rock.dv.isc.org>


In message <alpine.DEB.2.11.1605031737250.3942 at grey.csi.cam.ac.uk>, Tony Finch 
writes:
> Paul Vixie <paul at redbarn.org> wrote:
> > Tony Finch wrote:
> > >
> > > It's worth looking at RFC 882 and RFC 973 for the pre-standard history.
> > > CNAME was originally a fallback, so the canonical/target name was only
> > > used if the queried type was missing at the alias/owner name. This was
> > > changed because:
> > >
> > >        The specification allows CNAME RRs to exist with other RRs at the
> > >        same node.  This creates difficulties since the other RRs stored
> > >        with the CNAME at the alias might not agree with the RRs stored at
> > >        the primary name.
> > >
> > >        If a node has a CNAME RR, it should have no other RRs.
> > >
> > > The pre-standard logic would have worked nicely for CNAME-at-apex.
> >
> > what's missing from this text is that with cname in its present form as
> > a fallback, it's uncacheable. a cache having some RRsets at a name, upon
> > hearing a query for a type it doesn't have, would always have to forward
> > to the authority. the cache would then hold synthesized rrsets. probably
> > these would have to be sent from the authority with TTL=0.
> >
> > so, i disagree with your term, "nicely".
> 
> I don't understand the problem.
> 
> I thought what would happen is just like the current per-type positive /
> negative cacheing for non-CNAME types. When a cache gets a query for a
> type it doesn't have, query the origin, and cache positively or
> negatively. If it gets a negative result from the origin or the cache,
> look for an old-CNAME (query for it if necessary and cache positively or
> negatively per-type as usual); if it gets an old-CNAME from the origin or
> the cache, re-do the query at the target.
> 
> 
> > > The paragraph that mentions BIND (quoted below) talks about NS records
> > > pointing at CNAME aliases, which are still deliberately ignored by BIND.
> >
> > not just bind, and not just ns -- see also mx.
> 
> The mail servers I am familiar with chase CNAME chains. There's some ugly
> wording in RFC 5321 resulting from several long flamewars; it tries to say
> that MX-pointing-at-CNAME is non-standard but it isn't forbidden because
> that's not what running code does.

MX's pointing at CNAME chains did actually cause real operational
problems resulting in email not being delivered.  Blocking open
SMTP relaying eventually deal with this at the cost of additional
administative overhead.  One no longer queued email on a high
preference MX for later deliver.

> The key practical difference is that NS-pointing-at-CNAME causes horrible
> problems for the DNS resolution process itself; there's no such bootstrap
> difficulty for MX or SRV.

MX processing also changed from 'test name for equality' to 'test
addresses for equality'.  Your SMTP servers need to do more lookups
to determine whether they are a MX on the list of MX's.

SRV doesn't tend to be used for store-and-forward though that is
theoretically possible.  If it is used for store-and-forward it has
the same issues as MX with CNAME targets.

For NS -> CNAME to work reliably you need to have CNAME glue in
addition to A and AAAA glue and also change the rules for adding
additional data to add CNAME record chains as well as A and AAAA
records.  Rather than have hard to diagnose failure modes where NS
-> CNAME works some of the time but not always, named doesn't chase
CNAMEs when looking for addresses to send queries to.  This breaks
so resolutions that would have worked but has easily detectable
signature.

Mark

> Tony.
> -- 
> f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
> South Utsire: Southwesterly backing southerly 3 or 4, occasionally 5 later.
> Slight or moderate. Fair. Good.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From fweimer at redhat.com  Wed May  4 07:05:54 2016
From: fweimer at redhat.com (Florian Weimer)
Date: Wed, 4 May 2016 09:05:54 +0200
Subject: [dns-operations] Increasing the number of search path entries in a
	stub resolver
Message-ID: <57299F52.3080608@redhat.com>

Our stub resolver currently has a hard limit for 6 search domains that 
can be specified in /etc/resolv.conf.  We are considering lifting that 
limit.  Apparently, this is desirable for deployments which migrate from 
NIS host name lookups to DNS because NIS supports a larger number of 
default domain names (or something equivalent to that).

 From a larger ecosystem perspective, do you think that longer search 
paths would increase resolver load in an unacceptable way?  For example, 
host name lookups with a 10-element search path could easily require 20 
queries.

Thanks,
Florian


From nicolas at ncartron.org  Wed May  4 07:39:55 2016
From: nicolas at ncartron.org (Nico CARTRON)
Date: Wed, 4 May 2016 09:39:55 +0200
Subject: [dns-operations] Increasing the number of search path entries
	in a stub resolver
In-Reply-To: <57299F52.3080608@redhat.com>
References: <57299F52.3080608@redhat.com>
Message-ID: <EFEC76E1-CB50-4750-A8B5-44F7C4AF0774@ncartron.org>

Hi Florian,

> On 04 May 2016, at 09:05, Florian Weimer <fweimer at redhat.com> wrote:
> 
> Our stub resolver currently has a hard limit for 6 search domains that can be specified in /etc/resolv.conf.  We are considering lifting that limit.  Apparently, this is desirable for deployments which migrate from NIS host name lookups to DNS because NIS supports a larger number of default domain names (or something equivalent to that).
> 
> From a larger ecosystem perspective, do you think that longer search paths would increase resolver load in an unacceptable way?  For example, host name lookups with a 10-element search path could easily require 20 queries.

How many search domains are you thinking of?
20? 50? No limit?

I've seen Windows clients with long lists (15+); while this didn't really affect resolution times seriously, there was a collateral effect: the cache was much bigger with of course a lot of NXDOMAIN for all the tested search domains. 

-- 
Nico. 



From fweimer at redhat.com  Wed May  4 08:05:25 2016
From: fweimer at redhat.com (Florian Weimer)
Date: Wed, 4 May 2016 10:05:25 +0200
Subject: [dns-operations] Increasing the number of search path entries
 in a stub resolver
In-Reply-To: <EFEC76E1-CB50-4750-A8B5-44F7C4AF0774@ncartron.org>
References: <57299F52.3080608@redhat.com>
 <EFEC76E1-CB50-4750-A8B5-44F7C4AF0774@ncartron.org>
Message-ID: <5729AD45.9090005@redhat.com>

On 05/04/2016 09:39 AM, Nico CARTRON wrote:
> Hi Florian,
>
>> On 04 May 2016, at 09:05, Florian Weimer <fweimer at redhat.com> wrote:
>>
>> Our stub resolver currently has a hard limit for 6 search domains that can be specified in /etc/resolv.conf.  We are considering lifting that limit.  Apparently, this is desirable for deployments which migrate from NIS host name lookups to DNS because NIS supports a larger number of default domain names (or something equivalent to that).
>>
>>  From a larger ecosystem perspective, do you think that longer search paths would increase resolver load in an unacceptable way?  For example, host name lookups with a 10-element search path could easily require 20 queries.
>
> How many search domains are you thinking of?
> 20? 50? No limit?

No limit.  We cannot simply change a constant to increase the limit, so 
removing the limit altogether is no extra effort.

> I've seen Windows clients with long lists (15+); while this didn't really affect resolution times seriously, there was a collateral effect: the cache was much bigger with of course a lot of NXDOMAIN for all the tested search domains.

Interesting observation.  We will likely recommend to run a local stub 
resolver to reduce load somewhat, but the cache size impact will still 
be there.

Thanks,
Florian


From dot at dotat.at  Wed May  4 10:13:07 2016
From: dot at dotat.at (Tony Finch)
Date: Wed, 4 May 2016 11:13:07 +0100
Subject: [dns-operations] Adding CNAME for the root domain issue
In-Reply-To: <20160503170336.GN71114@mx2.yitter.info>
References: <20160429203420.1159.qmail@ary.lan>
 <alpine.DEB.2.11.1605031104460.3942@grey.csi.cam.ac.uk>
 <5728D305.2060801@redbarn.org>
 <alpine.DEB.2.11.1605031737250.3942@grey.csi.cam.ac.uk>
 <20160503170336.GN71114@mx2.yitter.info>
Message-ID: <alpine.DEB.2.11.1605041112130.3942@grey.csi.cam.ac.uk>

Andrew Sullivan <ajs at anvilwalrusden.com> wrote:
>
> Given the modern semantics of CNAME, however, this won't work.

Oh absolutely, no way to turn back the clock. I was just musing on an
alternate history....

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Fastnet, Irish Sea: South or southwest 5 or 6. Moderate, occasionally rough.
Occasional drizzle later. Good, occasionally moderate later.


From paul at redbarn.org  Wed May  4 10:14:43 2016
From: paul at redbarn.org (Paul Vixie)
Date: Wed, 04 May 2016 03:14:43 -0700
Subject: [dns-operations] Increasing the number of search path entries
 in a stub resolver
In-Reply-To: <57299F52.3080608@redhat.com>
References: <57299F52.3080608@redhat.com>
Message-ID: <5729CB93.2090708@redbarn.org>



Florian Weimer wrote:
> Our stub resolver currently has a hard limit for 6 search domains that
> can be specified in /etc/resolv.conf. We are considering lifting that
> limit. Apparently, this is desirable for deployments which migrate from
> NIS host name lookups to DNS because NIS supports a larger number of
> default domain names (or something equivalent to that).
>
>  From a larger ecosystem perspective, do you think that longer search
> paths would increase resolver load in an unacceptable way? For example,
> host name lookups with a 10-element search path could easily require 20
> queries.

above six, i'd hope you sent some or all of the queries in parallel, and 
turned on the round-robin option, to avoid server microbursts.

otherwise this sounds quite reasonable.

-- 
P Vixie


From daniel at digsys.bg  Wed May  4 12:16:16 2016
From: daniel at digsys.bg (Daniel Kalchev)
Date: Wed, 4 May 2016 15:16:16 +0300
Subject: [dns-operations] Adding CNAME for the root domain issue
In-Reply-To: <20160429203420.1159.qmail@ary.lan>
References: <20160429203420.1159.qmail@ary.lan>
Message-ID: <E4E6A58D-6CEF-4BA5-9E40-1EF91608C39E@digsys.bg>


> On 29.04.2016 ?., at 23:34, John Levine <johnl at taugh.com> wrote:
> 
> 
> RFC 1912 says:
> 
>   Don't go overboard with CNAMEs.  Use them when renaming hosts, but
>   plan to get rid of them (and inform your users).  However CNAMEs are
>   useful (and encouraged) for generalized names for servers -- `ftp'
>   for your ftp server, `www' for your Web server, `gopher' for your
>   Gopher server, `news' for your Usenet news server, etc.
> 

Sigh.

We would not have had this discussion, if people were happy to type www.example.com <http://www.example.com/> in their browser, instead of example.com <http://example.com/>.

If enough people were able to say NO, the world would be much better place...

Daniel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160504/cb8d6d21/attachment.html>

From bortzmeyer at nic.fr  Wed May  4 13:20:21 2016
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Wed, 4 May 2016 15:20:21 +0200
Subject: [dns-operations] Adding CNAME for the root domain issue
In-Reply-To: <E4E6A58D-6CEF-4BA5-9E40-1EF91608C39E@digsys.bg>
References: <20160429203420.1159.qmail@ary.lan>
 <E4E6A58D-6CEF-4BA5-9E40-1EF91608C39E@digsys.bg>
Message-ID: <20160504132021.GA21941@nic.fr>

On Wed, May 04, 2016 at 03:16:16PM +0300,
 Daniel Kalchev <daniel at digsys.bg> wrote 
 a message of 80 lines which said:

> We would not have had this discussion, if people were happy to type
> www.example.com <http://www.example.com/> in their browser, instead
> of example.com <http://example.com/>.

The users are perfectly right. We should be able to type
http://example.com/ like we are able to type user at example.com and not
user at mail.example.com. The fault is entirely IETF's, for not using SRV
in the HTTP standard (like every other protocol does).


From johnl at taugh.com  Wed May  4 14:39:30 2016
From: johnl at taugh.com (John R Levine)
Date: 4 May 2016 10:39:30 -0400
Subject: [dns-operations] Adding CNAME for the root domain issue
In-Reply-To: <E4E6A58D-6CEF-4BA5-9E40-1EF91608C39E@digsys.bg>
References: <20160429203420.1159.qmail@ary.lan>
 <E4E6A58D-6CEF-4BA5-9E40-1EF91608C39E@digsys.bg>
Message-ID: <alpine.OSX.2.11.1605041028260.32915@ary.lan>

> We would not have had this discussion, if people were happy to type 
> www.example.com <http://www.example.com/> in their browser, instead of 
> example.com <http://example.com/>.

> If enough people were able to say NO, the world would be much better place...

Blaming the users for poor UI design is an ancient tradition in the 
computer business, but it's never been very productive.

We also would not have this problem if sometime during the past 20 years 
we made our applications use SRV records since it solves nearly all of 
the problems that people are trying to address with funky CNAMEs without 
putting different names in the UI.

Regards,
John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.


From daniel at digsys.bg  Wed May  4 15:16:33 2016
From: daniel at digsys.bg (Daniel Kalchev)
Date: Wed, 4 May 2016 18:16:33 +0300
Subject: [dns-operations] Adding CNAME for the root domain issue
In-Reply-To: <alpine.OSX.2.11.1605041028260.32915@ary.lan>
References: <20160429203420.1159.qmail@ary.lan>
 <E4E6A58D-6CEF-4BA5-9E40-1EF91608C39E@digsys.bg>
 <alpine.OSX.2.11.1605041028260.32915@ary.lan>
Message-ID: <E7A7F4DD-A0E8-4D08-8752-6F3E21371499@digsys.bg>

This is not an UI issue at all. It is actually an issue of bending under pressure. ?users are always right? is an easy excuse, but never the best. Users do what is possible.

The SRV records essentially solve the same issue. But for SRV to be successful, the DNS protocol should be more strict.
If we would not allow for say, A records at the apex, then people would use SRV instead. Of course, it is too late to disallow A records at the apex ? as everyone is convinced by now, that DNS is supposed to work that way.

I know, I know? it is appropriate to use EXAMPLE.COM <http://example.com/> as name server name, ?because the glue is already there??.

Daniel

> On 4.05.2016 ?., at 17:39, John R Levine <johnl at taugh.com> wrote:
> 
>> We would not have had this discussion, if people were happy to type www.example.com <http://www.example.com/> in their browser, instead of example.com <http://example.com/>.
> 
>> If enough people were able to say NO, the world would be much better place...
> 
> Blaming the users for poor UI design is an ancient tradition in the computer business, but it's never been very productive.
> 
> We also would not have this problem if sometime during the past 20 years we made our applications use SRV records since it solves nearly all of the problems that people are trying to address with funky CNAMEs without putting different names in the UI.
> 
> Regards,
> John Levine, johnl at taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160504/1ec421dc/attachment.html>

From johnl at taugh.com  Wed May  4 15:32:47 2016
From: johnl at taugh.com (John R Levine)
Date: 4 May 2016 11:32:47 -0400
Subject: [dns-operations] Adding CNAME for the root domain issue
In-Reply-To: <E7A7F4DD-A0E8-4D08-8752-6F3E21371499@digsys.bg>
References: <20160429203420.1159.qmail@ary.lan>
 <E4E6A58D-6CEF-4BA5-9E40-1EF91608C39E@digsys.bg>
 <alpine.OSX.2.11.1605041028260.32915@ary.lan>
 <E7A7F4DD-A0E8-4D08-8752-6F3E21371499@digsys.bg>
Message-ID: <alpine.OSX.2.11.1605041119420.32915@ary.lan>

> This is not an UI issue at all. It is actually an issue of bending under pressure. ?users are always right? is an easy excuse, but never the best. Users do what is possible.

No, users are always wrong.  But they will do what they do, and a sensible 
designer builds designs that users can use in a reasonable way.  When we 
demand that people use long random passwords and change them every week, 
their reasonable response is to write them on sticky note and stick them 
on their screen.  (The security minded stick them under the desk.) 
Blaming them for not following rules that make no sense to them is a 
complete waste of time.

> The SRV records essentially solve the same issue. But for SRV to be successful, the DNS protocol should be more strict.
> If we would not allow for say, A records at the apex, then people would use SRV instead. Of course, it is too late to disallow A records at the apex ? as everyone is convinced by now, that DNS is supposed to work that way.

Actually, plenty of other protocols use SRV, notably SIP.  HTTP is just 
special.

R's,
John

From support at cloudwebdns.com  Fri May  6 10:16:15 2016
From: support at cloudwebdns.com (support at cloudwebdns.com)
Date: Fri, 06 May 2016 18:16:15 +0800
Subject: [dns-operations] domain has no MX record
Message-ID: <910dda33b46558c5abfd70b1e54149d1@cloudwebdns.com>

I have found this list address has no MX record, lists.ceph.com
you can find their subscribe info at,

http://ceph.com/resources/mailing-list-irc/

So some email systems can not deliver messages to it, such as Aliyun's 
which returns,

(8)lists.ceph.com resolving by dns failed

I know the deliver agent should try A record if there is no MX exists.
But any way lacks MX for a public email domain is not good practical.

Is it? :p



From bortzmeyer at nic.fr  Fri May  6 11:04:21 2016
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Fri, 6 May 2016 13:04:21 +0200
Subject: [dns-operations] domain has no MX record
In-Reply-To: <910dda33b46558c5abfd70b1e54149d1@cloudwebdns.com>
References: <910dda33b46558c5abfd70b1e54149d1@cloudwebdns.com>
Message-ID: <20160506110421.GA28666@nic.fr>

On Fri, May 06, 2016 at 06:16:15PM +0800,
 support at cloudwebdns.com <support at cloudwebdns.com> wrote 
 a message of 21 lines which said:

> I have found this list address has no MX record, lists.ceph.com
> you can find their subscribe info at,
> 
> http://ceph.com/resources/mailing-list-irc/

The domain advertised in these pages seems to be ceph.com, not
lists.ceph.com and ceph.com does have a MX record.


From randy at psg.com  Fri May  6 11:33:19 2016
From: randy at psg.com (Randy Bush)
Date: Fri, 06 May 2016 20:33:19 +0900
Subject: [dns-operations] domain has no MX record
In-Reply-To: <910dda33b46558c5abfd70b1e54149d1@cloudwebdns.com>
References: <910dda33b46558c5abfd70b1e54149d1@cloudwebdns.com>
Message-ID: <m2futvmneo.wl%randy@psg.com>

> I have found this list address has no MX record, lists.ceph.com
> you can find their subscribe info at,
> 
> http://ceph.com/resources/mailing-list-irc/
> 
> So some email systems can not deliver messages to it

yes, there are broken mtas out there.  perhaps fixing them is
where the energy should go.

randy


From bortzmeyer at nic.fr  Mon May  9 08:12:28 2016
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Mon, 9 May 2016 10:12:28 +0200
Subject: [dns-operations] domain has no MX record
In-Reply-To: <6ce4afa276d7c1199d9255566e665165@cloudwebdns.com>
References: <910dda33b46558c5abfd70b1e54149d1@cloudwebdns.com>
 <20160506110421.GA28666@nic.fr>
 <6ce4afa276d7c1199d9255566e665165@cloudwebdns.com>
Message-ID: <20160509081227.GA22780@nic.fr>

On Sat, May 07, 2016 at 06:54:50AM +0800,
 support at cloudwebdns.com <support at cloudwebdns.com> wrote 
 a message of 21 lines which said:

> when you click the subscribe button, the address is related to
> lists.ceph.com, like this one,
> ceph-users-join at lists.ceph.com
> 
> but lists.ceph.com does have no MX setup.

OK, but it has a A, so it should work (RFC 5321, "If an empty list of
MXs is returned, the address is treated as if it was associated with
an implicit MX RR, with a preference of 0, pointing to that host"). If
it does not, it means the sending mail server is broken, as simple as
that.


From sgraves at dns-oarc.net  Mon May  9 22:40:24 2016
From: sgraves at dns-oarc.net (Sue Graves)
Date: Mon, 9 May 2016 15:40:24 -0700
Subject: [dns-operations] Notice: DNS-OARC Systems Facility Relocation May
	14-18th
Message-ID: <573111D8.2060704@dns-oarc.net>


Please be advised that DNS-OARC will be relocating its equipment and
services to a new facility during next week starting this Saturday,
May 14th thru Wednesday the 18th.  There will be multiple sporadic
outages during this time affecting ALL services and ALL systems as a
result.

The main public and OARC Member-facing services, including websites,
email, mailing lists, indico and jabber are planned to be re-located
on Sunday 15th, and we hope to keep the total outage down to a few
hours. Our dataset and analysis servers will be taken out of service
on Saturday 14th, and are planned to be back in service late Monday
16th or early Tuesday 17th. All work is planned to be performed during
daytime hours Pacific time (UTC-8).

During the outages, we will post system availability updates on
LinkedIn, Twitter, Facebook, Google+ and Jabber.

Another email confirming recommissioning status will be sent once
email is back up and until we are completed.

If you encounter any issues after we have announced services have been
restored, please contact us via the usual channels of e-mail to
<admin @ dns-oarc.net>, phone to +1 650 423 1344, or on jabber.

Thanks in advance for your patience and cooperation, and our apologies
for any inconvenience this might unavoidably cause.
Once we are up and running in our new home we'll be in a strengthened
position to support and improve the quality, connectivity and growth
of our services to our Members and the DNS Community.

DNS-OARC Staff
~~~~
https://www.facebook.com/DNS-OARC-1706328039584929/?fref=ts

https://www.linkedin.com/groups/3193714

https://medium.com/dns-oarc-news

https://twitter.com/dnsoarc

https://plus.google.com/s/dns-oarc


From julie.hedlund at icann.org  Thu May 12 18:02:18 2016
From: julie.hedlund at icann.org (Julie Hedlund)
Date: Thu, 12 May 2016 18:02:18 +0000
Subject: [dns-operations] REMINDER: Call for Participation -- ICANN DNSSEC
 Workshop at ICANN 56 in Helsinki, Finland
Message-ID: <5A803022-2D23-4858-A11F-54B78C836024@icann.org>

REMINDER: Call for Participation -- ICANN DNSSEC Workshop at ICANN 56 in Helsinki, Finland

 

The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop at the ICANN 56 meeting on 27 June 2016 in Helsinki, Finland.  The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments.  For reference, the most recent session was held at the ICANN meeting in Marrakech, Morocco on 09 March 2016. The presentations and transcripts are available at:  https://meetings.icann.org/en/marrakech55/schedule/wed-dnssec. 

 

Examples of the types of topics we are seeking include:

 

1. DNSSEC Deployment Challenges

 

The program committee is seeking input from those that are interested in implementation of DNSSEC but have general or particular concerns with DNSSEC.  In particular, we are seeking input from individuals that would be willing to participate in a panel that would discuss questions of the nature:

? What are your most significant concerns with DNSSEC, e.g., implementation, operation or something else?

? What do you expect DNSSEC to do for you and what doesn't it do?

? What do you see as the most important trade-offs with respect to doing or not doing DNSSEC?

 

We are interested in presentations related to any aspect of DNSSEC such as zone signing, DNS response validation, applications use of DNSSEC, registry/registrar DNSSEC activities, etc.

 

2.  DNSSEC by Default

 

As more and more applications and systems are available with DNSSEC enabled by default, the vast majority of today?s applications support DNSSEC but are not DNSSEC enabled by default.    Are we ready to enable DNSSEC by default in all applications and services. We are interested in presentations by implementors on the reasoning that led to enable DNSSEC by default in their product or service.  We are also interested in understanding  those that elected not to enable DNSSEC by default and why, and what their plans are.

 

3. DNSSEC Encryption Algorithms

 

How do we make DNSSEC even more secure through the use of elliptic curve cryptography? What are the advantages of algorithms based on elliptic curves? And what steps need to happen to make this a reality? What challenges lie in the way?  Over the past few months there have been discussions within the DNSSEC community about how we start down the path toward adding support for new cryptographic algorithms such as Ed25519 and Ed448. At ICANN 55 in Marrakech we had a panel session that explored why elliptic curve cryptography was interesting and some high level views on what needs to happen.  At ICANN 56 we are interested in presentations that dive into greater detail about what needs to be done and how we start the process. More background information can be found in this document: https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-crypto-algs/

 

In addition, we welcome suggestions for additional topics.

 

If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-helsinki at isoc.org by **Wednesday, 18 May 2016**

 

We hope that you can join us.

 

Thank you,

Julie Hedlund

 

On behalf of the DNSSEC Workshop Program Committee:

 

Mark Elkins, DNS/ZACR

Cath Goulding, Nominet UK

Jean Robert Hountomey, AfricaCERT

Jacques Latour, .CA

Xiaodong Lee, CNNIC

Luciano Minuchin, NIC.AR

Russ Mundy, Parsons

Ond?ej Sur?, CZ.NIC

Yoshiro Yoneya, JPRS

Dan York, Internet Society

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160512/e39ac546/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4630 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160512/e39ac546/attachment.bin>

From sgraves at dns-oarc.net  Fri May 13 05:05:55 2016
From: sgraves at dns-oarc.net (Sue Graves)
Date: Thu, 12 May 2016 22:05:55 -0700
Subject: [dns-operations] Notice: DNS-OARC Systems Facility Relocation May
	14-18th
In-Reply-To: <573111D8.2060704@dns-oarc.net>
References: <573111D8.2060704@dns-oarc.net>
Message-ID: <7cfea589-a069-53e0-03a7-02d9472d2d5b@dns-oarc.net>

Reminder...

On 5/9/2016 3:40 PM, Sue Graves wrote:
> 
> Please be advised that DNS-OARC will be relocating its equipment and
> services to a new facility during next week starting this Saturday,
> May 14th thru Wednesday the 18th.  There will be multiple sporadic
> outages during this time affecting ALL services and ALL systems as a
> result.
> 
> The main public and OARC Member-facing services, including websites,
> email, mailing lists, indico and jabber are planned to be re-located
> on Sunday 15th, and we hope to keep the total outage down to a few
> hours. Our dataset and analysis servers will be taken out of service
> on Saturday 14th, and are planned to be back in service late Monday
> 16th or early Tuesday 17th. All work is planned to be performed during
> daytime hours Pacific time (UTC-8).
> 
> During the outages, we will post system availability updates on
> LinkedIn, Twitter, Facebook, Google+ and Jabber.
> 
> Another email confirming recommissioning status will be sent once
> email is back up and until we are completed.
> 
> If you encounter any issues after we have announced services have been
> restored, please contact us via the usual channels of e-mail to
> <admin @ dns-oarc.net>, phone to +1 650 423 1344, or on jabber.
> 
> Thanks in advance for your patience and cooperation, and our apologies
> for any inconvenience this might unavoidably cause.
> Once we are up and running in our new home we'll be in a strengthened
> position to support and improve the quality, connectivity and growth
> of our services to our Members and the DNS Community.
> 
> DNS-OARC Staff
> ~~~~
> https://www.facebook.com/DNS-OARC-1706328039584929/?fref=ts
> 
> https://www.linkedin.com/groups/3193714
> 
> https://medium.com/dns-oarc-news
> 
> https://twitter.com/dnsoarc
> 
> https://plus.google.com/s/dns-oarc
> 


From sgraves at dns-oarc.net  Wed May 18 02:27:47 2016
From: sgraves at dns-oarc.net (Sue Graves)
Date: Tue, 17 May 2016 19:27:47 -0700
Subject: [dns-operations] The DNS-OARC facility relocation is complete
Message-ID: <b0608928-b0b6-8826-bb10-2e48ac1bcaec@dns-oarc.net>

Thanks for your patience during this time.

Please let us know if you notice any issues with any of our services or
connectivity.

Best Regards,
Sue


From wanrunxia at aliyun.com  Wed May 18 06:50:27 2016
From: wanrunxia at aliyun.com (RunxiaWan)
Date: Wed, 18 May 2016 14:50:27 +0800
Subject: [dns-operations] Tools to assemble fragments
Message-ID: <009501d1b0d1$90c24800$b246d800$@aliyun.com>

Hi, everyone,
I am doing a data analysis work for the queries and responses captured in my
recursive server. I find the DNS data has some fragments due to large DNS
package and it is tricky to assemble them. Would anyone tell me any works of
assembling IP layer fragments or any tools to parse DNS message from
tcpdump/dnscap data?




Best
Runxia Wan

---------------
Runxia Wan(Brian)
Research Engineer
BII Lab
Beijing Internet Institute(BII)
rxwan at biigroup.cn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160518/b804511f/attachment.html>

From paul at redbarn.org  Wed May 18 13:48:04 2016
From: paul at redbarn.org (P Vixie)
Date: Wed, 18 May 2016 13:48:04 +0000
Subject: [dns-operations] Tools to assemble fragments
In-Reply-To: <009501d1b0d1$90c24800$b246d800$@aliyun.com>
References: <009501d1b0d1$90c24800$b246d800$@aliyun.com>
Message-ID: <478B16BE-2633-422A-8470-FC29F72D18C2@redbarn.org>

Dnscap has an ip reassembler in it.

On May 18, 2016 9:50:27 AM GMT+03:00, RunxiaWan <wanrunxia at aliyun.com> wrote:
>Hi, everyone,
>I am doing a data analysis work for the queries and responses captured
>in my
>recursive server. I find the DNS data has some fragments due to large
>DNS
>package and it is tricky to assemble them. Would anyone tell me any
>works of
>assembling IP layer fragments or any tools to parse DNS message from
>tcpdump/dnscap data?
>
>
>
>
>Best
>Runxia Wan
>
>---------------
>Runxia Wan(Brian)
>Research Engineer
>BII Lab
>Beijing Internet Institute(BII)
>rxwan at biigroup.cn
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>dns-operations mailing list
>dns-operations at 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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160518/9910a393/attachment.html>

From rxwan at biigroup.cn  Wed May 18 06:44:23 2016
From: rxwan at biigroup.cn (=?gb2312?B?zfLI88/E?=)
Date: Wed, 18 May 2016 14:44:23 +0800
Subject: [dns-operations] Tools to assemble fragments
Message-ID: <008701d1b0d0$b7405db0$25c11910$@biigroup.cn>

Hi, everyone,
I am doing a data analysis work for the queries and responses captured in my
recursive server. I find the DNS data has some fragments due to large DNS
package and it is tricky to assemble them. Would anyone tell me any works of
assembling IP layer fragments or any tools to parse DNS message from
tcpdump/dnscap data?




Best
Runxia Wan

---------------
Runxia Wan(Brian)
Research Engineer
BII Lab
Beijing Internet Institute(BII)
rxwan at biigroup.cn


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160518/d5b09ed2/attachment.html>

From Francis.Dupont at fdupont.fr  Wed May 18 15:59:35 2016
From: Francis.Dupont at fdupont.fr (Francis Dupont)
Date: Wed, 18 May 2016 17:59:35 +0200
Subject: [dns-operations] Tools to assemble fragments
In-Reply-To: Your message of Wed, 18 May 2016 14:50:27 +0800.
 <009501d1b0d1$90c24800$b246d800$@aliyun.com>
Message-ID: <201605181559.u4IFxZ1m093083@givry.fdupont.fr>

 In your previous mail you wrote:

>  I am doing a data analysis work for the queries and responses captured in my
>  recursive server. I find the DNS data has some fragments due to large DNS
>  package and it is tricky to assemble them. Would anyone tell me any works of
>  assembling IP layer fragments or any tools to parse DNS message from
>  tcpdump/dnscap data?

=> there were some scripts to perform IP reassembly or even TCP stream
recovery on tcpdump output but today the simpler is to use wireshark
which can read pcap capture files too (or tshark if you don't want
a graphical tool).

Regards

Francis.Dupont at fdupont.fr


From songlinjian at gmail.com  Wed May 18 16:42:25 2016
From: songlinjian at gmail.com (songlinjian)
Date: Thu, 19 May 2016 00:42:25 +0800
Subject: [dns-operations] Tools to assemble fragments
Message-ID: <vlxm2vsoxm1g23mbgbj5oh5u.1463589749857@email.android.com>

An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160519/25e3058c/attachment.html>

From mphillips at rcgdirect.com  Wed May 18 19:32:50 2016
From: mphillips at rcgdirect.com (Michael Phillips)
Date: Wed, 18 May 2016 19:32:50 +0000
Subject: [dns-operations] Notice: DNS-OARC Systems Facility Relocation
 May	14-18th
In-Reply-To: <7cfea589-a069-53e0-03a7-02d9472d2d5b@dns-oarc.net>
References: <573111D8.2060704@dns-oarc.net>
 <7cfea589-a069-53e0-03a7-02d9472d2d5b@dns-oarc.net>
Message-ID: <1F2DBAC4205624428871568713E9352931B844C1@350-SRV-EXCH1.rcgdirect.com>

Hi Sue,

I've received no updates since this message prior to the move. Seeking to confirm if all went well and that I didn't inadvertently get dropped from the listserv?

Thanks in advance,
M. Phillips

-----Original Message-----
From: dns-operations [mailto:dns-operations-bounces at dns-oarc.net] On Behalf Of Sue Graves
Sent: Friday, May 13, 2016 12:06 AM
To: dns-operations at dns-oarc.net
Subject: [dns-operations] Notice: DNS-OARC Systems Facility Relocation May 14-18th

Reminder...

On 5/9/2016 3:40 PM, Sue Graves wrote:
> 
> Please be advised that DNS-OARC will be relocating its equipment and 
> services to a new facility during next week starting this Saturday, 
> May 14th thru Wednesday the 18th.  There will be multiple sporadic 
> outages during this time affecting ALL services and ALL systems as a 
> result.
> 
> The main public and OARC Member-facing services, including websites, 
> email, mailing lists, indico and jabber are planned to be re-located 
> on Sunday 15th, and we hope to keep the total outage down to a few 
> hours. Our dataset and analysis servers will be taken out of service 
> on Saturday 14th, and are planned to be back in service late Monday 
> 16th or early Tuesday 17th. All work is planned to be performed during 
> daytime hours Pacific time (UTC-8).
> 
> During the outages, we will post system availability updates on 
> LinkedIn, Twitter, Facebook, Google+ and Jabber.
> 
> Another email confirming recommissioning status will be sent once 
> email is back up and until we are completed.
> 
> If you encounter any issues after we have announced services have been 
> restored, please contact us via the usual channels of e-mail to <admin 
> @ dns-oarc.net>, phone to +1 650 423 1344, or on jabber.
> 
> Thanks in advance for your patience and cooperation, and our apologies 
> for any inconvenience this might unavoidably cause.
> Once we are up and running in our new home we'll be in a strengthened 
> position to support and improve the quality, connectivity and growth 
> of our services to our Members and the DNS Community.
> 
> DNS-OARC Staff
> ~~~~
> https://www.facebook.com/DNS-OARC-1706328039584929/?fref=ts
> 
> https://www.linkedin.com/groups/3193714
> 
> https://medium.com/dns-oarc-news
> 
> https://twitter.com/dnsoarc
> 
> https://plus.google.com/s/dns-oarc
> 
_______________________________________________
dns-operations mailing list
dns-operations at 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














? Rosenthal Collins Group 2012 
This email may contain confidential and/or privileged information. If you are not the intended recipient (or have received this email by mistake), please notify the sender immediately and destroy this email. Any unauthorized copying, disclosure or distribution of the material in this email is strictly prohibited. Email transmission security and error-free status cannot be guaranteed as information could be intercepted, corrupted, destroyed, delayed, incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which may arise as a result of email transmission. Rosenthal Collins Group, LLC ("RCG") is a US registered futures commission merchant and a member of the NFA. Certain affiliates of RCG are US registered broker-dealers and members of FINRA and or are FSA licensed in the UK. Except as otherwise indicated, references to RCG also refer to affiliates and ?guaranteed (not ?independent?) introducing brokers? of RCG (collectively "RCG"). RCG does not warrant the accuracy or correctness of any information herein or the appropriateness of any transaction. Information contained herein is obtained from sources believed to be reliable; however, no guarantee to its accuracy is made. Opinions expressed herein are those of the author and not necessarily of RCG. All electronic communications may be reviewed by authorized personnel and may be provided to regulatory authorities or others with a legal right to access such information. At various times, RCG or its affiliates may have positions in, and effect proprietary transactions in, futures, options, securities or other financial instruments which may be referred to herein. Trading in futures, options, securities, derivatives or OTC products entails significant risks which must be understood prior to trading and may not be appropriate for all investors. Past performance of actual trades or strategies is not necessarily indicative of future results. Unless otherwise indicated, nothing contained herein shall be construed as an offer to sell or a solicitation to buy any futures contract, option, security, or derivative, including foreign exchange.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160518/2da24bf0/attachment.html>

From nicolas at ncartron.org  Wed May 18 20:03:34 2016
From: nicolas at ncartron.org (Nico CARTRON)
Date: Wed, 18 May 2016 22:03:34 +0200
Subject: [dns-operations] Notice: DNS-OARC Systems Facility Relocation
 May 14-18th
In-Reply-To: <1F2DBAC4205624428871568713E9352931B844C1@350-SRV-EXCH1.rcgdirect.com>
References: <573111D8.2060704@dns-oarc.net>
 <7cfea589-a069-53e0-03a7-02d9472d2d5b@dns-oarc.net>
 <1F2DBAC4205624428871568713E9352931B844C1@350-SRV-EXCH1.rcgdirect.com>
Message-ID: <etPan.573cca96.ddd9d28.110@Nicolass-MacBook.local>

Hi Michael,

Sue actually posted an update earlier today - using another email thread.

"On 18 May 2016 at 05:12:06, Sue Graves (sgraves at dns-oarc.net) wrote:
Thanks for your patience during this time.?

Please let us know if you notice any issues with any of our services or?
connectivity.?

Best Regards,?
Sue?
_______________________________________________?
dns-operations mailing list?
dns-operations at 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 "

Cheers,
Nico
On 18 May 2016 at 21:58:28, Michael Phillips (mphillips at rcgdirect.com) wrote:

Hi Sue,

I've received no updates since this message prior to the move. Seeking to confirm if all went well and that I didn't inadvertently get dropped from the listserv?

Thanks in advance,
M. Phillips

-----Original Message-----
From: dns-operations [mailto:dns-operations-bounces at dns-oarc.net] On Behalf Of Sue Graves
Sent: Friday, May 13, 2016 12:06 AM
To: dns-operations at dns-oarc.net
Subject: [dns-operations] Notice: DNS-OARC Systems Facility Relocation May 14-18th

Reminder...

On 5/9/2016 3:40 PM, Sue Graves wrote:
>
> Please be advised that DNS-OARC will be relocating its equipment and
> services to a new facility during next week starting this Saturday,
> May 14th thru Wednesday the 18th. There will be multiple sporadic
> outages during this time affecting ALL services and ALL systems as a
> result.
>
> The main public and OARC Member-facing services, including websites,
> email, mailing lists, indico and jabber are planned to be re-located
> on Sunday 15th, and we hope to keep the total outage down to a few
> hours. Our dataset and analysis servers will be taken out of service
> on Saturday 14th, and are planned to be back in service late Monday
> 16th or early Tuesday 17th. All work is planned to be performed during
> daytime hours Pacific time (UTC-8).
>
> During the outages, we will post system availability updates on
> LinkedIn, Twitter, Facebook, Google+ and Jabber.
>
> Another email confirming recommissioning status will be sent once
> email is back up and until we are completed.
>
> If you encounter any issues after we have announced services have been
> restored, please contact us via the usual channels of e-mail to <admin
> @ dns-oarc.net>, phone to +1 650 423 1344, or on jabber.
>
> Thanks in advance for your patience and cooperation, and our apologies
> for any inconvenience this might unavoidably cause.
> Once we are up and running in our new home we'll be in a strengthened
> position to support and improve the quality, connectivity and growth
> of our services to our Members and the DNS Community.
>
> DNS-OARC Staff
> ~~~~
> https://www.facebook.com/DNS-OARC-1706328039584929/?fref=ts
>
> https://www.linkedin.com/groups/3193714
>
> https://medium.com/dns-oarc-news
>
> https://twitter.com/dnsoarc
>
> https://plus.google.com/s/dns-oarc
>
_______________________________________________
dns-operations mailing list
dns-operations at 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
?

?

?

?

? Rosenthal Collins Group 2016If you are not the intended recipient of this message, you may not disclose, print, copy or disseminate this information. If you have received this in error, please reply and notify the sender (only) and delete the message. Unauthorized interception of this e-mail is a violation of federal criminal law. Unless otherwise indicated, this is not intended to be an offer to sell or a solicitation to buy any futures or options on futures contract. RCG or its affiliates may have positions in: futures, options, securities or other financial instruments which may be referred to herein. Trading in futures and options on futures entails significant risks which may not be appropriate for all investors. Past performance is not necessarily indicative of future results. _______________________________________________  
dns-operations mailing list  
dns-operations at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160518/42ff449c/attachment.html>

From keith at dns-oarc.net  Wed May 18 20:41:39 2016
From: keith at dns-oarc.net (Keith Mitchell)
Date: Wed, 18 May 2016 16:41:39 -0400
Subject: [dns-operations] DNS-OARC facility relocation is complete
In-Reply-To: <etPan.573cca96.ddd9d28.110@Nicolass-MacBook.local>
References: <573111D8.2060704@dns-oarc.net>
 <7cfea589-a069-53e0-03a7-02d9472d2d5b@dns-oarc.net>
 <1F2DBAC4205624428871568713E9352931B844C1@350-SRV-EXCH1.rcgdirect.com>
 <etPan.573cca96.ddd9d28.110@Nicolass-MacBook.local>
Message-ID: <573CD383.10002@dns-oarc.net>

Now we're done with the bulk of this work, here's a more detailed status
update:

- all of OARC's primary infrastructure has now been successfully
  relocated from Internet Systems Consortium in Redwood City to
  Hurricane Electric in Fremont, California. I'm pleased to report this
  was done without any significant mishap to our hardware or data.

- we did have some config issues with our ix1 server which led to some
  services being down for a day or two longer than intended, but
  otherwise the move went pretty much according to the announced
  schedule.

- we'll be spending the rest of this week doing testing, debugging,
  documentation and tidy-up.

- one outstanding item is that we need to publish new IP addresses for
  the ODVR resolvers. Otherwise, we believe that all public-facing OARC
  services should be working as normal. Please let us know via
  <admin at dnsoarc.net> if you see anything that is not working the way
  you expect it to.

- I'd like to thank the OARC Engineering team, William and Jerry, for
  their hard work and professionalism in getting this demanding
  migration completed.

- We'd also like to express our thanks to the entire ISC Operations
  team for all their service, support and helpful flexibility over the
  past decade of hosting OARC's infrastructure. Rory Doolin, Dan
  Mahoney, and Jim Martin deserve a special mention in particular.

- As we are now in a facility with a diverse community of tenants and
  plenty of room for growth, this opens some new possibilities for
  our members to submit and access OARC data. It is now possible to
  host your analysis server with OARC, directly interconnect with us,
  or peer with US across SFMIX. We will peer directly with OARC
  Members, and operate an open peering policy via the SFMIX route
  server. Please get in touch if you are interested in doing any of
  these.

Finally, thank you to our Members for their support and patience while
we completed this important work. This enhancement to our stability and
robustness builds on OARC's growth as an independent organization and
puts us in stronger shape for the future.

Keith Mitchell
DNS OARC



From jacques.latour at cira.ca  Wed May 18 20:43:50 2016
From: jacques.latour at cira.ca (Jacques Latour)
Date: Wed, 18 May 2016 20:43:50 +0000
Subject: [dns-operations] TLD Monitoring Tools
Message-ID: <C059877D829F76429F49E0B48705D888DDF04D97@EXCH-01.CORP.CIRA.CA>

Hi,

I'm putting a list of TLD monitoring tools as a resource for all and TLDOPS group, got a couple example below, if you know of a good tools, please let me know.  Anything that provides insight on the TLD.

DNSSEC Checker:
     DNSvis - 			http://dnsviz.net/d/ca/dnssec/

     DNSSEC Early warning: 	http://www.dnssek.info/

DNS STATUS: 
     DNS-OARC TLD Monitoring     https://tldmon.dns-oarc.net/nagios/ 

     RIPE Atlas DNS Monitoring      https://atlas.ripe.net/dnsmon 

SECURITY TOOLS/API/REPORT:
     ?


Thanks,

Jacques




From jerry at dns-oarc.net  Wed May 18 21:07:27 2016
From: jerry at dns-oarc.net (=?UTF-8?Q?Jerry_Lundstr=c3=b6m?=)
Date: Wed, 18 May 2016 23:07:27 +0200
Subject: [dns-operations] TLD Monitoring Tools
In-Reply-To: <C059877D829F76429F49E0B48705D888DDF04D97@EXCH-01.CORP.CIRA.CA>
References: <C059877D829F76429F49E0B48705D888DDF04D97@EXCH-01.CORP.CIRA.CA>
Message-ID: <573CD98F.50900@dns-oarc.net>

Hi Jacques,

On 05/18/16 22:43, Jacques Latour wrote:
> DNSSEC Checker:

Zonalizer (uses Zonemaster)

    https://zonalizer.makeinstall.se

I've been checking all TLDs for half a year now, you can get the direct
results for .CA like this:

    https://zonalizer.makeinstall.se/browse/?ca

Cheers,
Jerry


From marka at isc.org  Wed May 18 22:11:33 2016
From: marka at isc.org (Mark Andrews)
Date: Thu, 19 May 2016 08:11:33 +1000
Subject: [dns-operations] TLD Monitoring Tools
In-Reply-To: Your message of "Wed, 18 May 2016 23:07:27 +0200."
 <573CD98F.50900@dns-oarc.net>
References: <C059877D829F76429F49E0B48705D888DDF04D97@EXCH-01.CORP.CIRA.CA>
 <573CD98F.50900@dns-oarc.net>
Message-ID: <20160518221133.0AB664907105@rock.dv.isc.org>


The EDNS compliance tools at https://ednscomp.isc.org/

In message <573CD98F.50900 at dns-oarc.net>, =?UTF-8?Q?Jerry_Lundstr=c3=b6m?= writ
es:
> Hi Jacques,
> 
> On 05/18/16 22:43, Jacques Latour wrote:
> > DNSSEC Checker:
> 
> Zonalizer (uses Zonemaster)
> 
>     https://zonalizer.makeinstall.se
> 
> I've been checking all TLDs for half a year now, you can get the direct
> results for .CA like this:
> 
>     https://zonalizer.makeinstall.se/browse/?ca
> 
> Cheers,
> Jerry
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From pawal at blipp.com  Wed May 18 23:42:36 2016
From: pawal at blipp.com (Patrik Wallstrom)
Date: Thu, 19 May 2016 01:42:36 +0200
Subject: [dns-operations] TLD Monitoring Tools
In-Reply-To: <C059877D829F76429F49E0B48705D888DDF04D97@EXCH-01.CORP.CIRA.CA>
References: <C059877D829F76429F49E0B48705D888DDF04D97@EXCH-01.CORP.CIRA.CA>
Message-ID: <20160518234236.GB24487@vic20.blipp.com>

On Wed, 18 May 2016, Jacques Latour wrote:

> Hi,
> 
> I'm putting a list of TLD monitoring tools as a resource for all and TLDOPS group, got a couple example below, if you know of a good tools, please let me know.  Anything that provides insight on the TLD.
> 
> DNSSEC Checker:
>      DNSvis - 			http://dnsviz.net/d/ca/dnssec/
> 
>      DNSSEC Early warning: 	http://www.dnssek.info/
> 
> DNS STATUS: 
>      DNS-OARC TLD Monitoring     https://tldmon.dns-oarc.net/nagios/ 
> 
>      RIPE Atlas DNS Monitoring      https://atlas.ripe.net/dnsmon 
> 
> SECURITY TOOLS/API/REPORT:
>      ?

I run Zonemaster on all the TLDs a few times a week. The current
report is always available here: https://tldmonitor.blipp.com/

What's fun with this tool is that you can cross reference IP
addresses, AS numbers and errors just by clicking around on the
links. Useful for finding common factors in mis-configurations. (I
originally made this tool for doing analysis on another set of domains, but it's
useful for doing TLDs as well.)


From matthaeus.wander at uni-due.de  Thu May 19 20:46:03 2016
From: matthaeus.wander at uni-due.de (=?UTF-8?Q?Matth=c3=a4us_Wander?=)
Date: Thu, 19 May 2016 22:46:03 +0200
Subject: [dns-operations] Tools to assemble fragments
In-Reply-To: <009501d1b0d1$90c24800$b246d800$@aliyun.com>
References: <009501d1b0d1$90c24800$b246d800$@aliyun.com>
Message-ID: <71c23c69-6b5e-1b99-4065-3f97f4e6a409@uni-due.de>

Here's a Python 2.7 tool I've used to chew on 240 GBytes of .pcap files:
https://www.vs.uni-due.de/wander/reassemble_dns/

reassemble_write.py reads 1 to n .pcap files, extracts DNS messages and
writes a binary .dns file with all DNS messages. It supports IPv4, IPv6,
UDP and TCP. IP fragments and TCP streams are reassembled.
Depends on dpkt (https://github.com/kbandla/dpkt).

You can use dns_parser.py to parse the .dns file. Depends on dnspython
(www.dnspython.org).
Or implement a parser on your own. The file format is documented in
dns_file_format.txt.

Usage:
> python reassemble_write.py input.pcap output.dns
> python dns_parser.py output.dns

Regards,
Matt

RunxiaWan wrote on 2016-05-18 08:50:
> Hi, everyone,
> 
> I am doing a data analysis work for the queries and responses captured
> in my recursive server. I find the DNS data has some fragments due to
> large DNS packageand it is tricky to assemble them. Would anyone tell me
> any works of assembling IP layer fragments or any tools to parse DNS
> message from tcpdump/dnscap data?
> 
> 
> 
> Best
> 
> Runxia Wan
> 
> 
> ---------------
> Runxia Wan(Brian)
> 
> Research Engineer
> BII Lab
> 
> Beijing Internet Institute(BII)
> 
> _____rxwan at biigroup.cn_<mailto:rxwan at biigroup.cn>
> 
> 
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at 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
> 



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5523 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160519/7585ba62/attachment.bin>

From wanrunxia at aliyun.com  Fri May 20 01:05:17 2016
From: wanrunxia at aliyun.com (RunxiaWan)
Date: Fri, 20 May 2016 09:05:17 +0800
Subject: [dns-operations] =?utf-8?b?562U5aSNOiAgVG9vbHMgdG8gYXNzZW1ibGUg?=
	=?utf-8?q?fragments?=
In-Reply-To: <71c23c69-6b5e-1b99-4065-3f97f4e6a409@uni-due.de>
References: <009501d1b0d1$90c24800$b246d800$@aliyun.com>
 <71c23c69-6b5e-1b99-4065-3f97f4e6a409@uni-due.de>
Message-ID: <001801d1b233$ad0f1ca0$072d55e0$@aliyun.com>

Thanks! That helps a lot!

-----????-----
???: Matth?us Wander [mailto:matthaeus.wander at uni-due.de] 
????: 2016?5?20? 4:46
???: RunxiaWan; dns-operations at dns-oarc.net
??: Re: [dns-operations] Tools to assemble fragments

Here's a Python 2.7 tool I've used to chew on 240 GBytes of .pcap files:
https://www.vs.uni-due.de/wander/reassemble_dns/

reassemble_write.py reads 1 to n .pcap files, extracts DNS messages and
writes a binary .dns file with all DNS messages. It supports IPv4, IPv6,
UDP and TCP. IP fragments and TCP streams are reassembled.
Depends on dpkt (https://github.com/kbandla/dpkt).

You can use dns_parser.py to parse the .dns file. Depends on dnspython
(www.dnspython.org).
Or implement a parser on your own. The file format is documented in
dns_file_format.txt.

Usage:
> python reassemble_write.py input.pcap output.dns
> python dns_parser.py output.dns

Regards,
Matt

RunxiaWan wrote on 2016-05-18 08:50:
> Hi, everyone,
> 
> I am doing a data analysis work for the queries and responses captured
> in my recursive server. I find the DNS data has some fragments due to
> large DNS packageand it is tricky to assemble them. Would anyone tell me
> any works of assembling IP layer fragments or any tools to parse DNS
> message from tcpdump/dnscap data?
> 
> 
> 
> Best
> 
> Runxia Wan
> 
> 
> ---------------
> Runxia Wan(Brian)
> 
> Research Engineer
> BII Lab
> 
> Beijing Internet Institute(BII)
> 
> _____rxwan at biigroup.cn_<mailto:rxwan at biigroup.cn>
> 
> 
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at 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
> 







From berni at birkenwald.de  Fri May 20 08:35:07 2016
From: berni at birkenwald.de (Bernhard Schmidt)
Date: Fri, 20 May 2016 10:35:07 +0200
Subject: [dns-operations] The DNS-OARC facility relocation is complete
In-Reply-To: <b0608928-b0b6-8826-bb10-2e48ac1bcaec@dns-oarc.net>
References: <b0608928-b0b6-8826-bb10-2e48ac1bcaec@dns-oarc.net>
Message-ID: <573ECC3B.1090001@birkenwald.de>

Hi,

> Thanks for your patience during this time.
> 
> Please let us know if you notice any issues with any of our services or
> connectivity.

You're sending mail from an IPv6 host without PTR record, which will
likely result in bounces from GMail, O365 and so on

May 20 10:31:16 mail postfix/smtpd[22209]: NOQUEUE: reject: RCPT from
unknown[2620:ff:c000:1::65]: 450 4.7.1 Client host rejected: cannot find
your hostname, [2620:ff:c000:1::65];
from=<dns-operations-bounces at dns-oarc.net> to=<xxx at xxxx.de> proto=ESMTP
helo=<ix1.dns-oarc.net>

Your rDNS block isn't even delegated at ARIN level.

Bernhard


From bortzmeyer at nic.fr  Sun May 22 15:18:22 2016
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Sun, 22 May 2016 17:18:22 +0200
Subject: [dns-operations] More DNSSEC validators to expect
Message-ID: <20160522151822.GA31809@sources.org>

New version of Linux' systemd has DNSEC validation enabled by default:

http://news.softpedia.com/news/systemd-230-launches-with-dnssec-enabled-by-default-in-systemd-resolved-more-504339.shtml


From dougb at dougbarton.us  Mon May 23 21:14:05 2016
From: dougb at dougbarton.us (Doug Barton)
Date: Mon, 23 May 2016 21:14:05 +0000
Subject: [dns-operations] Increasing the number of search path entries
 in a stub resolver
In-Reply-To: <EFEC76E1-CB50-4750-A8B5-44F7C4AF0774@ncartron.org>
References: <EFEC76E1-CB50-4750-A8B5-44F7C4AF0774@ncartron.org>
 <57299F52.3080608@redhat.com>
Message-ID: <e602710c8de225efde67d1911509d2e0@dougbarton.us>

May 4 2016 12:52 AM, "Nico CARTRON" <nicolas at ncartron.org> wrote:
> Hi Florian,
> 
>> On 04 May 2016, at 09:05, Florian Weimer <fweimer at redhat.com> wrote:
>> 
>> Our stub resolver currently has a hard limit for 6 search domains that can be specified in
>> /etc/resolv.conf. We are considering lifting that limit. Apparently, this is desirable for
>> deployments which migrate from NIS host name lookups to DNS because NIS supports a larger number of
>> default domain names (or something equivalent to that).
>> 
>> From a larger ecosystem perspective, do you think that longer search paths would increase resolver
>> load in an unacceptable way? For example, host name lookups with a 10-element search path could
>> easily require 20 queries.
> 
> How many search domains are you thinking of?
> 20? 50? No limit?
> 
> I've seen Windows clients with long lists (15+); while this didn't really affect resolution times
> seriously, there was a collateral effect: the cache was much bigger with of course a lot of
> NXDOMAIN for all the tested search domains.

My experience is the same as Nico's, in fact I've seen higher numbers when an enterprise that started off with 10 or 12 sites in the search list was undergoing a massive IP address renumbering + domain name refactoring at the same time. So for almost every one of the original names there was now a new version of the same name at the top of the list, and the old names at the bottom; about 20 in all. 

There was a statistically significant change in load on the resolvers, but one of the things we did was refactor the list so that any query for an existing name was answered on the first or second try. So when I say "change" above what I mean is that the load went *down*, since the previous list was a mess. :) The biggest user complaint was that when someone fat-fingered a name it took a measurable amount of time for the NXDOMAIN to come back. But fortunately the goal was to remove the old names from the list down the road, so hopefully they actually did that. 

All that said, I don't see any harm in raising the limit on a Unix'y system, but I would not remove the limit entirely as doing so may introduce a DOS vector. I would set it to something ridiculously high like 30 (or better yet, 31 since it's a prime).  :)

hth,

Doug



From aboling at gmail.com  Mon May 23 21:59:10 2016
From: aboling at gmail.com (Andrew Boling)
Date: Mon, 23 May 2016 17:59:10 -0400
Subject: [dns-operations] Increasing the number of search path entries
 in a stub resolver
In-Reply-To: <5729CB93.2090708@redbarn.org>
References: <57299F52.3080608@redhat.com>
	<5729CB93.2090708@redbarn.org>
Message-ID: <CAPnMbcw3Sja1bkmdBnJ03rtUEghMfuP2SrC=g-Xq-KrMLSG6Dw@mail.gmail.com>

On Wed, May 4, 2016 at 6:14 AM, Paul Vixie <paul at redbarn.org> wrote:
>
>
> above six, i'd hope you sent some or all of the queries in parallel, and
> turned on the round-robin option, to avoid server microbursts.
>
> otherwise this sounds quite reasonable.
>
>
+1. Additionally, deployments not meeting this criteria can run into
significantly delayed resolution times when the first nameserver in
/etc/resolv.conf is unreachable. I've seen scenarios in mixed environments
where /etc/resolv.conf is pointing at domain controllers (directly, no LB),
and the AD admins assume that impact of a downed DC is minimal if one
server still responds. This interacts poorly with applications that are
sensitive to long delays in lookups. If I recall correctly, glibc will make
one attempt against the first server for every DNS search suffix before
moving on to the next server. Please correct me if this has changed in
recent years.

This isn't a new problem, and increasing the number of search domains only
increases the damage that the operators can do to themselves. It's just
worth the periodic reminder.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160523/ce26571c/attachment.html>

From paul at nohats.ca  Tue May 24 05:00:22 2016
From: paul at nohats.ca (Paul Wouters)
Date: Tue, 24 May 2016 01:00:22 -0400 (EDT)
Subject: [dns-operations] More DNSSEC validators to expect
In-Reply-To: <20160522151822.GA31809@sources.org>
References: <20160522151822.GA31809@sources.org>
Message-ID: <alpine.LRH.2.20.1605240052370.24328@bofh.nohats.ca>

On Sun, 22 May 2016, Stephane Bortzmeyer wrote:

> New version of Linux' systemd has DNSEC validation enabled by default:
>
> http://news.softpedia.com/news/systemd-230-launches-with-dnssec-enabled-by-default-in-systemd-resolved-more-504339.shtml

Which sends out all application queries over all interfaces to all
DNS servers, and uses the first answer that comes back irrespective of
DNSSEC status.

This will be bad for split-DNS (VPN) queries and DNS privacy in general,
and additionally will ensure a local attacker will always win from the
real answer.

As it uses nsswitch, it will also still do all of this even if you
run a local validating nameserver. Since systemd-resolved itself
does not cache, at least over time you will get a better chance
of not getting poisoned, if you do run a local DNS server.

systemd-resolvd also implements its own resolver, and uses dbus/xml
to convert DNS queries from wire format to internal format to wire
format before it hits the application. So this requires continuous
active maintanance on the DNS protocol by the software vendor.

I cannot recommend using this software in the current form.

Paul


From jan.vcelak at nic.cz  Tue May 24 08:22:45 2016
From: jan.vcelak at nic.cz (=?UTF-8?Q?Jan_V=c4=8delak?=)
Date: Tue, 24 May 2016 10:22:45 +0200
Subject: [dns-operations] More DNSSEC validators to expect
In-Reply-To: <alpine.LRH.2.20.1605240052370.24328@bofh.nohats.ca>
References: <20160522151822.GA31809@sources.org>
 <alpine.LRH.2.20.1605240052370.24328@bofh.nohats.ca>
Message-ID: <8c37870c-1653-d39e-0638-6d01937ef998@nic.cz>

>> New version of Linux' systemd has DNSEC validation enabled by default:
>>
>> http://news.softpedia.com/news/systemd-230-launches-with-dnssec-enabled-by-default-in-systemd-resolved-more-504339.shtml
> 
> Which sends out all application queries over all interfaces to all
> DNS servers, and uses the first answer that comes back irrespective of
> DNSSEC status.

Let's call it "Opportunistic DNSSEC".

I wonder what is the purpose of DNSSEC=allow-downgrade. Maybe just to
verify that DNSSEC=true is a bad default in many networks and therefore
a bad default for regular users.

I really like this effort of systemd-resolved. But I think that
something similar to dnssec-trigger will be needed in the foreseeable
future anyway.

Jan


From paul at nohats.ca  Thu May 26 13:37:11 2016
From: paul at nohats.ca (Paul Wouters)
Date: Thu, 26 May 2016 09:37:11 -0400 (EDT)
Subject: [dns-operations] More DNSSEC validators to expect
In-Reply-To: <8c37870c-1653-d39e-0638-6d01937ef998@nic.cz>
References: <20160522151822.GA31809@sources.org>
 <alpine.LRH.2.20.1605240052370.24328@bofh.nohats.ca>
 <8c37870c-1653-d39e-0638-6d01937ef998@nic.cz>
Message-ID: <alpine.LRH.2.20.1605260933480.19549@bofh.nohats.ca>

On Tue, 24 May 2016, Jan V?elak wrote:

>>> New version of Linux' systemd has DNSEC validation enabled by default:
>>>
>>> http://news.softpedia.com/news/systemd-230-launches-with-dnssec-enabled-by-default-in-systemd-resolved-more-504339.shtml
>>
>> Which sends out all application queries over all interfaces to all
>> DNS servers, and uses the first answer that comes back irrespective of
>> DNSSEC status.
>
> Let's call it "Opportunistic DNSSEC".

But that's a problem. The design favours the local attacker. So it is
more like "security when not under attack". Applications have no way
of saying "I need a secure answer for this".

Since we are bootstrapping opportunistic security _using_ DNSSEC, you
can't just relay unprotected DNS answers from random sources for what
are really signed zones. That's really breaking the API contract of
the DO/AD bits.

Paul


From bortzmeyer at nic.fr  Fri May 27 08:44:42 2016
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Fri, 27 May 2016 10:44:42 +0200
Subject: [dns-operations] [tjw.ietf@gmail.com: Working Group Last Call:
 draft-ietf-dnsop-nxdomain-cut]
Message-ID: <20160527084442.GC1422@nic.fr>

This proposal may have practical consequences for DNS operations so
people on this list may want to read the draft and to report opinions
on the DNSOP working group mailing list (not to be confused with this
dns-operations mailing list).
-------------- next part --------------
An embedded message was scrubbed...
From: Tim Wicinski <tjw.ietf at gmail.com>
Subject: Working Group Last Call: draft-ietf-dnsop-nxdomain-cut
Date: Thu, 26 May 2016 14:53:06 +0200
Size: 9189
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160527/9e1e726f/attachment.mht>

From bortzmeyer at nic.fr  Sun May 29 08:35:35 2016
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Sun, 29 May 2016 10:35:35 +0200
Subject: [dns-operations] [hello@axfrcheck.com: AXFR Securit - alert -
	XXXXXX.fr]
Message-ID: <20160529083535.GB5639@nic.fr>

We received this since, apparently, they send email to every email
address in the changed: attribute of the whois output :-( (I'm not
involved in the management of this domain name.)

Does anyone know these people who spread FUD about AXFR-enabled
domains?

----- Forwarded message from AXFR Check Team <hello at axfrcheck.com> -----

Date: Sun, 29 May 2016 07:22:38 +0000 (UTC)
From: AXFR Check Team <hello at axfrcheck.com>
To: [many unrelated email addresses]
Subject: AXFR Securit - alert - XXXXXX.fr

   Dear XXXXXX.fr DNS Provider,
   Our research team found some security issue in some of your DNS server
   configurations. These misconfigured DNS are very vulnerable, and easy
   to abuse.

   Here are some of potential affected DNS for example:
   ns.XXXXXX.fr

   Affected domains actually:
   1

   About DNS Zone Transfer AXFR Requests May Leak Domain Information:

   https://www.us-cert.gov/ncas/alerts/TA15-103A

   Check affected DNS and domains on AXFR CHECK API
   http://api.axfrcheck.com/api/provider/XXXXXX.fr

   You can fix the problem if you disbale AXFR transfer on your dns
   servers.

   For example:

   BIND:

   allow-transfer {"none";};

   PowerDNS:

   disable-axfr=yes

   If you need help to configure the setting correctly, reply to this
   email, and we will help you.

   Who we are?
   [1]axfrcheck.com

   If we helped you, or you want to support our work, please [2]DONATE us,
   to help the web a more secure place!

   Regards,
   Zoltan Vigh

   Twitter: [3]@ptzool

   LinkedIn: [4]https://hu.linkedin.com/in/zvigh

   AXFR Check Team

References

   1. http://axfrcheck.com/
   2. http://axfrcheck.com/
   3. https://twitter.com/ptZool
   4. https://hu.linkedin.com/in/zvigh

----- End forwarded message -----


From phoffman at proper.com  Sun May 29 14:00:00 2016
From: phoffman at proper.com (Paul Hoffman)
Date: Sun, 29 May 2016 07:00:00 -0700
Subject: [dns-operations] [hello@axfrcheck.com: AXFR Securit - alert -
 XXXXXX.fr]
In-Reply-To: <20160529083535.GB5639@nic.fr>
References: <20160529083535.GB5639@nic.fr>
Message-ID: <87BAE879-456A-4A33-8858-BFAE65EACBFB@proper.com>

On 29 May 2016, at 1:35, Stephane Bortzmeyer wrote:

> Does anyone know these people who spread FUD about AXFR-enabled
> domains?

He's not completely anonymous: he proudly list his LinkedIn page on the 
web site.

--Paul Hoffman


From davew at hireahit.com  Mon May 30 00:14:06 2016
From: davew at hireahit.com (Dave Warren)
Date: Sun, 29 May 2016 18:14:06 -0600
Subject: [dns-operations] [hello@axfrcheck.com: AXFR Securit - alert -
 XXXXXX.fr]
In-Reply-To: <20160529083535.GB5639@nic.fr>
References: <20160529083535.GB5639@nic.fr>
Message-ID: <574B85CE.4060600@hireahit.com>

On 2016-05-29 02:35, Stephane Bortzmeyer wrote:
> We received this since, apparently, they send email to every email
> address in the changed: attribute of the whois output :-( (I'm not
> involved in the management of this domain name.)
>
> Does anyone know these people who spread FUD about AXFR-enabled
> domains?
>
> ----- Forwarded message from AXFR Check Team <hello at axfrcheck.com> -----
>
<...>
>     4. https://hu.linkedin.com/in/zvigh
>

Dear Zoltan,

My crack team of crack researchers have found some critical security 
issues in your social media profile configurations. These misconfigured 
profiles are very vulnerable and can cause your Personal Information 
including but not limited to your name, occupation, geographical 
location, timezone, and various biometric data open to the public at large.

Here are some potentially affected URLs:
https://hu.linkedin.com/in/zvigh
https://twitter.com/ptzool

Number of affected idiots:
A team of at least 1

About the HTTP protocol and related services:
https://tools.ietf.org/html/rfc2616
https://tools.ietf.org/html/rfc2818
https://www.linkedin.com/about-us
https://about.twitter.com/

You can fix this problem by sticking to shoddy PHP programming and 
limiting your commentary on intentionally publicly available DNS 
information being made available publicly.


-- 
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren




From gihan at nic.lk  Mon May 30 02:56:13 2016
From: gihan at nic.lk (Gihan Dias)
Date: Mon, 30 May 2016 08:26:13 +0530
Subject: [dns-operations] [hello@axfrcheck.com: AXFR Securit - alert -
 XXXXXX.fr]
In-Reply-To: <574B85CE.4060600@hireahit.com>
References: <20160529083535.GB5639@nic.fr> <574B85CE.4060600@hireahit.com>
Message-ID: <957fbe30-f0ee-2f98-fce9-4235b39854f2@nic.lk>

On 2016-05-30 ??.?. 5:44, Dave Warren wrote:
>
> My crack team of crack researchers have found some critical security 
> issues in your social media profile configurations. These 
> misconfigured profiles are very vulnerable and can cause your Personal 
> Information including but not limited to your name, occupation, 
> geographical location, timezone, and various biometric data open to 
> the public at large. 
Dave,

You should have added the
<sarcasm>
...
</sarcasm>
Even then he may not get it.

You may need to be more plain and direct (or send a message in Hungarian).

Gihan


From zool1983 at gmail.com  Mon May 30 09:30:16 2016
From: zool1983 at gmail.com (=?UTF-8?B?Wm9sdMOhbiBWaWdo?=)
Date: Mon, 30 May 2016 09:30:16 +0000
Subject: [dns-operations] AXFR misconfiguration mail
Message-ID: <CABKv_cwJ3TsvOFO+TbukJmefUxDp=9FHGyCp0QoO58NvMV8y9g@mail.gmail.com>

Hi Everybody,

I would like to apologize to everybody. I made a mistake when I sent an
email to DNS providers. I only  wanted to call everyone's attention the
AXFR misconfiguration. It won?t happen again.

I accepted your opinion. Axfr transfer is not problem, it is a matter of
personal choice.

@Dave Warren: Thank you for your opinion!


Regards,

Zolt?n Vigh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160530/5c24bf28/attachment.html>

From peter.van.dijk at powerdns.com  Mon May 30 15:37:51 2016
From: peter.van.dijk at powerdns.com (Peter van Dijk)
Date: Mon, 30 May 2016 17:37:51 +0200
Subject: [dns-operations] More DNSSEC validators to expect
In-Reply-To: <alpine.LRH.2.20.1605240052370.24328@bofh.nohats.ca>
References: <20160522151822.GA31809@sources.org>
 <alpine.LRH.2.20.1605240052370.24328@bofh.nohats.ca>
Message-ID: <A283E525-2824-415D-BF13-0D63CAC69500@powerdns.com>

Hello Paul,

On 24 May 2016, at 7:00, Paul Wouters wrote:

> As it uses nsswitch, it will also still do all of this even if you
> run a local validating nameserver. Since systemd-resolved itself
> does not cache, at least over time you will get a better chance
> of not getting poisoned, if you do run a local DNS server.

Are you sure it does not cache? The man page says it does, and so does 
this (old!) message: http://seclists.org/oss-sec/2014/q4/592

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/


From paul at nohats.ca  Mon May 30 16:08:54 2016
From: paul at nohats.ca (Paul Wouters)
Date: Mon, 30 May 2016 12:08:54 -0400 (EDT)
Subject: [dns-operations] More DNSSEC validators to expect
In-Reply-To: <A283E525-2824-415D-BF13-0D63CAC69500@powerdns.com>
References: <20160522151822.GA31809@sources.org>
 <alpine.LRH.2.20.1605240052370.24328@bofh.nohats.ca>
 <A283E525-2824-415D-BF13-0D63CAC69500@powerdns.com>
Message-ID: <alpine.LRH.2.20.1605301206550.6184@bofh.nohats.ca>

On Mon, 30 May 2016, Peter van Dijk wrote:

>>  As it uses nsswitch, it will also still do all of this even if you
>>  run a local validating nameserver. Since systemd-resolved itself
>>  does not cache, at least over time you will get a better chance
>>  of not getting poisoned, if you do run a local DNS server.
>
> Are you sure it does not cache? The man page says it does, and so does this 
> (old!) message: http://seclists.org/oss-sec/2014/q4/592

You seem to be right. I was going by what I was told at the devconf
DNSSEC meeting where Lennart told me otherwise (or possibly I misunderstood
his statement that resolvd was not a dns caching server)

Paul