Peter van Dijk | 5 Feb 17:15 2016

lowercasing of questions from recursor to auths?

Hello fellow DNS people,

we recently got a request from a user to lowercase questions sent from the
PowerDNS Recursor to auths on the Internet, even if the question the Recursor
got from the client was in mixed case. My initial thought was “why don’t we do
that already - after all, once cached there are no case guarantees anyway”.

So I did some digging and investigation - all of PowerDNS, BIND and Unbound
preserve case on the initial question to the auth (i.e. the uncached case).
Unbound with 0x20 enabled, of course, does not preserve case.

Now, experience with unbound’s 0x20 implementation shows, as I recall it, that
it breaks some auths (no surprise there) but I have not heard anything about
it breaking client applications (although one imagines that some DNS
tunnelling software might be affected).

My concrete question: can you imagine operational downsides to lowercasing all
questions sent to auths? Because I don’t see it, but we’ve gone 15 years
(longer for other implementations) preserving case so I need to be careful.

(In case the question comes up, this discussion is triggered by widget.criteo.com
returning several IPs instead of just one when asked in non-lowercase.)

Kind regards,
--

-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
Hello fellow DNS people,
(Continue reading)

Paul Hoffman | 3 Feb 18:20 2016
Gravatar

Everyone having their own resolver

On 3 Feb 2016, at 7:41, Matthew Pounsett wrote:

> The existing infrastructure can probably handle it initially, sure .. 
> but expect your domain registrations and DNS hosting to be an order of 
> magnitude more expensive.   Much of the authoritative infrastructure 
> has an overhead multiplier built into its capacity, where the 
> multiplier is locally chosen based on the likelihood and impact of 
> DDoS.  Some infrastructures are built to handle over 100x the 
> “normal” traffic load.
>
> When the normal query rate sees an order (or two) magnitude jump, it 
> eats away that extra capacity built into the system, and everyone has 
> to scale up to get back their DDoS-eating overhead.

These are interesting bold statements, and I've heard similar over the 
past few years.

Has anyone ever measured this? That is, there are a bunch of people on 
this very mailing list who have access to the caches and possibly even 
the query logs for Very Large Resolvers. It would be grand to see 
current research (or at least a list of good recent research) on what 
percentage of queries are for things in the long tail.

--Paul Hoffman
_______________________________________________
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
(Continue reading)

David C Lawrence | 3 Feb 05:42 2016

Looking for netregistry contact

Is there anyone from netregistry on the list, or someone who knows
someone there?  We're having some trouble finding someone to help us
track down a resolution issue with their authorities.

Thank you.

Shane Kerr | 2 Feb 21:10 2016
Gravatar

DNS at FOSDEM 2016

All,

I was at FOSDEM 2016 last weekend, and wrote up a few of my
observations around DNS there:

http://dnsv6lab.net/2016/02/03/DNS-at-FOSDEM/

Cheers,

--
Shane
Casey Deccio | 2 Feb 20:51 2016
Picon

Verizon ROUTE contact

If there is a Verizon ROUTE contact here, could you please contact me off-list?

Cheers,
Casey
<div><div dir="ltr">
<div>If there is a Verizon ROUTE contact here, could you please contact me off-list?<br>
</div>
<div><br></div>
<div>Cheers,<br>
</div>Casey<br>
</div></div>
Michael Smitasin | 2 Feb 00:21 2016

NXDOMAIN and negative caching

Just wanted to confirm my understanding:

- An NXDOMAIN / Name Error response indicates the domain name does not 
exist, while a No Data response indicates the domain exists but no data 
of the queried type exists. (Mostly looking at RFC 1035 Section 5.2.1)
- An NXDOMAIN should be cached for a given QNAME, QCLASS. (RFC 2038 
Section 5)

