bert hubert | 22 Jun 16:35 2016

EDNS buffer size on TCP connections?

Hi everybody,

While working on a PowerDNS bug, I wondered: what do I fill out on the
buffer size field of the EDNS record on a TCP/IP connection?

RFC 2671 and 6891 do not speak about this. 

I expect most implementations to ignore the field, but would love to hear
what operational practice is.

Thanks!

	Bert
Sue Graves | 22 Jun 04:56 2016
Picon

Call for Presentations -- OARC25 in Dallas is now Open!

The next DNS-OARC Workshop — OARC 25 — will take place in Dallas, TX, USA on Saturday 15 and Sunday 16 October 2016, before NANOG 98.

See our meetings page for more details and/or to register.

https://indico.dns-oarc.net/event/25/call-for-abstracts/

We hope to see you there!

Sue

<div>
    <p name="0e6e" class="graf--p graf-after--h4">The next
      DNS-OARC Workshop&#8202;&mdash;&#8202;<a href="https://indico.dns-oarc.net/event/25/" data-href="https://indico.dns-oarc.net/event/25/" class="markup--anchor markup--p-anchor" rel="nofollow">OARC 25</a>&#8202;&mdash;&#8202;will
      take place in Dallas, TX, USA on Saturday 15 and Sunday 16 October
      2016, before <a href="https://www.nanog.org/meetings/nanog68/home" data-href="https://www.nanog.org/meetings/nanog68/home" class="markup--anchor markup--p-anchor" rel="nofollow">NANOG 98</a>.</p>
    <p name="6bed" class="graf--p graf-after--p">See our
      meetings page for more details and/or to register.</p>
    <p name="6bed" class="graf--p graf-after--p"><a class="js-link
        post-link" href="http://www.linkedin.com/redir/redirect?url=https%3A%2F%2Findico%2Edns-oarc%2Enet%2Fevent%2F25%2Fcall-for-abstracts%2F&amp;urlhash=Yccz&amp;_t=tracking_anet" target="_blank">https://indico.dns-oarc.net/event/25/call-for-abstracts/</a></p>
    <p name="6bed" class="graf--p graf-after--p">We hope to see you
      there!</p>
    <p name="6bed" class="graf--p graf-after--p">Sue<br></p>
  </div>
Sebastian Castro | 16 Jun 03:49 2016
Picon
Gravatar

Call for Presentations - DNS-OARC 25th Workshop, Oct 2016

The DNS-OARC 25th Workshop will take place in Dallas, Texas during
October 15th and 16th 2016, the Saturday and Sunday before NANOG68. To
attract the best DNS minds, DNS-OARC is requesting proposals for
presentations, with a preference for Resolver's Operations experiences,
including running DNSSEC validating resolvers.

This workshop intends to build from previous strong DNS-OARC workshops,
where both operational content and research are welcome. All DNS-related
subjects are accepted. If you are an OARC member, and have a sensitive
topic you would like to present for members-only, we will accommodate
those talks too. A timeslot will be available for lightning talks (5-10
minutes) on Sunday October 16th, for which submissions will be accepted
during October 15th on a first-come first-served basis.

Workshop Milestones
* 15th June 2016, Call for Presentations posted and open for submissions
* 14th August 2016, Deadline for submission
* 1st September 2016, Final Program published
* 10th October 2016, Final deadline for slideset submission

Details for presentation submission will be published here:

        https://indico.dns-oarc.net/event/25/call-for-abstracts/

The workshop presentations will be organized by common themes, depending
on the topics and the timing of each presentation. There are 30-minute
and 15-minute slots, let us know your preference in your submission. To
ensure the quality of the workshop, submissions should include slides.
Draft slides are acceptable on submission.

You can contact the Programme Committee:

    https://www.dns-oarc.net/oarc/programme

via <submissions@...> if you have questions or concerns.

Sebastian Castro, for the OARC Programme Committee

OARC is also seeking sponsorship for this workshop, please contact
<sponsor@...> if your organization is interested in becoming a
sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)

Roger Murray | 14 Jun 14:36 2016
Picon
Gravatar

question regarding rcodes REFUSED vs NOTAUTH

Hey everybody,

I have some questions regarding expected rcodes and what can be found in the wild.

