George Michaelson | 28 Jan 22:21 2015
Picon

Re: AWS footnote: DNS firewall rules are UDP only

I entirely agree. This is a point-specific issue. 

There are lots of 53 stupidities, but this is one which has a single locus of control which can be viewed as 'tractable'

On 29 January 2015 at 10:09, Paul Hoffman <paul.hoffman-yoAj3PwqdAM@public.gmane.org> wrote:
Are there any Route 53 people on this list? If so, this should be fixed ASAP.

--Paul Hoffman

> On Jan 28, 2015, at 11:28 AM, Fred Morris <m3047-gzKdTEmrlFteoWH0uzbU5w@public.gmane.org> wrote:
>
> I just noticed that when configuring firewall rules for an AWS instance,
> if "DNS" is chosen then the (only) protocol automagically filled in is
> UDP.
>
> To get TCP, you have to create a custom TCP rule.
>
> When you save, the UDP one gets saved as "DNS", the TCP one stays "custom
> TCP rule".


<div>
<div dir="ltr">I entirely agree. This is a point-specific issue.&nbsp;<div><br></div>
<div>There are lots of 53 stupidities, but this is one which has a single locus of control which can be viewed as 'tractable'</div>
</div>
<div class="gmail_extra">
<br><div class="gmail_quote">On 29 January 2015 at 10:09, Paul Hoffman <span dir="ltr">&lt;<a href="mailto:paul.hoffman@..." target="_blank">paul.hoffman@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">Are there any Route 53 people on this list? If so, this should be fixed ASAP.<br><span class="HOEnZb"><br>
--Paul Hoffman<br></span><span class="im HOEnZb"><br>
&gt; On Jan 28, 2015, at 11:28 AM, Fred Morris &lt;<a href="mailto:m3047 <at> m3047.net">m3047@...</a>&gt; wrote:<br>
&gt;<br>
&gt; I just noticed that when configuring firewall rules for an AWS instance,<br>
&gt; if "DNS" is chosen then the (only) protocol automagically filled in is<br>
&gt; UDP.<br>
&gt;<br>
&gt; To get TCP, you have to create a custom TCP rule.<br>
&gt;<br>
&gt; When you save, the UDP one gets saved as "DNS", the TCP one stays "custom<br>
&gt; TCP rule".<br><br></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
dns-operations mailing list<br><a href="mailto:dns-operations@...">dns-operations <at> lists.dns-oarc.net</a><br><a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations%0Adns-jobs" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations<br>
dns-jobs</a> mailing list<br><a href="https://lists.dns-oarc.net/mailman/listinfo/dns-jobs" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-jobs</a><br>
</div></div>
</blockquote>
</div>
<br>
</div>
</div>
Fred Morris | 28 Jan 20:28 2015
Picon

AWS footnote: DNS firewall rules are UDP only

I just noticed that when configuring firewall rules for an AWS instance,
if "DNS" is chosen then the (only) protocol automagically filled in is
UDP.

To get TCP, you have to create a custom TCP rule.

When you save, the UDP one gets saved as "DNS", the TCP one stays "custom
TCP rule".

--

Fred Morris

Marek Vavruša | 27 Jan 10:07 2015
Picon

extra records in resolver answer, any benefit?

Hi, I was wondering if there's any operational benefit in including
records other than direct answer in resolver responses [1]?  For
example, some recursors return authoritative NS records, SOA, glue,
etc., and some servers scrub them. I have utterly failed in finding
anything in the related RFCs to back this up, so I guess it's up to
implementors.

My reasoning is that the end user rarely needs anything but the direct
answer, maybe additional address records for MX, NS and such. But
presuming that most of the resolver traffic is 'IN A
www.populardomain.com'-like, and a lot of traffic originates from
congested mobile networks, it makes sense to me to return only minimal
possible responses.
Or am I wrong?

 - Marek

