RE: IPv6 automatic reverse DNS

[White, Andrew]

Hi John,

Thanks for the info and background.

One operational suggestion I have is … why link synthesis rules to a specific 
DNS zone?

Most larger operators of auth DNS use an IP management tool, like BT Diamond 
IPAM, BlueCat, or Infoblox. Oftentimes, allocations of IP space will not be on 
classful boundaries, yet most often reverse DNS zones are on classful 
boundaries.

What may be more operationally useful would be an (optional) feature in auth 
DNS software that would process an incoming PTR request as follows:


1.   Answer the PTR with an entry in the corresponding ip6.arpa or 
in-addr.arpa zone file if the PTR exists

2.   Otherwise, examine a rule set of synthetic PTR responses and answer by 
the rule set (e.g. 10.0.0.128 matches rule for “10.0.0.128/27” and returns PTR 
of 10-0-0-128.dhcp.example.com.)

3.   Otherwise, return NXDOMAIN or NOANSWER/NOERROR as appropriate

Such a ruleset could apply to forward zones as well to create the matching 
forward lookup.

Just my two cents!  Caveat: personal opinion and not the official position of 
Charter.

Andrew


Ληdrеw Whiте
Charter Network Operations - DAS DNS
Desk: 314-394-9594 - Cell: 314-452-4386
andrew.whi...@charter.com<mailto:andrew.whi...@charter.com>

From: Woodworth, John R [mailto:john.woodwo...@centurylink.com]
Sent: Monday, October 31, 2016 11:04 PM
To: White, Andrew; 'nanog@nanog.org'
Cc: Ballew, Dean; Woodworth, John R
Subject: RE: IPv6 automatic reverse DNS

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of White, Andrew
>
> There are two competing drafts for synthetic rule-based PTR responses
> for IPv6 rDNS:
>
> Howard Lee, Time Warner Cable (now Charter)
> https://tools.ietf.org/html/draft-howard-isp-ip6rdns-08
>
> J. Woodworth, CenturyLink
> https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/
>
> Nominum and Xerocole/Akamai also have proprietary solutions to this
> in their Vantio AuthServ and AuthX products, respectively.
>
> It seems to me that it is still an open question whether the
> recommendations in RFC-1912 that any IP address that accesses the
> Internet should have a PTR and matching forward record. My personal
> thoughts are that the best solution would be an OPTIONAL standards-based
> method of generating DNS responses based on a ruleset if a specific zone
> record is not present, and that implementation of that requirement
> should be left to the developers of the auth nameserver software.

Greetings Andrew,

I am new to the group but one of the authors referenced above.  My
colleagues and I are glad to see the discussion around this issue
see some recent movement.

As indicated by one of our esteemed WG chairs elsewhere in this thread,
I am currently working to provide additional clarity for some of the
more difficult concepts in the draft and have not yet requested the
next step.  Once these changes are complete we will enthusiastically
move forward with this request.

As I am new to this forum, for the moment I wanted to simply state:
synthesized records based on the proposed "bulk rr" method can
_only_exist_where_zone_records_do_not_already_.  One critical goal of
the draft is to make the "intent" of synthesized records easy to
transfer between nameservers in authoritative roles.  Examples for
implementing the draft using fairly straightforward regex
manipulation are included but are more of a guideline for making
the pattern substitution easier for the implementor and provide
a reference for the accompanying examples.  Ultimately, as you
recommend, the auth nameserver software vendor would be free to
provide their own pattern substitution logic (so long as the
intent is not lost).

DNSSEC for synthesized records also poses its own obvious set of…
complications for which we've outlined a number of solutions to
help satisfy this challenge.

Admittedly, it is a bit of a hefty read but we would love the
feedback (directly or in the IETF DNSOP mailing list of course).


Thanks,
John Woodworth


>
> Andrew
>
> Caveat: These thoughts are mine personally and do not represent
> any official position of Charter Communications.
>
>
> Ληdrеw Whiте
> Charter Network Operations - DAS DNS
> Desk: 314-394-9594 ? Cell: 314-452-4386
> andrew.whi...@charter.com<mailto:andrew.whi...@charter.com>
>

-- THESE ARE THE DROIDS TO WHOM I REFER:
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.

RE: IPv6 automatic reverse DNS

[White, Andrew]

Thanks for the clarification, Wes.