What I infer from that (perhaps it's explicitly stated elsewhere?) is 
two things:

- An NXDOMAIN indicates /no/ records exist for that name.
- When an NXDOMAIN is cached, it will be returned for /any/ QTYPE 
matching the same QNAME, QCLASS.

We have a situation where an authoritative server (outside our control) 
is returning a good A record but when the same name is queried for an NS 
record, it returns NXDOMAIN. Once our caching nameservers get that 
NXDOMAIN, they start returning it to our client queries for the A 
record. If my understanding of the above is true, our caching 
nameservers are behaving correctly, but the authoritative server should 
not be returning NXDOMAIN for that name? If so, is anyone familiar with 
the circumstances where that would be the case or have recommendations I 
can forward on to the operators of that authoritative server?

Thanks,

--

-- 
Michael Smitasin
Network Engineer
LBLnet Services Group
Lawrence Berkeley National Laboratory
Edward Lewis | 1 Feb 20:12 2016
Picon

Why utopian ideals die on the shores of operations ... Re: Typo in fox.com and an Akamai squatter

On 2/1/16, 12:45, "dns-operations on behalf of Paul Hoffman"
<dns-operations-bounces@... on behalf of phoffman@...>
wrote:

>On 1 Feb 2016, at 8:08, Edward Lewis wrote:

>Sure there is. A hoster can scan the NS records for all their clients
>and note when one of those records isn't pointing to the hoster's name
>servers. This would be a service that I bet some customers (such as
>Fox?) would very much like.

Unless they aren't supposed to.  There are many factors in operating a DNS
hosting service that may not be obvious.

In my experience, smart, well-heeled and well-funded customers would not
rely on a single provider.  My old frim decided to recommend this to
customers so we could build in a technological monoculture and leave
diversity to using someone else.  For that reason, inspecting the NS
records that don't match would be raising false alarms.  In the case that
I recall, the issue was the transpositioning of some letters inside a
label, not the TLD, like "s/the/teh/".  Sure, the name didn't match the
hoster, but there's no telling if it is the name of a host of another
operator.

>That should not prevent the hoster from not only alerting their
>customer, but suggesting that the customer use a better registrar (for
>some probably-slated definition of "better", like "registrars with whom
>we have a business relationship").

In my case, one hand of the business was concerned with being neutral to
the registrars.  So, that's out.

>In the current case, Akamai could make an arrangement with some
>registrars (certainly with one the size and reputation of MarkMonitor)
>to have a high-urgency communication channel when there is something
>wrong happening with their mutual customers.

Generally that's so.  Once you know there's a problem.  Operators did talk
to each other, but come to think of it, never with the registrars.

>> Only the domain name owner is in position to check this.
>
>This entire list was able to check this. :-)

Post-haste.

It's like something I heard in the search for MH370 - why is it we have
spy satellites that can read a newspaper on a porch but they can't find a
Boeing 777?  It's easy once you spot it to see it.

>Note that the registrar is also able to check this. Pseudocode:
>for each customer:
>   Collect all NS records
>   for each NS record in set:
>     Check for name that is not run by the same admin as the rest
>   if state == fishy:
>     Check if we have talked to the customer about this before
>     if first_time or not dont_bug_us_about_fishiness:
>       Escalate

A long time ago a quote was attributed to Vijay Gill regarding service
calls to AOL.  It went something like this: a single call blows the profit
margin for the year, a second (or an escalation) blows the profit for the
lifetime of the account.  (In 2014 I asked him if he could recall where
the quote might be archived, he did not.)  The point is that operators are
not likely to go out "looking for trouble" for a few reasons.

One, most broken situations don't matter.  I.e., they belong to unused
domain names.  Two, if you try to contact customers, you'll be waiting on
the phone a lot.  Even active customers are reluctant to respond, much
less to those who've forgotten they are paying for the service.

Setting this up is that at a DNS hoster, there's no prerequisite for a
domain name to have any correlation to the WhoIs.  (Recall SAC 057 - when
certs were issued for .CORP, etc?  One can configure DNS hosters with
names the same way.  It would be a bad idea to ban that, it would make
transitioning hosters a delicate dance as an example.)

There are a couple of factors against tighter coupling.

1) Economics.  The businesses involved are competing on price already and
there's known churn rate.  When you know your customers will only be
around a few years regardless of what you do, it's unwise, financially, to
invest in trying to keep them.

2) Technology.  The Internet is vast.  The protocols are not easily
manageable.  It's hard enough to find a symptom, it's impossible to make a
diagnosis relying solely on in-band information.