Background:
We are currently trying out Knot and noticed that it “broke” our monitoring. A perl script that checks
the rcode of a request for a zone transfer and we expect it to return REFUSED (rcode 5), but Knot returns
NOTAUTH (rcode 9).  It is easy to fix the monitoring, but I got curious as to what the rcode should be. As far as
I can tell by reading rfc’s (1035 and 2136) REFUSED (rcode 5) is a refusal for policy reasons while
NOTAUTH (rcode 9) is that the nameserver is not authoritative for the zone.

Questions:
Is there more/another rfc that can shed more light on this difference?
What should the rcode be?
Anyone know why different nameservers are implementing the response codes differently?

Best regards,
Roger Murray
Systemspecialist DNS, IIS
Mobil: +46 709 48 5242

Hey everybody,

I have some questions regarding expected rcodes and what can be found in the wild.

Background:
We are currently trying out Knot and noticed that it “broke” our monitoring. A perl script that checks
the rcode of a request for a zone transfer and we expect it to return REFUSED (rcode 5), but Knot returns
NOTAUTH (rcode 9).  It is easy to fix the monitoring, but I got curious as to what the rcode should be. As far as
I can tell by reading rfc’s (1035 and 2136) REFUSED (rcode 5) is a refusal for policy reasons while
NOTAUTH (rcode 9) is that the nameserver is not authoritative for the zone.

Questions:
Is there more/another rfc that can shed more light on this difference?
What should the rcode be?
Anyone know why different nameservers are implementing the response codes differently?

Best regards,
Roger Murray
Systemspecialist DNS, IIS
Mobil: +46 709 48 5242

Jacques Latour | 13 Jun 20:50 2016
Picon

That's a big one: MSG SIZE rcvd: 5131!

Apple presenting a NANOG about TCP Fast Open…

Not relevant, but snooping around, found apple returning ;; MSG SIZE  rcvd: 5131
 

$ dig apple.ca a +short
17.142.160.7
17.172.224.29
17.178.96.7


$ dig -x 17.142.160.7
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.8.3-P1 <<>> -x 17.142.160.7
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51711
;; flags: qr rd ra; QUERY: 1, ANSWER: 207, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;7.160.142.17.in-addr.arpa. IN PTR

;; ANSWER SECTION:
7.160.142.17.in-addr.arpa. 3599 IN PTR omegamap.com.
7.160.142.17.in-addr.arpa. 3599 IN PTR next.com.
7.160.142.17.in-addr.arpa. 3599 IN PTR newton.com.
7.160.142.17.in-addr.arpa. 3599 IN PTR ipad.rio.
7.160.142.17.in-addr.arpa. 3599 IN PTR ipadpro.rio.
7.160.142.17.in-addr.arpa. 3599 IN PTR applephotos.rio.
7.160.142.17.in-addr.arpa. 3599 IN PTR livephotos.rio.
7.160.142.17.in-addr.arpa. 3599 IN PTR applelivephotos.rio.
7.160.142.17.in-addr.arpa. 3599 IN PTR applemusicfestival.rio.
7.160.142.17.in-addr.arpa. 3599 IN PTR applenews.rio.
7.160.142.17.in-addr.arpa. 3599 IN PTR beats5.rio.
77.160.142.17.in-addr.arpa. 3599 IN PTR pushpin.mobi.
7.160.142.17.in-addr.arpa. 3599 IN PTR onlineapplestore.com.
7.160.142.17.in-addr.arpa. 3599 IN PTR online-apple-store.com.

;; Query time: 3 msec
;; SERVER: 192.252.241.12#53(192.252.241.12)
;; WHEN: Mon Jun 13 14:42:56 2016
;; MSG SIZE  rcvd: 5131