[1] With the exception of SOA for NODATA and DNSSEC-related data.
Stephen Johnson (DIS | 22 Jan 20:21 2015

Entering DNSSEC waters

I'm about to put my toes into the DNSS waters before something forces be
to dive in head first. I've been researching and doing to tentative
planning as to how to implement DNSSEC for our DNS zones.

I've got a good handle on how we'll doing out key handling and keys
rotations (from RFC6781). What I'm currently lacking is a roll out and
testing plan for the live zones. I've read about the DNSSEC roll outs
that have been discussed on the list.

What I'm asking for is advice and possibly copies of roll out and
testing planes other have used. From those I'll cobble together a roll
plan for our zones.

Thanks in advanced.

--

-- 
Stephen L Johnson  <stephen.johnson@...>
Unix Systems Administrator / DNS Hostmaster
Department of Information Systems
State of Arkansas
501-682-4339

Stephane Bortzmeyer | 18 Jan 11:28 2015
Picon

DNS training at the NSA

On <http://www.spiegel.de/media/media-35658.pdf> p. 9 (NSA slides,
leaked to the press), the DNS resolution process is strange, as if
recursion, instead of iteration, were used by all DNS servers of the
world, including the root name servers. Too much haste in using
PowerPoint? Ignorance? Deliberate attempt to obfuscate the issue?

I'm trying to find out if this NSA attack is a good use case for
DNSSEC.
Mehmet Akcin | 16 Jan 19:31 2015
Picon

cache flush request

colleagues

we need a quick cache flush for windowsmedia.com domain name to resolve a domain resolution issue. can you let me know privately once the cache is flushed?

thanks

mehmet
<div><div dir="ltr">
<div>colleagues</div>
<div><br></div>
<div>we need a quick cache flush for <a href="http://windowsmedia.com">windowsmedia.com</a> domain name to resolve a domain resolution issue. can you let me know privately once the cache is flushed?</div>
<div><br></div>
<div>thanks</div>
<div><br></div>
<div>mehmet</div>
</div></div>
Wessels, Duane | 12 Jan 18:43 2015
Picon

Root and ARPA DNSSEC operational message - signature validity period

DNSSEC signatures in the Root and ARPA zones were initially given a validity
period of 7 days.  The validity period is being increased to 10 days.

Both the Root and ARPA zones publish their NS RRsets with a TTL of 6 days.
A signature validity period of 7 days means that a root server instance
that is not updated within 24 hours may return NS RRset responses whose
TTL exceeds the signature validity.  This could cause problems for validating
recursive name servers that forward queries through non-validators.  A
longer signature validity provides a longer buffer in the distribution of
these zones.

Note that we are not aware of any cases where the 7 day signature validity
period has caused problems for DNSSEC validators.  This is a precautionary
measure.

As of today, the zones now have the increased validity period.  Please
feel free to contact us with concerns or questions.
DNSSEC signatures in the Root and ARPA zones were initially given a validity
period of 7 days.  The validity period is being increased to 10 days.

Both the Root and ARPA zones publish their NS RRsets with a TTL of 6 days.
A signature validity period of 7 days means that a root server instance
that is not updated within 24 hours may return NS RRset responses whose
TTL exceeds the signature validity.  This could cause problems for validating
recursive name servers that forward queries through non-validators.  A
longer signature validity provides a longer buffer in the distribution of
these zones.

Note that we are not aware of any cases where the 7 day signature validity
period has caused problems for DNSSEC validators.  This is a precautionary
measure.

As of today, the zones now have the increased validity period.  Please
feel free to contact us with concerns or questions.
Stephane Bortzmeyer | 9 Jan 13:50 2015
Picon

Sharing a DNSSEC key between zones

I'm looking for resources discussing the pros and cons of sharing
DNSSEC keys between zones.

I find nothing in RFC 6841 or 6781. Any pointer?
Shawn Hsiao | 8 Jan 14:37 2015

issue with m root server from China?


We have reports that some qnames are not resolving properly in China, and in two of the follow ups I have received it appears they are getting random responses directly from the m root server.   Not sure what is causing it, but I am wondering if someone on the list knows.

So far, I am only aware this happening to edgecastcdn.net domain, and other domains we tested are resolving fine.

Thanks.

(from a home computer)
$ dig +trace cs216.wpc.edgecastcdn.net