3) Scale.  One major factor in the success of DNS is it's looseness.  I
bet, and this is a bet, if the DNS was as tightly coupled as many other
systems of the era in which it emerged for the sake of name management, we
wouldn't working on the DNS today.  I.e., tightening the system now could
crimp the scale, encouraging consolidation into a smaller set of
operators.  (This is totally opinion.)
Attachment (smime.p7s): application/pkcs7-signature, 6226 bytes
On 2/1/16, 12:45, "dns-operations on behalf of Paul Hoffman"
<dns-operations-bounces@... on behalf of phoffman@...>
wrote:

>On 1 Feb 2016, at 8:08, Edward Lewis wrote:

>Sure there is. A hoster can scan the NS records for all their clients
>and note when one of those records isn't pointing to the hoster's name
>servers. This would be a service that I bet some customers (such as
>Fox?) would very much like.

Unless they aren't supposed to.  There are many factors in operating a DNS
hosting service that may not be obvious.

In my experience, smart, well-heeled and well-funded customers would not
rely on a single provider.  My old frim decided to recommend this to
customers so we could build in a technological monoculture and leave
diversity to using someone else.  For that reason, inspecting the NS
records that don't match would be raising false alarms.  In the case that
I recall, the issue was the transpositioning of some letters inside a
label, not the TLD, like "s/the/teh/".  Sure, the name didn't match the
hoster, but there's no telling if it is the name of a host of another
operator.

>That should not prevent the hoster from not only alerting their
>customer, but suggesting that the customer use a better registrar (for
>some probably-slated definition of "better", like "registrars with whom
>we have a business relationship").

In my case, one hand of the business was concerned with being neutral to
the registrars.  So, that's out.

>In the current case, Akamai could make an arrangement with some
>registrars (certainly with one the size and reputation of MarkMonitor)
>to have a high-urgency communication channel when there is something
>wrong happening with their mutual customers.

Generally that's so.  Once you know there's a problem.  Operators did talk
to each other, but come to think of it, never with the registrars.

>> Only the domain name owner is in position to check this.
>
>This entire list was able to check this. :-)

Post-haste.

It's like something I heard in the search for MH370 - why is it we have
spy satellites that can read a newspaper on a porch but they can't find a
Boeing 777?  It's easy once you spot it to see it.

>Note that the registrar is also able to check this. Pseudocode:
>for each customer:
>   Collect all NS records
>   for each NS record in set:
>     Check for name that is not run by the same admin as the rest
>   if state == fishy:
>     Check if we have talked to the customer about this before
>     if first_time or not dont_bug_us_about_fishiness:
>       Escalate

A long time ago a quote was attributed to Vijay Gill regarding service
calls to AOL.  It went something like this: a single call blows the profit
margin for the year, a second (or an escalation) blows the profit for the
lifetime of the account.  (In 2014 I asked him if he could recall where
the quote might be archived, he did not.)  The point is that operators are
not likely to go out "looking for trouble" for a few reasons.

One, most broken situations don't matter.  I.e., they belong to unused
domain names.  Two, if you try to contact customers, you'll be waiting on
the phone a lot.  Even active customers are reluctant to respond, much
less to those who've forgotten they are paying for the service.

Setting this up is that at a DNS hoster, there's no prerequisite for a
domain name to have any correlation to the WhoIs.  (Recall SAC 057 - when
certs were issued for .CORP, etc?  One can configure DNS hosters with
names the same way.  It would be a bad idea to ban that, it would make
transitioning hosters a delicate dance as an example.)

There are a couple of factors against tighter coupling.

1) Economics.  The businesses involved are competing on price already and
there's known churn rate.  When you know your customers will only be
around a few years regardless of what you do, it's unwise, financially, to
invest in trying to keep them.

2) Technology.  The Internet is vast.  The protocols are not easily
manageable.  It's hard enough to find a symptom, it's impossible to make a
diagnosis relying solely on in-band information.