<div>
<div>
Apple presenting a NANOG about TCP Fast Open&hellip;</div>
<div>
<br>
</div>
<div>
Not relevant, but snooping around, found apple returning ;; MSG SIZE &nbsp;rcvd: 5131<br>
&nbsp;</div>
<div>
<div><br></div>
<div>$ dig apple.ca a +short</div>
<div>17.142.160.7</div>
<div>17.172.224.29</div>
<div>17.178.96.7</div>
<div><br></div>
<div><br></div>
<div>$ dig -x 17.142.160.7</div>
</div>
<div>
<div>;; Truncated, retrying in TCP mode.</div>
<div><br></div>
<div>; &lt;&lt;&gt;&gt; DiG 9.8.3-P1 &lt;&lt;&gt;&gt; -x 17.142.160.7</div>
<div>;; global options: +cmd</div>
<div>;; Got answer:</div>
<div>;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 51711</div>
<div>;; flags: qr rd ra; QUERY: 1, ANSWER: 207, AUTHORITY: 0, ADDITIONAL: 0</div>
<div><br></div>
<div>;; QUESTION SECTION:</div>
<div>;7.160.142.17.in-addr.arpa.<span class="Apple-tab-span">
</span>IN<span class="Apple-tab-span"> </span>PTR</div>
<div><br></div>
<div>;; ANSWER SECTION:</div>
<div>7.160.142.17.in-addr.arpa. 3599<span class="Apple-tab-span">
</span>IN<span class="Apple-tab-span"> </span>PTR<span class="Apple-tab-span">
</span>omegamap.com.</div>
<div>7.160.142.17.in-addr.arpa. 3599<span class="Apple-tab-span">
</span>IN<span class="Apple-tab-span"> </span>PTR<span class="Apple-tab-span">
</span>next.com.</div>
<div>7.160.142.17.in-addr.arpa. 3599<span class="Apple-tab-span">
</span>IN<span class="Apple-tab-span"> </span>PTR<span class="Apple-tab-span">
</span>newton.com.</div>
</div>
<div>
&hellip;</div>
<div>
&hellip;</div>
<div>
<div>7.160.142.17.in-addr.arpa. 3599<span class="Apple-tab-span">
</span>IN<span class="Apple-tab-span"> </span>PTR<span class="Apple-tab-span">
</span>ipad.rio.</div>
<div>7.160.142.17.in-addr.arpa. 3599<span class="Apple-tab-span">
</span>IN<span class="Apple-tab-span"> </span>PTR<span class="Apple-tab-span">
</span>ipadpro.rio.</div>
<div>7.160.142.17.in-addr.arpa. 3599<span class="Apple-tab-span">
</span>IN<span class="Apple-tab-span"> </span>PTR<span class="Apple-tab-span">
</span>applephotos.rio.</div>
<div>7.160.142.17.in-addr.arpa. 3599<span class="Apple-tab-span">
</span>IN<span class="Apple-tab-span"> </span>PTR<span class="Apple-tab-span">
</span>livephotos.rio.</div>
<div>7.160.142.17.in-addr.arpa. 3599<span class="Apple-tab-span">
</span>IN<span class="Apple-tab-span"> </span>PTR<span class="Apple-tab-span">
</span>applelivephotos.rio.</div>
<div>7.160.142.17.in-addr.arpa. 3599<span class="Apple-tab-span">
</span>IN<span class="Apple-tab-span"> </span>PTR<span class="Apple-tab-span">
</span>applemusicfestival.rio.</div>
<div>7.160.142.17.in-addr.arpa. 3599<span class="Apple-tab-span">
</span>IN<span class="Apple-tab-span"> </span>PTR<span class="Apple-tab-span">
</span>applenews.rio.</div>
<div>7.160.142.17.in-addr.arpa. 3599<span class="Apple-tab-span">
</span>IN<span class="Apple-tab-span"> </span>PTR<span class="Apple-tab-span">
</span>beats5.rio.</div>
<div>77.160.142.17.in-addr.arpa. 3599<span class="Apple-tab-span">
</span>IN<span class="Apple-tab-span"> </span>PTR<span class="Apple-tab-span">
</span>pushpin.mobi.</div>
<div>7.160.142.17.in-addr.arpa. 3599<span class="Apple-tab-span">
</span>IN<span class="Apple-tab-span"> </span>PTR<span class="Apple-tab-span">
</span>onlineapplestore.com.</div>
<div>7.160.142.17.in-addr.arpa. 3599<span class="Apple-tab-span">
</span>IN<span class="Apple-tab-span"> </span>PTR<span class="Apple-tab-span">
</span>online-apple-store.com.</div>
<div><br></div>
<div>;; Query time: 3 msec</div>
<div>;; SERVER: 192.252.241.12#53(192.252.241.12)</div>
<div>;; WHEN: Mon Jun 13 14:42:56 2016</div>
<div>;; MSG SIZE &nbsp;rcvd: 5131</div>
<div>
<br>
</div>
</div>
</div>
T.Suzuki | 10 Jun 02:18 2016
Picon

ENT was here !!!

What is the purpose of this record?

dig -t txt gouv.fr +dnssec +short

--

-- 
------------------------------------------------------------------------------
T.Suzuki
Mark E. Jeftovic | 9 Jun 00:41 2016
Gravatar

Long shot: .com zone from 2000?

Anybody got a .com zonefile lying around from late 2000 or early 2001?