Has anyone proposed the method of publishing v6 PTRs on-the-fly as addresses 
are observed passing through an ISP's router?

Andrew


Ληdrеw Whiте
Charter Network Operations - DAS DNS
Desk: 314-394-9594 ? Cell: 314-452-4386
andrew.whi...@charter.com


-Original Message-
From: Wesley George [mailto:wesgeo...@puck.nether.net] 
Sent: Saturday, October 29, 2016 7:41 AM
To: White, Andrew
Cc: Steve Atkins; NANOG list
Subject: Re: IPv6 automatic reverse DNS


> On Oct 28, 2016, at 11:03 PM, White, Andrew  wrote:
> 
> There are two competing drafts for synthetic rule-based PTR responses for 
> IPv6 rDNS:
> 
> Howard Lee, Time Warner Cable (now Charter)
> https://tools.ietf.org/html/draft-howard-isp-ip6rdns-08
> 
> J. Woodworth, CenturyLink
> https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/
> 

At the risk of getting into IETF administrivia, a little clarification is 
important here: The first draft you mention above was replaced by the draft I 
referenced in my previous email. It is currently an adopted WG draft in DNSOP, 
moving toward working group last call as a consensus document., thus the window 
for capturing and incorporating feedback is closing soon. The second document 
does not appear to be associated with any IETF Working Group yet, but it also 
isn't competing with the first document. The first draft is informational 
status, discussing the issues and considerations surrounding this problem, of 
which generating on-the-fly reverse records is one possible solution. The 
second draft is a proposed standard defining *how* to generate those on-the-fly 
reverse records assuming one decides that is the right path to take in one's 
network, and would dovetail nicely via reference to section 2.5 of isp-ip6-rdns.

Wes George

RE: IPv6 automatic reverse DNS

[White, Andrew]

There are two competing drafts for synthetic rule-based PTR responses for IPv6 
rDNS:

Howard Lee, Time Warner Cable (now Charter)
https://tools.ietf.org/html/draft-howard-isp-ip6rdns-08

J. Woodworth, CenturyLink
https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/

Nominum and Xerocole/Akamai also have proprietary solutions to this in their 
Vantio AuthServ and AuthX products, respectively.

It seems to me that it is still an open question whether the recommendations in 
RFC-1912 that any IP address that accesses the Internet should have a PTR and 
matching forward record. My personal thoughts are that the best solution would 
be an OPTIONAL standards-based method of generating DNS responses based on a 
ruleset if a specific zone record is not present, and that implementation of 
that requirement should be left to the developers of the auth nameserver 
software.

Andrew

Caveat: These thoughts are mine personally and do not represent any official 
position of Charter Communications.


Ληdrеw Whiте
Charter Network Operations - DAS DNS
Desk: 314-394-9594 ? Cell: 314-452-4386
andrew.whi...@charter.com


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Steve Atkins
Sent: Friday, October 28, 2016 6:29 PM
To: NANOG list
Subject: Re: IPv6 automatic reverse DNS


> On Oct 28, 2016, at 4:02 PM, Baldur Norddahl  
> wrote:
> 
> Hello
> 
> Many service providers have IPv4 reverse DNS for all their IP addresses. If 
> nothing is more relevant, this will often just be the IPv4 address hashed 
> somehow and tagged to the ISP domain name. For some arcane reason it is 
> important to have the forward DNS match the reverse DNS or some mail servers 
> might reject your mails.
> 
> However with IPv6 it is not practical to build such a complete reverse DNS 
> zone. You could do a star entry but that would fail the reverse/forward match 
> test.
> 
> It should be simple to build a DNS server that will automatically generate a 
> hostname value for every reverse lookup received, and also be able to parse 
> that hostname value to return the correct IPv6 address on forward lookups.
> 
> Does any DNS server have that feature?

It's easy enough to implement with plugins on some servers.

> Should we have it?

Meh.

> Why not?

Because having an automatically generated reverse DNS is a sign that the IP 
address is not really intended to be offering public services, rather it's a 
malware-infested end user machine.

> 
> I know of some arguments for:
> 
> 1a) mail servers like it

... because it's a sign that the mail is coming from a real mailserver 
configured by a competent admin, rather than being a random compromised 
machine. That's not the case if you're just synthesizing reverse DNS for 
arbitrary IP addresses on your network.