3) Scale.  One major factor in the success of DNS is it's looseness.  I
bet, and this is a bet, if the DNS was as tightly coupled as many other
systems of the era in which it emerged for the sake of name management, we
wouldn't working on the DNS today.  I.e., tightening the system now could
crimp the scale, encouraging consolidation into a smaller set of
operators.  (This is totally opinion.)
Suresh, Sairam | 29 Jan 23:58 2016
Picon

Re: Typo in fox.com and an Akamai squatter

Chris, try fnghelpdesk@... - they'll escalate to the right person.

-----Original Message-----
From: dns-operations [mailto:dns-operations-bounces@...]
On Behalf Of Chris Adams
Sent: Friday, January 29, 2016 2:17 PM
To: dns-operations@...
Subject: [dns-operations] Typo in fox.com and an Akamai squatter

One of my customers for which I manage recursive DNS servers ran into a
problem: fox.com was resolving to 185.45.13.88 for their customers (which appears to be serving malware).

Digging into the cache, it appears the problem is a typo in the NS records for fox.com:

$ dig +short fox.com ns
;; Truncated, retrying in TCP mode.
a23-73-133-237.deploy.static.akamaitechnologies.com.
a72-247-151-10.deploy.akamaitechnologies.com.
a72-247-45-157.deploy.akamaitechnologies.com.
a72-246-0-10.deploy.akamaitechnologies.com.
a23-73-134-237.deploy.static.akamaitechnologies.com.
a72-247-45-25.deploy.akamaitechnologies.com.
a72-247-45-110.deploy.akamaitechnologies.co.
a72-246-192-168.deploy.akamaitechnologies.com.
a23-73-133-141.deploy.static.akamaitechnologies.com.
zl1-east.akamai.com.
a60-254-128-45.deploy.akamaitechnologies.com.
zl1-west.akamai.com.
a23-73-134-141.deploy.static.akamaitechnologies.com.
a72-247-45-65.deploy.akamaitechnologies.com.
fw01.cmbrmaks.akamai.com.
a193-108-152-143.deploy.akamaitechnologies.com.

Note that they are all "akamai.com." or "akamaitechnologies.com.", except for one that is
"akamaitechnologies.co." (.co not .coM).
a72-247-45-110.deploy.akamaitechnologies.co. resolves to the bogus IP (with a link-local AAAA
record), so I am guessing that the akamaitechnologies.co domain is a squatter (wonder how many other
domains have such typos).

Anybody have a contact at fox.com and/or Akamai?
--
Chris Adams <cma@...>
_______________________________________________
dns-operations mailing list
dns-operations@...
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Chris Adams | 29 Jan 23:16 2016
Picon

Typo in fox.com and an Akamai squatter

One of my customers for which I manage recursive DNS servers ran into a
problem: fox.com was resolving to 185.45.13.88 for their customers
(which appears to be serving malware).

Digging into the cache, it appears the problem is a typo in the NS
records for fox.com:

$ dig +short fox.com ns
;; Truncated, retrying in TCP mode.
a23-73-133-237.deploy.static.akamaitechnologies.com.
a72-247-151-10.deploy.akamaitechnologies.com.
a72-247-45-157.deploy.akamaitechnologies.com.
a72-246-0-10.deploy.akamaitechnologies.com.
a23-73-134-237.deploy.static.akamaitechnologies.com.
a72-247-45-25.deploy.akamaitechnologies.com.
a72-247-45-110.deploy.akamaitechnologies.co.
a72-246-192-168.deploy.akamaitechnologies.com.
a23-73-133-141.deploy.static.akamaitechnologies.com.
zl1-east.akamai.com.
a60-254-128-45.deploy.akamaitechnologies.com.
zl1-west.akamai.com.
a23-73-134-141.deploy.static.akamaitechnologies.com.
a72-247-45-65.deploy.akamaitechnologies.com.
fw01.cmbrmaks.akamai.com.
a193-108-152-143.deploy.akamaitechnologies.com.

Note that they are all "akamai.com." or "akamaitechnologies.com.",
except for one that is "akamaitechnologies.co." (.co not .coM).
a72-247-45-110.deploy.akamaitechnologies.co. resolves to the bogus IP
(with a link-local AAAA record), so I am guessing that the
akamaitechnologies.co domain is a squatter (wonder how many other
domains have such typos).