; <<>> DiG 9.8.3-P1 <<>> +trace cs216.wpc.edgecastcdn.net
;; global options: +cmd
. 23964
IN NS
j.root-servers.net.
. 23964
IN NS
i.root-servers.net.
. 23964
IN NS
g.root-servers.net.
. 23964
IN NS
f.root-servers.net.
. 23964
IN NS
m.root-servers.net.
. 23964
IN NS
h.root-servers.net.
. 23964
IN NS
e.root-servers.net.
. 23964
IN NS
c.root-servers.net.
. 23964
IN NS
a.root-servers.net.
. 23964
IN NS
l.root-servers.net.
. 23964
IN NS
k.root-servers.net.
. 23964
IN NS
b.root-servers.net.
. 23964
IN NS d.root-servers.net.
;; Received 228 bytes from 192.168.1.1#53(192.168.1.1) in 12 ms

cs216.wpc.edgecastcdn.net. 2732 IN A 206.17.103.24
;; Received 84 bytes from 202.12.27.33#53(202.12.27.33) in 100 ms


(from a server in a datacenter)
$ dig +trace cs216.wpc.edgecastcdn.net

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> +trace cs216.wpc.edgecastcdn.net
;; global options: +cmd
.
498401 IN
NS b.root-servers.net.
.
498401 IN
NS i.root-servers.net.
.
498401 IN
NS c.root-servers.net.
.
498401 IN
NS a.root-servers.net.
.
498401 IN
NS l.root-servers.net.
.
498401 IN
NS j.root-servers.net.
.
498401 IN
NS e.root-servers.net.
.
498401 IN
NS m.root-servers.net.
.
498401 IN
NS g.root-servers.net.
.
498401 IN
NS k.root-servers.net.
.
498401 IN
NS h.root-servers.net.
.
498401 IN
NS d.root-servers.net.
.
498401 IN
NS f.root-servers.net.
;; Received 508 bytes from 192.168.4.192#53(192.168.4.192) in 8419 ms

cs216.wpc.edgecastcdn.net. 1911
IN A
54.210.250.207
;; Received 59 bytes from 202.12.27.33#53(202.12.27.33) in 3 ms

---
// Shawn




<div>
<div><br></div>
<div>We have reports that some qnames are not resolving properly in China, and in two of the follow ups I have received it appears they are getting random responses directly from the m root server. &nbsp; Not sure what is causing it, but I am wondering if someone
 on the list knows.</div>