> 
> 1b) anti spam filters believe in the magic of checking forward/reverse match.

For the same reason as above. Spam filters are also often smart enough to 
recognize, and treat as dubious, synthesized reverse DNS.

If you have synthesized reverse DNS on your smarthost you're likely to have a 
bad time, perhaps initially, perhaps the first time someone notices bad mail 
coming from it and doesn't recognize it as a legitimate smarthost.

> 
> 2) traceroute will be nicer

Most of those hosts a traceroute goes through should hopefully have stable IP 
addresses and meaningful, not synthesized, reverse DNS, I'd think. Consumer 
endpoints are the only ones where you might expect that not to be the case and 
synthesized reverse DNS might be an improvement there.

> 
> 3) http://ipv6-test.com/ will give me 20/20 instead of 19/20 (yes that was 
> what got me going on this post)
> 
> 4) Output from "who" command on Unix will look nicer (maybe).
> 
> Regards,
> 
> Baldur

Cheers,
  Steve

RE: BCP38 adoption "incentives"?

[White, Andrew]

Hi Mike,

This assumes the ISP manages the customer's CPE or home router, which is often 
not the case. Adding such ACLs to the upstream device, operated by the ISP, is 
not always easy or feasible.

It would make sense for most ISPs to have egress filtering at the edge (transit 
and peering points) to filter out packets that should not originate from the 
ISP's ASN, although this does not prevent spoofing between points in the ISP's 
network.

Andrew

NB: My personal opinion and not official communiqué of Charter.


Andrew White
Desk:  314.394-9594  | Cell:  314-452-4386 | Jabber
andrew.whi...@charter.com
Systems Engineer III, DAS DNS group
Charter Communications
12405 Powerscourt Drive, St. Louis,  MO 63131



-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mike Hammett
Sent: Tuesday, September 27, 2016 3:33 PM
Cc: nanog@nanog.org
Subject: Re: BCP38 adoption "incentives"?

It would be incredibly low impact to have the residential CPE block any source 
address not assigned by the ISP. Done. 




-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com 

Midwest-IX
http://www.midwest-ix.com 

- Original Message -

From: "Stephen Satchell" 
To: nanog@nanog.org
Sent: Tuesday, September 27, 2016 7:31:24 AM
Subject: BCP38 adoption "incentives"? 

Does anyone know if any upstream and tiered internet providers include in their 
connection contracts a mandatory requirement that all directly-connected 
routers be in compliance with BCP38? 

Does anyone know if large ISPs like Comcast, Charter, or AT&T have put in place 
internal policies requiring retail/business-customer-aggregating routers to be 
in compliance with BCP38? 

Does any ISP, providing business Internet connectivity along with a block of IP 
addresses, include language in their contracts that any directly connected 
router must be in compliance with BCP38? 

I've seen a lot of moaning and groaning about how BCP38 is pretty much being 
ignored. Education is one way to help, but that doesn't hit anyone in the 
wallet. You have to motivate people to go out of their way to *learn* about 
BCP38; most business people are too busy with things that make them money to be 
concerned with "Internet esoterica" 
that doesn't add to the bottom line. You have to make their ignorance SUBTRACT 
from the bottom line. 

Contracts, properly enforced, can make a huge dent in the problem of
BCP38 adoption. At a number of levels. 

Equipment manufacturers not usually involved in this sort of thing (home and 
SOHO market) would then have market incentive to provide equipment at the low 
end that would provide BCP38 support. Especially equipment manufacturers that 
incorporate embedded Linux in their products. They can be creative in how they 
implement their product; let creativity blossom. 

I know, I know, BCP38 was originally directed at Internet Service Providers at 
their edge to upstreams. I'm thinking that BCP38 needs to be in place at any 
point -- every point? -- where you have a significant-sized collection of 
systems/devices aggregated to single upstream connections. Particular 
systems/devices where any source address can be generated and propagated -- 
including compromised desktop computers, compromised light bulbs, compromised 
wireless routers, compromised you-name-it. 

(That is one nice thing about NAT -- the bad guys can't build spoofed packets. 
They *can* build, um, "other" packets...which is a different subject entirely.) 