Anybody have a contact at fox.com and/or Akamai?
--

-- 
Chris Adams <cma@...>
Giuseppe (Pino) de Candia | 26 Jan 10:43 2016
Gravatar

Fwd: Proposed DNS support in MN 5.2

Hi DNS Operations community,

I'd love any feedback you might provide about the DNS behaviour explained in the attached Google Document (separately shared with the MidoNet Open Source community). The document is open to comments and a quick read.

I'm not familiar with practices on this mailing list (this is my first time sending), so please let me know if it's bad form to refer to external documents and I'll resend.

thanks in advance for any feedback you provide!

Pino


---------- Forwarded message ----------
From: Giuseppe (Pino) de Candia <gdecandia-SN072n759w5Wk0Htik3J/w@public.gmane.org>
Date: Mon, Jan 25, 2016 at 6:37 PM
Subject: Proposed DNS support in MN 5.2
To: midonet-dev <midonet-dev-+hD5IHI5XseJ8IffHwK4ng@public.gmane.org.org>, midonet-+hD5IHI5Xsc@public.gmane.orgdonet.org


Hi Folks,

MidoNet 1.9 and 5.0 do not have DNS support, which means that tenants cannot resolve local hostnames out-of-the-box.

Here's a proposal about what DNS support MN should provide in the short term.

thanks,
Pino

<div><div dir="ltr">
<div>Hi DNS Operations community,</div>
<div><br></div>
<div>I'd love any feedback you might provide about the DNS behaviour explained in the attached Google Document (separately shared with the MidoNet Open Source community). The document is open to comments and a quick read.</div>
<div><br></div>
<div>I'm not familiar with practices on this mailing list (this is my first time sending), so please let me know if it's bad form to refer to external documents and I'll resend.</div>
<div><br></div>
<div>thanks in advance for any feedback you provide!</div>
<div><br></div>
<div>Pino</div>
<div><br></div>
<br><div class="gmail_quote">---------- Forwarded message ----------<br>From: Giuseppe (Pino) de Candia <span dir="ltr">&lt;<a href="mailto:gdecandia <at> midokura.com">gdecandia@...</a>&gt;</span><br>Date: Mon, Jan 25, 2016 at 6:37 PM<br>Subject: Proposed DNS support in MN 5.2<br>To: midonet-dev &lt;<a href="mailto:midonet-dev@...">midonet-dev@....org</a>&gt;, <a href="mailto:midonet@...">midonet@...donet.org</a><br><br><br><div dir="ltr">Hi Folks,<div><br></div>
<div>MidoNet 1.9 and 5.0 do not have DNS support, which means that tenants cannot resolve local hostnames out-of-the-box.</div>
<div><br></div>
<div>Here's a <a href="https://docs.google.com/document/d/1_nDVxlh0TQkq8ow3Tb_36pt_AEKsENJYzzDaZ0tdBBU" target="_blank">proposal</a> about what DNS support MN should provide in the short term.</div>
<div><br></div>
<div>thanks,</div>
<div>Pino</div>
</div>
</div>
<br>
</div></div>
bert hubert | 25 Jan 16:36 2016

Embedding MAC address in DNS requests for selective filtering

Hi everybody,

We have heard of implementations where 'per-device DNS filtering' is being  
offered, even behind NAT.  So this means you might get parental filtering on
your kids' iPads, but not on your own desktop.

This is then probably implemented by the home router (CPE) appending the MAC 
address to queries, presumably over EDNS.  The ISP nameserver can then
conditionally filter queries or not, based on customer IP and client MAC
address.

In the interest of interoperability, could those parties that are
implementing this functionality please speak up how they are doing it? I
know you are on this list.

One very simple way of doing it would be to reuse RFC 5001, which is
normally
used for server identification, and use it for client identification too.

If any vendor is in fact using NSID this way, please document this. It might
prevent surprises later on. Thank you.

If anyone thinks NSID is not a good way to do this, please also let us know.

PowerDNS will be implementing either NSID or what "the CPE market" is doing.

Thanks!

	Bert

Gmane