Shoot me an email off list if so 

Thx!

- Mark 

Sent from my iPhone
Andrew White | 7 Jun 17:12 2016

Acceptable query limit to root servers

Hi fellow DNS operators,

I work at Charter, and this is not an official Charter communique :)

We are considering adding some health checks on our recursive DNS platform.

We'd like to ensure each server has access to the root via a remote dig at the recursive server. Specifically we are considering a query to an effectively random top-level domain that should always be answered by an NXDOMAIN by a root server.

Given the large number of servers and our need to perform this check fairly often, this could result in a large number of queries resulting in NXDOMAIN to the root.

Is there a best common practice as to how many of these types queries per second are considered non-impacting to the root servers, or a better method for determining recursion to the root from a large recursive platform?

Andrew White

<div><div dir="ltr">Hi fellow DNS operators,<div><br></div>
<div>I work at Charter, and this is not an official Charter communique :)</div>
<div><br></div>
<div>We are considering adding some health checks on our recursive DNS platform.</div>
<div><br></div>
<div>We'd like to ensure each server has access to the root via a remote dig at the recursive server. Specifically we are considering a query to an effectively random top-level domain that should always be answered by an NXDOMAIN by a root server.</div>
<div><br></div>
<div>Given the large number of servers and our need to perform this check fairly often, this could result in a large number of queries resulting in NXDOMAIN to the root.</div>
<div><br></div>
<div>Is there a best common practice as to how many of these types queries per second are considered non-impacting to the root servers, or a better method for determining recursion to the root from a large recursive platform?</div>
<div><br></div>
<div>Andrew White</div>
<div><br></div>
</div></div>
Stephane Bortzmeyer | 7 Jun 09:51 2016
Picon

Crouching Tiger, Hidden DNS

A clever trick to change the DNS resolvers on a Windows machine
without making this change visible (using the difference in behaviour
between configuration parsers). Useful for malware.

http://www.welivesecurity.com/2016/06/02/crouching-tiger-hidden-dns/
Shane Kerr | 5 Jun 15:03 2016
Gravatar

Quick DNS report from behind the Great Firewall of China

Hello,

I'm doing some work comparing IANA root server answers with Yeti root
server answers. As a baseline I decided to compare IANA servers with
themselves, and discovered differences. I am doing this work in China
right now, so I probably should have expected something like this,
because of the Great Firewall and all of its evil.

So here are some observations about DNS and the Great Firewall of
China, from my hotel room. Note that I am not encouraging anyone to
bypass Chinese laws or regulations, but as a technical DNS person I
find the details interesting and thought other people would too.

After a little poking around it seems that there is some DPI happening
for all DNS packets that come into China via the Great Firewall. This
means that, for example, the F, J, and L root servers are not impacted
by the Great Firewall since they have instances in Beijing. (Packets
from some root servers are *sometimes* modified, like I root, and I'm
not sure why that is.) I didn't look at any TLD. I don't know
if any have servers in China other than the various Chinese TLDs.

It looks like there is a blacklist. Of course I can't know the full
extent, but I did notice that answers for "google.com" and
"twitter.com" are modified. If you query anything on the list, then you
get an A record back with some IP addresses that are not always the
same, but also not completely random.

WHOIS lookup on some of the addresses shows valid networks in Germany,
Azerbaijan, the UK, and so on. When I traceroute to these IP addresses
though they terminate at a hop within the China Unicom network, which
seems to be the provider that I'm currently connected to - so while I
would consider it BGP hijacking, as Randy Bush says, "your network, your
rules". ;) My guess is that there is some disk somewhere recording all
packets that try to get to those addresses and making a careful note
for future auditing, but perhaps these packets are just dropped on the
floor. (The NSA would save these, maybe the Chinese officials are
smarter though?)