(N.B.: Now you know why I'm trying to get the simplest possible definition of 
BCP38 into words. The RFCs don't contain "executive
summaries".) 

RE: small automatic transfer switches

[White, Andrew]

+1 on Baytech



-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Krenn, Thomas A
Sent: Wednesday, January 27, 2016 2:36 PM
To: Chuck Anderson; nanog@nanog.org
Subject: RE: small automatic transfer switches

I have had good luck with BayTech in the past. 
http://www.baytech.net/


Tom Krenn | Optum
IT Network Services


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Chuck Anderson
Sent: Wednesday, January 27, 2016 2:30 PM
To: nanog@nanog.org
Subject: small automatic transfer switches

Does anyone have any recommendations for a small, cheap, reliable ATS?
(I know, pick two, you can't have all three) I'm looking for something to power 
one or two 120V out-of-band network device(s) in each location with a single 
power supply each, much less than 10 amps total, with two 120v input cords.  
The primary input cord will go to the UPS and the other directly to a wall 
outlet to be able to access the UPS when if fails to turn on after the power 
returns :-)

I found the usual suspects, APC, TrippLite, ServerTech, etc. but they are 
mostly 8 or more outlets and upwards of $300-$900 each.

I also found this neat one, Zonit uATS, which is a small box that piggybacks 
onto the powered device's C14 input and has two power cords coming out of it.  
But it seems to cost just as much as the bigger ones...


This e-mail, including attachments, may include confidential and/or proprietary 
information, and may be used only by the person or entity to which it is 
addressed. If the reader of this e-mail is not the intended recipient or his or 
her authorized agent, the reader is hereby notified that any dissemination, 
distribution or copying of this e-mail is prohibited. If you have received this 
e-mail in error, please notify the sender by replying to this message and 
delete this e-mail immediately.

RE: IPV6 availability

[White, Andrew]

Here's our page on IPv6 support:

http://www.charter.net/support/internet/ipv6/

TL;DR: Subscribers can only get ipv6 today via a 6rd tunnel.


Andrew White
Desk:  314.394-9594  | Cell:  314.452-4386
Systems Engineer III, DAS DNS group
Charter Communications
12405 Powerscourt Drive, St. Louis,  MO 63131



-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Roy
Sent: Wednesday, December 16, 2015 4:52 PM
To: nanog
Subject: IPV6 availability

Anyone know what the IPV6 availability is on Cable One or Charter networks?

Last I heard from Charter was that they were in beta.  Its been in that state 
for years.

I can't find anything on Cable One

Contact for Open Resolver Project?

[White, Andrew]

Hi there,

If anyone from the Open Resolver Project is on-list, would love to get in touch 
re. getting a feed of open resolver data for our ASN. I have not been receiving 
response to the email address listed on the project's web site.

Andrew White
Desk:  314.394-9594  | Cell:  314.308-7730
NetOps Consultant, DAS DNS group
Charter Communications
12405 Powerscourt Drive, St. Louis,  MO 63131

RE: NetFlow - path from Routers to Collector

[White, Andrew]

$50 on ebay

http://www.ebay.com/sch/i.html?_from=R40&_trksid=p2050601.m570.l1313.TR12.TRC2.A0.H0.Xconsole+server.TRS0&_nkw=console+server&_sacat=0

Andrew White
Desk:  314.394-9594  | Cell:  314.308-7730
NetOps Consultant, DAS DNS group
Charter Communications
12405 Powerscourt Drive  St. Louis,  MO 63131


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Frank Bulk
Sent: Thursday, September 10, 2015 9:37 AM
To: 'Roland Dobbins'; nanog@nanog.org
Subject: RE: NetFlow - path from Routers to Collector

Does anyone else have a serial to IP dongle for devices that are IP only?
That dongle would need to have telnet and SSH support.  Or an IP-to-IP dongle, 
that would support a routing table?  There's Brocade kit that has a mgmt. port, 
but it doesn't have its own routing table (they now have a mgmt.
vrf in some software releases), making it local-only or something you have to 
use some kind of pseudo-NAT (all public IPs are translated to mgmt-network IPs).

Frank

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Roland Dobbins
Sent: Tuesday, September 01, 2015 6:23 PM
To: nanog@nanog.org
Subject: Re: NetFlow - path from Routers to Collector



Absolutely.  All kinds of creative lashups to get console access in difficult 
situations (and, as you noted previously, an increasing number of devices don't 
support serial console at all, which is highly annoying).

---
Roland Dobbins