<div><br></div>
<div>So far, I am only aware this happening to <a href="http://edgecastcdn.net">edgecastcdn.net</a> domain, and other domains we tested are resolving fine.</div>
<div><br></div>
<div>Thanks.</div>
<div><br></div>
<div>(from a home computer)</div>
<div>$ dig +trace&nbsp;<a href="http://cs216.wpc.edgecastcdn.net">cs216.wpc.edgecastcdn.net</a><br><br>
; &lt;&lt;&gt;&gt; DiG 9.8.3-P1 &lt;&lt;&gt;&gt; +trace&nbsp;cs216.wpc.edgecastcdn.net<br>
;; global options: +cmd<br>
.&nbsp;23964<br>
IN&nbsp;NS<br>
j.root-servers.net.<br>
.&nbsp;23964<br>
IN&nbsp;NS<br>
i.root-servers.net.<br>
.&nbsp;23964<br>
IN&nbsp;NS<br>
g.root-servers.net.<br>
.&nbsp;23964<br>
IN&nbsp;NS<br>
f.root-servers.net.<br>
.&nbsp;23964<br>
IN&nbsp;NS<br>
m.root-servers.net.<br>
.&nbsp;23964<br>
IN&nbsp;NS<br>
h.root-servers.net.<br>
.&nbsp;23964<br>
IN&nbsp;NS<br>
e.root-servers.net.<br>
.&nbsp;23964<br>
IN&nbsp;NS<br>
c.root-servers.net.<br>
.&nbsp;23964<br>
IN&nbsp;NS<br>
a.root-servers.net.<br>
.&nbsp;23964<br>
IN&nbsp;NS<br>
l.root-servers.net.<br>
.&nbsp;23964<br>
IN&nbsp;NS<br>
k.root-servers.net.<br>
.&nbsp;23964<br>
IN&nbsp;NS<br>
b.root-servers.net.<br>
.&nbsp;23964<br>
IN&nbsp;NS&nbsp;d.root-servers.net.<br>
;; Received 228 bytes from 192.168.1.1#53(192.168.1.1) in 12 ms<br><br>
cs216.wpc.edgecastcdn.net. 2732&nbsp;IN&nbsp;A&nbsp;206.17.103.24<br>;; Received 84 bytes from 202.12.27.33#53(202.12.27.33) in 100 ms<br><br>
</div>
<div><br></div>
<div>(from a server in a datacenter)</div>
<div>$ dig +trace&nbsp;<a href="http://cs216.wpc.edgecastcdn.net">cs216.wpc.edgecastcdn.net</a><br><br>
; &lt;&lt;&gt;&gt; DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 &lt;&lt;&gt;&gt; +trace&nbsp;cs216.wpc.edgecastcdn.net<br>
;; global options: +cmd<br>
.<br>
498401&nbsp;IN<br>
NS&nbsp;b.root-servers.net.<br>
.<br>
498401&nbsp;IN<br>
NS&nbsp;i.root-servers.net.<br>
.<br>
498401&nbsp;IN<br>
NS&nbsp;c.root-servers.net.<br>
.<br>
498401&nbsp;IN<br>
NS&nbsp;a.root-servers.net.<br>
.<br>
498401&nbsp;IN<br>
NS&nbsp;l.root-servers.net.<br>
.<br>
498401&nbsp;IN<br>
NS&nbsp;j.root-servers.net.<br>
.<br>
498401&nbsp;IN<br>
NS&nbsp;e.root-servers.net.<br>
.<br>
498401&nbsp;IN<br>
NS&nbsp;m.root-servers.net.<br>
.<br>
498401&nbsp;IN<br>
NS&nbsp;g.root-servers.net.<br>
.<br>
498401&nbsp;IN<br>
NS&nbsp;k.root-servers.net.<br>
.<br>
498401&nbsp;IN<br>
NS&nbsp;h.root-servers.net.<br>
.<br>
498401&nbsp;IN<br>
NS&nbsp;d.root-servers.net.<br>
.<br>
498401&nbsp;IN<br>
NS&nbsp;f.root-servers.net.<br>
;; Received 508 bytes from 192.168.4.192#53(192.168.4.192) in 8419 ms<br><br>
cs216.wpc.edgecastcdn.net. 1911<br>
IN&nbsp;A<br>
54.210.250.207<br>;; Received 59 bytes from 202.12.27.33#53(202.12.27.33) in 3 ms</div>
<br><div>
<span class="Apple-style-span"><span class="Apple-style-span">
<div>
<div>---</div>
<div>// Shawn</div>
<div><br></div>
</div>
</span><br class="Apple-interchange-newline"></span><br class="Apple-interchange-newline">
</div>
<br>
</div>
Techs_Maru | 8 Jan 07:44 2015
Picon

What are the "DNS Traffic tester" that you are using?

Hi,folks,

Please tell me,
What are the "DNS Traffic tester(Traffic Generator)"  that you are using?

Now, I used,dnsperf & queryperf only.
Do you have recommended the appliance?
(I am thinking about buying of appliances that can real simulate the
Various types of traffic for DNS
 For example, tcp / udp / dnssec / mobile traffic emulation and more....)

Appliance equipment that I know now, avalanche and ixia traffic generator.

best regards.
Wessels, Duane | 7 Jan 01:24 2015
Picon

DNS Track at NANOG 63

Dear DNS Community,

I will be moderating a DNS Track at the NANOG 63 meeting in San Antonio,
TX.  If you have interesting and timely DNS-related material to share with
operators and researchers please reply to me with a brief abstract or
description.  I'm expecting we'll have about 90 minutes and plan to allocate
10-15 minutes per presenter.

Apologies if you receive multiple copies.

Duane W.
Dear DNS Community,

I will be moderating a DNS Track at the NANOG 63 meeting in San Antonio,
TX.  If you have interesting and timely DNS-related material to share with
operators and researchers please reply to me with a brief abstract or
description.  I'm expecting we'll have about 90 minutes and plan to allocate
10-15 minutes per presenter.

Apologies if you receive multiple copies.

Duane W.

Gmane