It looks like the DNS answers are being modified on the return path, not
the outbound path. At least, I can query IP addresses I run for
"google.com" and I see the query packets at that host ("dig  <at> my.host
google.com").

It looks like TCP is not being intercepted, so a simple approach for
someone in China wishing to get clean DNS might be to use TCP to a
resolver outside of China. A Linux host can usually do this by setting:

   options use-vc

In the /etc/resolv.conf file.

If you want to run a resolver *inside* of China and get the answers that
authority operators are actually returning, this is probably also
possible, although trickier.

Right now, it seems that NS records are not being intercepted. This
means that if you use QNAME minimization, a resolver in China should be
able to get information on (for example) the Google name servers.
UDP answers from those servers will be spoofed.

These spoofed A records are not signed (of course), so anyone performing
DNSSEC validation will reject the spoofed answers.

Since TCP is not being intercepted, a resolver can:

1. Use QNAME minimization to get to the authoritative servers, then
2. Reject UDP answers because validation will break, and then
3. Use TCP to get a valid answer.

I don't know if any resolvers can work this way, but in principle it is
at least *possible*.

To be clear, this won't actually let you get to any blocked server,
since there are IP layer blocks in place too, but at least DNS will be
correct. :) (Actually, detecting such blocks could allow someone to
build a middlebox which used VPN only when needed and otherwise used
normal upstream. Hm...)

Cheers,

--
Shane
Hello,

I'm doing some work comparing IANA root server answers with Yeti root
server answers. As a baseline I decided to compare IANA servers with
themselves, and discovered differences. I am doing this work in China
right now, so I probably should have expected something like this,
because of the Great Firewall and all of its evil.

So here are some observations about DNS and the Great Firewall of
China, from my hotel room. Note that I am not encouraging anyone to
bypass Chinese laws or regulations, but as a technical DNS person I
find the details interesting and thought other people would too.

After a little poking around it seems that there is some DPI happening
for all DNS packets that come into China via the Great Firewall. This
means that, for example, the F, J, and L root servers are not impacted
by the Great Firewall since they have instances in Beijing. (Packets
from some root servers are *sometimes* modified, like I root, and I'm
not sure why that is.) I didn't look at any TLD. I don't know
if any have servers in China other than the various Chinese TLDs.

It looks like there is a blacklist. Of course I can't know the full
extent, but I did notice that answers for "google.com" and
"twitter.com" are modified. If you query anything on the list, then you
get an A record back with some IP addresses that are not always the
same, but also not completely random.

WHOIS lookup on some of the addresses shows valid networks in Germany,
Azerbaijan, the UK, and so on. When I traceroute to these IP addresses
though they terminate at a hop within the China Unicom network, which
seems to be the provider that I'm currently connected to - so while I
would consider it BGP hijacking, as Randy Bush says, "your network, your
rules". ;) My guess is that there is some disk somewhere recording all
packets that try to get to those addresses and making a careful note
for future auditing, but perhaps these packets are just dropped on the
floor. (The NSA would save these, maybe the Chinese officials are
smarter though?)

It looks like the DNS answers are being modified on the return path, not
the outbound path. At least, I can query IP addresses I run for
"google.com" and I see the query packets at that host ("dig  <at> my.host
google.com").

It looks like TCP is not being intercepted, so a simple approach for
someone in China wishing to get clean DNS might be to use TCP to a
resolver outside of China. A Linux host can usually do this by setting:

   options use-vc

In the /etc/resolv.conf file.

If you want to run a resolver *inside* of China and get the answers that
authority operators are actually returning, this is probably also
possible, although trickier.

Right now, it seems that NS records are not being intercepted. This
means that if you use QNAME minimization, a resolver in China should be
able to get information on (for example) the Google name servers.
UDP answers from those servers will be spoofed.

These spoofed A records are not signed (of course), so anyone performing
DNSSEC validation will reject the spoofed answers.

Since TCP is not being intercepted, a resolver can:

1. Use QNAME minimization to get to the authoritative servers, then
2. Reject UDP answers because validation will break, and then
3. Use TCP to get a valid answer.

I don't know if any resolvers can work this way, but in principle it is
at least *possible*.

To be clear, this won't actually let you get to any blocked server,
since there are IP layer blocks in place too, but at least DNS will be
correct. :) (Actually, detecting such blocks could allow someone to
build a middlebox which used VPN only when needed and otherwise used
normal upstream. Hm...)

Cheers,

--
Shane
Ondřej Surý | 3 Jun 09:38 2016
Picon
Gravatar

Sad news today: systemd-resolved to be deployed in Ubuntu 16.10

Hi,

the horrible news as of today:

https://lists.ubuntu.com/archives/ubuntu-devel/2016-May/039350.html

Shivers...

Cheers,
--
 Ondřej Surý -- Technical Fellow
 --------------------------------------------
 CZ.NIC, z.s.p.o.    --     Laboratoře CZ.NIC
 Milesovska 5, 130 00 Praha 3, Czech Republic
 mailto:ondrej.sury <at> nic.cz    https://nic.cz/
 --------------------------------------------

_______________________________________________
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

Gmane